1999-12-04 21:35:07 +00:00
/*
2005-09-14 20:46:50 +00:00
* Asterisk - - An open source telephony toolkit .
1999-12-04 21:35:07 +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
* Copyright ( C ) 1999 - 2008 , Digium , Inc .
1999-12-04 21:35:07 +00:00
*
2004-09-22 05:19:06 +00:00
* Mark Spencer < markster @ digium . com >
1999-12-04 21:35:07 +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 .
*
1999-12-04 21:35:07 +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
*
2005-10-24 20:12:06 +00:00
* \ brief dial ( ) & retrydial ( ) - Trivial application to dial a channel and send an URL on answer
2005-12-30 21:18:06 +00:00
*
* \ author Mark Spencer < markster @ digium . com >
2008-02-09 11:27:10 +00:00
*
2005-11-06 15:09:47 +00:00
* \ ingroup applications
1999-12-04 21:35:07 +00:00
*/
2008-01-22 17:42:27 +00:00
/*** MODULEINFO
2008-04-25 20:20:10 +00:00
< depend > chan_local < / depend >
2011-07-14 20:28:54 +00:00
< support_level > core < / support_level >
2008-01-22 17:42:27 +00:00
* * */
2006-06-07 18:54:56 +00:00
# include "asterisk.h"
ASTERISK_FILE_VERSION ( __FILE__ , " $Revision$ " )
2005-06-06 22:39:32 +00:00
# include <sys/time.h>
# include <sys/signal.h>
2006-08-05 06:39:43 +00:00
# include <sys/stat.h>
2005-06-06 22:39:32 +00:00
# include <netinet/in.h>
2008-02-09 11:27:10 +00:00
# include "asterisk/paths.h" /* use ast_config_AST_DATA_DIR */
2005-04-21 06:02:45 +00:00
# include "asterisk/lock.h"
# include "asterisk/file.h"
# include "asterisk/channel.h"
# include "asterisk/pbx.h"
# include "asterisk/module.h"
# include "asterisk/translate.h"
# include "asterisk/say.h"
# include "asterisk/config.h"
# include "asterisk/features.h"
# include "asterisk/musiconhold.h"
# include "asterisk/callerid.h"
# include "asterisk/utils.h"
# include "asterisk/app.h"
# include "asterisk/causes.h"
2009-04-02 17:20:52 +00:00
# include "asterisk/rtp_engine.h"
Merged revisions 89622 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r89622 | murf | 2007-11-26 23:24:02 -0700 (Mon, 26 Nov 2007) | 1 line
closes issue #11379; OK, this is an attempt to make both sides happy. To the cdr.conf file, I added the option 'unanswered', which defaults to 'no'. In this mode, you will see a cdr for a call, whether it was answered or not. The disposition will be NO ANSWER or ANSWERED, as appropriate. The src is as you'd expect, the destination channel will be one of the channels from the Dial() call, usually the last in the list if more than one chan was specified. With unanswered set to 'yes', you will still see this cdr entry in both cases. But in the case where the dial timed out, you will also see a cdr for each line attempted, marked NO ANSWER, with no destination channel name. The new option defaults to 'no', so you don't see the pesky extra cdr's by default, and you will not see the irritating 'not posted' messages.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-11-27 06:47:08 +00:00
# include "asterisk/cdr.h"
2005-04-21 06:02:45 +00:00
# include "asterisk/manager.h"
2005-07-12 03:23:31 +00:00
# include "asterisk/privacy.h"
2006-02-01 23:05:28 +00:00
# include "asterisk/stringfields.h"
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
# include "asterisk/global_datastores.h"
2008-03-05 16:23:44 +00:00
# include "asterisk/dsp.h"
2009-06-26 15:28:53 +00:00
# include "asterisk/cel.h"
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
# include "asterisk/aoc.h"
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
# include "asterisk/ccss.h"
2009-12-19 08:59:31 +00:00
# include "asterisk/indications.h"
2011-06-29 15:36:20 +00:00
# include "asterisk/framehook.h"
1999-12-04 21:35:07 +00:00
2008-11-01 21:10:07 +00:00
/*** DOCUMENTATION
< application name = " Dial " language = " en_US " >
< synopsis >
Attempt to connect to another device or endpoint and bridge the call .
< / synopsis >
< syntax >
< parameter name = " Technology/Resource " required = " true " argsep = " & " >
< argument name = " Technology/Resource " required = " true " >
< para > Specification of the device ( s ) to dial . These must be in the format of
< literal > Technology / Resource < / literal > , where < replaceable > Technology < / replaceable >
represents a particular channel driver , and < replaceable > Resource < / replaceable >
represents a resource available to that particular channel driver . < / para >
< / argument >
< argument name = " Technology2/Resource2 " required = " false " multiple = " true " >
< para > Optional extra devices to dial in parallel < / para >
< para > If you need more then one enter them as
Technology2 / Resource2 & amp ; Technology3 / Resourse3 & amp ; . . . . . < / para >
< / argument >
< / parameter >
< parameter name = " timeout " required = " false " >
< para > Specifies the number of seconds we attempt to dial the specified devices < / para >
< para > If not specified , this defaults to 136 years . < / para >
< / parameter >
< parameter name = " options " required = " false " >
< optionlist >
< option name = " A " >
< argument name = " x " required = " true " >
< para > The file to play to the called party < / para >
< / argument >
< para > Play an announcement to the called party , where < replaceable > x < / replaceable > is the prompt to be played < / para >
< / option >
2009-11-04 21:39:33 +00:00
< option name = " a " >
< para > Immediately answer the calling channel when the called channel answers in
all cases . Normally , the calling channel is answered when the called channel
answers , but when options such as A ( ) and M ( ) are used , the calling channel is
not answered until all actions on the called channel ( such as playing an
announcement ) are completed . This option can be used to answer the calling
channel before doing anything on the called channel . You will rarely need to use
this option , the default behavior is adequate in most cases . < / para >
< / option >
2008-11-01 21:10:07 +00:00
< option name = " C " >
< para > Reset the call detail record ( CDR ) for this call . < / para >
< / option >
< option name = " c " >
< para > If the Dial ( ) application cancels this call , always set the flag to tell the channel
driver that the call is answered elsewhere . < / para >
< / option >
< option name = " d " >
< para > Allow the calling user to dial a 1 digit extension while waiting for
a call to be answered . Exit to that extension if it exists in the
current context , or the context defined in the < variable > EXITCONTEXT < / variable > variable ,
if it exists . < / para >
2011-09-19 19:03:38 +00:00
< note >
< para > Many SIP and ISDN phones cannot send DTMF digits until the call is
connected . If you wish to use this option with these phones , you
can use the < literal > Answer < / literal > application before dialing . < / para >
< / note >
2008-11-01 21:10:07 +00:00
< / option >
< option name = " D " argsep = " : " >
< argument name = " called " / >
< argument name = " calling " / >
2009-03-17 17:17:51 +00:00
< argument name = " progress " / >
2008-11-01 21:10:07 +00:00
< para > Send the specified DTMF strings < emphasis > after < / emphasis > the called
party has answered , but before the call gets bridged . The
< replaceable > called < / replaceable > DTMF string is sent to the called party , and the
< replaceable > calling < / replaceable > DTMF string is sent to the calling party . Both arguments
2009-03-17 17:17:51 +00:00
can be used alone . If < replaceable > progress < / replaceable > is specified , its DTMF is sent
immediately after receiving a PROGRESS message . < / para >
2008-11-01 21:10:07 +00:00
< / option >
< option name = " e " >
< para > Execute the < literal > h < / literal > extension for peer after the call ends < / para >
< / option >
< option name = " f " >
2010-01-05 18:46:19 +00:00
< argument name = " x " required = " false " / >
2011-03-18 02:31:27 +00:00
< para > If < replaceable > x < / replaceable > is not provided , force the CallerID sent on a call - forward or
deflection to the dialplan extension of this Dial ( ) using a dialplan < literal > hint < / literal > .
2008-11-01 21:10:07 +00:00
For example , some PSTNs do not allow CallerID to be set to anything
2011-03-18 02:31:27 +00:00
other than the numbers assigned to you .
If < replaceable > x < / replaceable > is provided , force the CallerID sent to < replaceable > x < / replaceable > . < / para >
2008-11-01 21:10:07 +00:00
< / option >
< option name = " F " argsep = " ^ " >
< argument name = " context " required = " false " / >
< argument name = " exten " required = " false " / >
< argument name = " priority " required = " true " / >
2011-10-03 20:07:08 +00:00
< para > When the caller hangs up , transfer the < emphasis > called < / 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 >
2008-11-01 21:10:07 +00:00
< / option >
2009-04-09 19:10:02 +00:00
< option name = " F " >
2011-10-03 20:07:08 +00:00
< para > When the caller hangs up , transfer the < emphasis > called < / 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 >
2011-10-05 17:02:17 +00:00
< / note >
< note >
< para > Using this option from a Macro ( ) or GoSub ( ) might not make sense as there would be no return points . < / para >
2011-10-03 20:07:08 +00:00
< / note >
2009-04-09 19:10:02 +00:00
< / option >
2008-11-01 21:10:07 +00:00
< option name = " g " >
< para > Proceed with dialplan execution at the next priority in the current extension if the
destination channel hangs up . < / para >
< / option >
< option name = " G " argsep = " ^ " >
< argument name = " context " required = " false " / >
< argument name = " exten " required = " false " / >
< argument name = " priority " required = " true " / >
< para > If the call is answered , transfer the calling party to
the specified < replaceable > priority < / replaceable > and the called party to the specified
< replaceable > priority < / replaceable > plus one . < / para >
< note >
< para > You cannot use any additional action post answer options in conjunction with this option . < / para >
< / note >
< / option >
< option name = " h " >
2011-09-19 19:03:38 +00:00
< para > Allow the called party to hang up by sending the DTMF sequence
defined for disconnect in < filename > features . conf < / filename > . < / para >
2008-11-01 21:10:07 +00:00
< / option >
< option name = " H " >
2011-09-19 19:03:38 +00:00
< para > Allow the calling party to hang up by sending the DTMF sequence
defined for disconnect in < filename > features . conf < / filename > . < / para >
< note >
< para > Many SIP and ISDN phones cannot send DTMF digits until the call is
connected . If you wish to allow DTMF disconnect before the dialed
party answers with these phones , you can use the < literal > Answer < / literal >
application before dialing . < / para >
< / note >
2008-11-01 21:10:07 +00:00
< / option >
< option name = " i " >
< para > Asterisk will ignore any forwarding requests it may receive on this dial attempt . < / para >
< / option >
2009-04-03 22:41:46 +00:00
< option name = " I " >
2012-01-11 21:56:12 +00:00
< para > Asterisk will ignore any connected line update requests or any redirecting party
update requests it may receive on this dial attempt . < / para >
2009-04-03 22:41:46 +00:00
< / option >
2008-11-01 21:10:07 +00:00
< option name = " k " >
< para > Allow the called party to enable parking of the call by sending
the DTMF sequence defined for call parking in < filename > features . conf < / filename > . < / para >
< / option >
< option name = " K " >
< para > Allow the calling party to enable parking of the call by sending
the DTMF sequence defined for call parking in < filename > features . conf < / filename > . < / para >
< / option >
< option name = " L " argsep = " : " >
< argument name = " x " required = " true " >
< para > Maximum call time , in milliseconds < / para >
< / argument >
< argument name = " y " >
< para > Warning time , in milliseconds < / para >
< / argument >
< argument name = " z " >
< para > Repeat time , in milliseconds < / para >
< / argument >
< para > Limit the call to < replaceable > x < / replaceable > milliseconds . Play a warning when < replaceable > y < / replaceable > milliseconds are
left . Repeat the warning every < replaceable > z < / replaceable > milliseconds until time expires . < / para >
< para > This option is affected by the following variables : < / para >
< variablelist >
< variable name = " LIMIT_PLAYAUDIO_CALLER " >
< value name = " yes " default = " true " / >
< value name = " no " / >
< para > If set , this variable causes Asterisk to play the prompts to the caller . < / para >
< / variable >
< variable name = " LIMIT_PLAYAUDIO_CALLEE " >
< value name = " yes " / >
< value name = " no " default = " true " / >
< para > If set , this variable causes Asterisk to play the prompts to the callee . < / para >
< / variable >
< variable name = " LIMIT_TIMEOUT_FILE " >
< value name = " filename " / >
< para > If specified , < replaceable > filename < / replaceable > specifies the sound prompt to play when the timeout is reached .
If not set , the time remaining will be announced . < / para >
< / variable >
< variable name = " LIMIT_CONNECT_FILE " >
< value name = " filename " / >
< para > If specified , < replaceable > filename < / replaceable > specifies the sound prompt to play when the call begins .
If not set , the time remaining will be announced . < / para >
< / variable >
< variable name = " LIMIT_WARNING_FILE " >
< value name = " filename " / >
< para > If specified , < replaceable > filename < / replaceable > specifies the sound prompt to play as
a warning when time < replaceable > x < / replaceable > is reached . If not set , the time remaining will be announced . < / para >
< / variable >
< / variablelist >
< / option >
< option name = " m " >
< argument name = " class " required = " false " / >
< para > Provide hold music to the calling party until a requested
channel answers . A specific music on hold < replaceable > class < / replaceable >
( as defined in < filename > musiconhold . conf < / filename > ) can be specified . < / para >
< / option >
< option name = " M " argsep = " ^ " >
< argument name = " macro " required = " true " >
< para > Name of the macro that should be executed . < / para >
< / argument >
< argument name = " arg " multiple = " true " >
< para > Macro arguments < / para >
< / argument >
< para > Execute the specified < replaceable > macro < / replaceable > for the < emphasis > called < / emphasis > channel
before connecting to the calling channel . Arguments can be specified to the Macro
using < literal > ^ < / literal > as a delimiter . The macro can set the variable
< variable > MACRO_RESULT < / variable > to specify the following actions after the macro is
finished executing : < / para >
< variablelist >
< variable name = " MACRO_RESULT " >
< para > If set , this action will be taken after the macro finished executing . < / para >
< value name = " ABORT " >
Hangup both legs of the call
< / value >
< value name = " CONGESTION " >
Behave as if line congestion was encountered
< / value >
< value name = " BUSY " >
Behave as if a busy signal was encountered
< / value >
< value name = " CONTINUE " >
Hangup the called party and allow the calling party to continue dialplan execution at the next priority
< / value >
< ! - - TODO : Fix this syntax up , once we ' ve figured out how to specify the GOTO syntax - - >
< value name = " GOTO:<context>^<exten>^<priority> " >
Transfer the call to the specified destination .
< / value >
< / variable >
< / variablelist >
< note >
< para > You cannot use any additional action post answer options in conjunction
with this option . Also , pbx services are not run on the peer ( called ) channel ,
so you will not be able to set timeouts via the TIMEOUT ( ) function in this macro . < / para >
< / note >
2009-05-18 14:45:23 +00:00
< warning > < para > Be aware of the limitations that macros have , specifically with regards to use of
the < literal > WaitExten < / literal > application . For more information , see the documentation for
Macro ( ) < / para > < / warning >
2008-11-01 21:10:07 +00:00
< / option >
< option name = " n " >
2009-11-02 18:08:54 +00:00
< argument name = " delete " >
< para > With < replaceable > delete < / replaceable > either not specified or set to < literal > 0 < / literal > ,
the recorded introduction will not be deleted if the caller hangs up while the remote party has not
yet answered . < / para >
< para > With < replaceable > delete < / replaceable > set to < literal > 1 < / literal > , the introduction will
always be deleted . < / para >
< / argument >
2008-11-01 21:10:07 +00:00
< para > This option is a modifier for the call screening / privacy mode . ( See the
< literal > p < / literal > and < literal > P < / literal > options . ) It specifies
that no introductions are to be saved in the < directory > priv - callerintros < / directory >
directory . < / para >
< / option >
< option name = " N " >
< para > This option is a modifier for the call screening / privacy mode . It specifies
that if Caller * ID is present , do not screen the call . < / para >
< / option >
< option name = " o " >
2011-03-18 02:31:27 +00:00
< argument name = " x " required = " false " / >
< para > If < replaceable > x < / replaceable > is not provided , specify that the CallerID that was present on the
< emphasis > calling < / emphasis > channel be stored as the CallerID on the < emphasis > called < / emphasis > channel .
This was the behavior of Asterisk 1.0 and earlier .
If < replaceable > x < / replaceable > is provided , specify the CallerID stored on the < emphasis > called < / emphasis > channel .
Note that o ( $ { CALLERID ( all ) } ) is similar to option o without the parameter . < / para >
2008-11-01 21:10:07 +00:00
< / option >
< option name = " O " >
< argument name = " mode " >
< para > With < replaceable > mode < / replaceable > either not specified or set to < literal > 1 < / literal > ,
the originator hanging up will cause the phone to ring back immediately . < / para >
< para > With < replaceable > mode < / replaceable > set to < literal > 2 < / literal > , when the operator
flashes the trunk , it will ring their phone back . < / para >
< / argument >
< para > Enables < emphasis > operator services < / emphasis > mode . This option only
works when bridging a DAHDI channel to another DAHDI channel
only . if specified on non - DAHDI interfaces , it will be ignored .
When the destination answers ( presumably an operator services
station ) , the originator no longer has control of their line .
They may hang up , but the switch will not release their line
until the destination party ( the operator ) hangs up . < / para >
< / option >
< option name = " p " >
< para > This option enables screening mode . This is basically Privacy mode
without memory . < / para >
< / option >
< option name = " P " >
< argument name = " x " / >
< para > Enable privacy mode . Use < replaceable > x < / replaceable > as the family / key in the AstDB database if
it is provided . The current extension is used if a database family / key is not specified . < / para >
< / option >
< option name = " r " >
2009-12-19 08:59:31 +00:00
< para > Default : Indicate ringing to the calling party , even if the called party isn ' t actually ringing . Pass no audio to the calling
2008-11-01 21:10:07 +00:00
party until the called channel has answered . < / para >
2009-12-19 08:59:31 +00:00
< argument name = " tone " required = " false " >
< para > Indicate progress to calling party . Send audio ' tone ' from indications . conf < / para >
< / argument >
2008-11-01 21:10:07 +00:00
< / option >
< option name = " S " >
< argument name = " x " required = " true " / >
< para > Hang up the call < replaceable > x < / replaceable > seconds < emphasis > after < / emphasis > the called party has
answered the call . < / para >
< / option >
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
< option name = " s " >
< argument name = " x " required = " true " / >
2011-03-18 02:31:27 +00:00
< para > Force the outgoing callerid tag parameter to be set to the string < replaceable > x < / replaceable > . < / para >
< para > Works with the f option . < / para >
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
< / option >
2008-11-01 21:10:07 +00:00
< option name = " t " >
< para > Allow the called party to transfer the calling party by sending the
2010-03-31 17:48:09 +00:00
DTMF sequence defined in < filename > features . conf < / filename > . This setting does not perform policy enforcement on
transfers initiated by other methods . < / para >
2008-11-01 21:10:07 +00:00
< / option >
< option name = " T " >
< para > Allow the calling party to transfer the called party by sending the
2010-03-31 17:48:09 +00:00
DTMF sequence defined in < filename > features . conf < / filename > . This setting does not perform policy enforcement on
transfers initiated by other methods . < / para >
2008-11-01 21:10:07 +00:00
< / option >
< option name = " U " argsep = " ^ " >
< argument name = " x " required = " true " >
< para > Name of the subroutine to execute via Gosub < / para >
< / argument >
< argument name = " arg " multiple = " true " required = " false " >
< para > Arguments for the Gosub routine < / para >
< / argument >
< para > Execute via Gosub the routine < replaceable > x < / replaceable > for the < emphasis > called < / emphasis > channel before connecting
to the calling channel . Arguments can be specified to the Gosub
using < literal > ^ < / literal > as a delimiter . The Gosub routine can set the variable
< variable > GOSUB_RESULT < / variable > to specify the following actions after the Gosub returns . < / para >
< variablelist >
< variable name = " GOSUB_RESULT " >
< value name = " ABORT " >
Hangup both legs of the call .
< / value >
< value name = " CONGESTION " >
Behave as if line congestion was encountered .
< / value >
< value name = " BUSY " >
Behave as if a busy signal was encountered .
< / value >
< value name = " CONTINUE " >
Hangup the called party and allow the calling party
to continue dialplan execution at the next priority .
< / value >
< ! - - TODO : Fix this syntax up , once we ' ve figured out how to specify the GOTO syntax - - >
< value name = " GOTO:<context>^<exten>^<priority> " >
Transfer the call to the specified priority . Optionally , an extension , or
extension and priority can be specified .
< / value >
< / variable >
< / variablelist >
< note >
< para > You cannot use any additional action post answer options in conjunction
with this option . Also , pbx services are not run on the peer ( called ) channel ,
so you will not be able to set timeouts via the TIMEOUT ( ) function in this routine . < / para >
< / note >
< / option >
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
< option name = " u " >
< argument name = " x " required = " true " >
< para > Force the outgoing callerid presentation indicator parameter to be set
to one of the values passed in < replaceable > x < / replaceable > :
< literal > allowed_not_screened < / literal >
< literal > allowed_passed_screen < / literal >
< literal > allowed_failed_screen < / literal >
< literal > allowed < / literal >
< literal > prohib_not_screened < / literal >
< literal > prohib_passed_screen < / literal >
< literal > prohib_failed_screen < / literal >
< literal > prohib < / literal >
< literal > unavailable < / literal > < / para >
< / argument >
2011-03-18 02:31:27 +00:00
< para > Works with the f option . < / para >
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
< / option >
2008-11-01 21:10:07 +00:00
< option name = " w " >
< para > Allow the called party to enable recording of the call by sending
the DTMF sequence defined for one - touch recording in < filename > features . conf < / filename > . < / para >
< / option >
< option name = " W " >
< para > Allow the calling party to enable recording of the call by sending
the DTMF sequence defined for one - touch recording in < filename > features . conf < / filename > . < / para >
< / option >
< option name = " x " >
< para > Allow the called party to enable recording of the call by sending
the DTMF sequence defined for one - touch automixmonitor in < filename > features . conf < / filename > . < / para >
< / option >
< option name = " X " >
< para > Allow the calling party to enable recording of the call by sending
the DTMF sequence defined for one - touch automixmonitor in < filename > features . conf < / filename > . < / para >
< / option >
2009-04-15 15:24:50 +00:00
< option name = " z " >
< para > On a call forward , cancel any dial timeout which has been set for this call . < / para >
< / option >
2008-11-01 21:10:07 +00:00
< / optionlist >
< / parameter >
< parameter name = " URL " >
< para > The optional URL will be sent to the called party if the channel driver supports it . < / para >
< / parameter >
< / syntax >
< description >
< para > This application will place calls to one or more specified channels . As soon
as one of the requested channels answers , the originating channel will be
answered , if it has not already been answered . These two channels will then
be active in a bridged call . All other channels that were requested will then
be hung up . < / para >
< para > Unless there is a timeout specified , the Dial application will wait
indefinitely until one of the called channels answers , the user hangs up , or
if all of the called channels are busy or unavailable . Dialplan executing will
continue if no requested channels can be called , or if the timeout expires .
This application will report normal termination if the originating channel
hangs up , or if the call is bridged and either of the parties in the bridge
ends the call . < / para >
< para > If the < variable > OUTBOUND_GROUP < / variable > variable is set , all peer channels created by this
application will be put into that group ( as in Set ( GROUP ( ) = . . . ) .
If the < variable > OUTBOUND_GROUP_ONCE < / variable > variable is set , all peer channels created by this
2011-12-23 15:26:12 +00:00
application will be put into that group ( as in Set ( GROUP ( ) = . . . ) . Unlike < variable > OUTBOUND_GROUP < / variable > ,
2008-11-01 21:10:07 +00:00
however , the variable will be unset after use . < / para >
< para > This application sets the following channel variables : < / para >
< variablelist >
< variable name = " DIALEDTIME " >
< para > This is the time from dialing a channel until when it is disconnected . < / para >
< / variable >
< variable name = " ANSWEREDTIME " >
< para > This is the amount of time for actual call . < / para >
< / variable >
< variable name = " DIALSTATUS " >
< para > This is the status of the call < / para >
< value name = " CHANUNAVAIL " / >
< value name = " CONGESTION " / >
< value name = " NOANSWER " / >
< value name = " BUSY " / >
< value name = " ANSWER " / >
< value name = " CANCEL " / >
< value name = " DONTCALL " >
For the Privacy and Screening Modes .
Will be set if the called party chooses to send the calling party to the ' Go Away ' script .
< / value >
< value name = " TORTURE " >
For the Privacy and Screening Modes .
Will be set if the called party chooses to send the calling party to the ' torture ' script .
< / value >
< value name = " INVALIDARGS " / >
< / variable >
< / variablelist >
< / description >
< / application >
< application name = " RetryDial " language = " en_US " >
< synopsis >
Place a call , retrying on failure allowing an optional exit extension .
< / synopsis >
< syntax >
< parameter name = " announce " required = " true " >
< para > Filename of sound that will be played when no channel can be reached < / para >
< / parameter >
< parameter name = " sleep " required = " true " >
2008-11-02 02:50:33 +00:00
< para > Number of seconds to wait after a dial attempt failed before a new attempt is made < / para >
2008-11-01 21:10:07 +00:00
< / parameter >
< parameter name = " retries " required = " true " >
< para > Number of retries < / para >
< para > When this is reached flow will continue at the next priority in the dialplan < / para >
< / parameter >
< parameter name = " dialargs " required = " true " >
< para > Same format as arguments provided to the Dial application < / para >
< / parameter >
< / syntax >
< description >
< para > This application will attempt to place a call using the normal Dial application .
If no channel can be reached , the < replaceable > announce < / replaceable > file will be played .
Then , it will wait < replaceable > sleep < / replaceable > number of seconds before retrying the call .
After < replaceable > retries < / replaceable > number of attempts , the calling channel will continue at the next priority in the dialplan .
If the < replaceable > retries < / replaceable > setting is set to 0 , this application will retry endlessly .
While waiting to retry a call , a 1 digit extension may be dialed . If that
extension exists in either the context defined in < variable > EXITCONTEXT < / variable > or the current
one , The call will jump to that extension immediately .
The < replaceable > dialargs < / replaceable > are specified in the same format that arguments are provided
to the Dial application . < / para >
< / description >
< / application >
* * */
1999-12-04 21:35:07 +00:00
2009-06-07 14:55:51 +00:00
static const char app [ ] = " Dial " ;
static const char rapp [ ] = " RetryDial " ;
2005-01-18 03:12:53 +00:00
2005-11-03 21:40:36 +00:00
enum {
2007-12-12 20:05:13 +00:00
OPT_ANNOUNCE = ( 1 < < 0 ) ,
OPT_RESETCDR = ( 1 < < 1 ) ,
OPT_DTMF_EXIT = ( 1 < < 2 ) ,
OPT_SENDDTMF = ( 1 < < 3 ) ,
OPT_FORCECLID = ( 1 < < 4 ) ,
OPT_GO_ON = ( 1 < < 5 ) ,
OPT_CALLEE_HANGUP = ( 1 < < 6 ) ,
OPT_CALLER_HANGUP = ( 1 < < 7 ) ,
2009-04-03 22:41:46 +00:00
OPT_ORIGINAL_CLID = ( 1 < < 8 ) ,
2007-12-12 20:05:13 +00:00
OPT_DURATION_LIMIT = ( 1 < < 9 ) ,
OPT_MUSICBACK = ( 1 < < 10 ) ,
OPT_CALLEE_MACRO = ( 1 < < 11 ) ,
OPT_SCREEN_NOINTRO = ( 1 < < 12 ) ,
2009-04-03 22:41:46 +00:00
OPT_SCREEN_NOCALLERID = ( 1 < < 13 ) ,
OPT_IGNORE_CONNECTEDLINE = ( 1 < < 14 ) ,
2007-12-12 20:05:13 +00:00
OPT_SCREENING = ( 1 < < 15 ) ,
OPT_PRIVACY = ( 1 < < 16 ) ,
OPT_RINGBACK = ( 1 < < 17 ) ,
OPT_DURATION_STOP = ( 1 < < 18 ) ,
OPT_CALLEE_TRANSFER = ( 1 < < 19 ) ,
OPT_CALLER_TRANSFER = ( 1 < < 20 ) ,
OPT_CALLEE_MONITOR = ( 1 < < 21 ) ,
OPT_CALLER_MONITOR = ( 1 < < 22 ) ,
OPT_GOTO = ( 1 < < 23 ) ,
OPT_OPERMODE = ( 1 < < 24 ) ,
OPT_CALLEE_PARK = ( 1 < < 25 ) ,
OPT_CALLER_PARK = ( 1 < < 26 ) ,
2006-05-31 15:52:32 +00:00
OPT_IGNORE_FORWARDING = ( 1 < < 27 ) ,
2007-12-12 20:05:13 +00:00
OPT_CALLEE_GOSUB = ( 1 < < 28 ) ,
2007-11-30 21:19:57 +00:00
OPT_CALLEE_MIXMONITOR = ( 1 < < 29 ) ,
OPT_CALLER_MIXMONITOR = ( 1 < < 30 ) ,
2007-04-09 22:49:32 +00:00
} ;
2005-11-03 21:40:36 +00:00
2011-08-11 21:55:48 +00:00
/* flags are now 64 bits, so keep it up! */
2011-08-12 18:03:29 +00:00
# define DIAL_STILLGOING (1LLU << 31)
# define DIAL_NOFORWARDHTML (1LLU << 32)
# define DIAL_CALLERID_ABSENT (1LLU << 33) /* TRUE if caller id is not available for connected line. */
# define OPT_CANCEL_ELSEWHERE (1LLU << 34)
# define OPT_PEER_H (1LLU << 35)
# define OPT_CALLEE_GO_ON (1LLU << 36)
# define OPT_CANCEL_TIMEOUT (1LLU << 37)
# define OPT_FORCE_CID_TAG (1LLU << 38)
# define OPT_FORCE_CID_PRES (1LLU << 39)
# define OPT_CALLER_ANSWER (1LLU << 40)
2005-11-03 21:40:36 +00:00
enum {
OPT_ARG_ANNOUNCE = 0 ,
OPT_ARG_SENDDTMF ,
OPT_ARG_GOTO ,
OPT_ARG_DURATION_LIMIT ,
OPT_ARG_MUSICBACK ,
OPT_ARG_CALLEE_MACRO ,
2009-12-19 08:59:31 +00:00
OPT_ARG_RINGBACK ,
2007-06-19 23:36:34 +00:00
OPT_ARG_CALLEE_GOSUB ,
2008-04-09 13:55:28 +00:00
OPT_ARG_CALLEE_GO_ON ,
2005-11-03 21:40:36 +00:00
OPT_ARG_PRIVACY ,
OPT_ARG_DURATION_STOP ,
2006-04-22 11:30:06 +00:00
OPT_ARG_OPERMODE ,
2009-11-02 18:08:54 +00:00
OPT_ARG_SCREEN_NOINTRO ,
2011-03-18 02:31:27 +00:00
OPT_ARG_ORIGINAL_CLID ,
2010-01-05 18:46:19 +00:00
OPT_ARG_FORCECLID ,
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
OPT_ARG_FORCE_CID_TAG ,
OPT_ARG_FORCE_CID_PRES ,
2005-11-03 21:40:36 +00:00
/* note: this entry _MUST_ be the last one in the enum */
OPT_ARG_ARRAY_SIZE ,
2007-04-09 22:49:32 +00:00
} ;
2005-11-03 21:40:36 +00:00
2007-11-14 01:40:47 +00:00
AST_APP_OPTIONS ( dial_exec_options , BEGIN_OPTIONS
2005-11-03 21:40:36 +00:00
AST_APP_OPTION_ARG ( ' A ' , OPT_ANNOUNCE , OPT_ARG_ANNOUNCE ) ,
2009-11-04 21:39:33 +00:00
AST_APP_OPTION ( ' a ' , OPT_CALLER_ANSWER ) ,
2005-11-03 21:40:36 +00:00
AST_APP_OPTION ( ' C ' , OPT_RESETCDR ) ,
2007-07-09 08:27:37 +00:00
AST_APP_OPTION ( ' c ' , OPT_CANCEL_ELSEWHERE ) ,
2005-11-03 21:40:36 +00:00
AST_APP_OPTION ( ' d ' , OPT_DTMF_EXIT ) ,
AST_APP_OPTION_ARG ( ' D ' , OPT_SENDDTMF , OPT_ARG_SENDDTMF ) ,
2007-07-17 19:40:29 +00:00
AST_APP_OPTION ( ' e ' , OPT_PEER_H ) ,
2010-01-05 18:46:19 +00:00
AST_APP_OPTION_ARG ( ' f ' , OPT_FORCECLID , OPT_ARG_FORCECLID ) ,
2008-04-09 13:55:28 +00:00
AST_APP_OPTION_ARG ( ' F ' , OPT_CALLEE_GO_ON , OPT_ARG_CALLEE_GO_ON ) ,
2005-11-03 21:40:36 +00:00
AST_APP_OPTION ( ' g ' , OPT_GO_ON ) ,
AST_APP_OPTION_ARG ( ' G ' , OPT_GOTO , OPT_ARG_GOTO ) ,
AST_APP_OPTION ( ' h ' , OPT_CALLEE_HANGUP ) ,
AST_APP_OPTION ( ' H ' , OPT_CALLER_HANGUP ) ,
2006-05-31 15:52:32 +00:00
AST_APP_OPTION ( ' i ' , OPT_IGNORE_FORWARDING ) ,
2009-04-03 22:41:46 +00:00
AST_APP_OPTION ( ' I ' , OPT_IGNORE_CONNECTEDLINE ) ,
2007-06-19 23:36:34 +00:00
AST_APP_OPTION ( ' k ' , OPT_CALLEE_PARK ) ,
2007-08-31 18:46:02 +00:00
AST_APP_OPTION ( ' K ' , OPT_CALLER_PARK ) ,
2005-11-03 21:40:36 +00:00
AST_APP_OPTION_ARG ( ' L ' , OPT_DURATION_LIMIT , OPT_ARG_DURATION_LIMIT ) ,
AST_APP_OPTION_ARG ( ' m ' , OPT_MUSICBACK , OPT_ARG_MUSICBACK ) ,
AST_APP_OPTION_ARG ( ' M ' , OPT_CALLEE_MACRO , OPT_ARG_CALLEE_MACRO ) ,
2009-11-02 18:08:54 +00:00
AST_APP_OPTION_ARG ( ' n ' , OPT_SCREEN_NOINTRO , OPT_ARG_SCREEN_NOINTRO ) ,
2009-04-03 22:41:46 +00:00
AST_APP_OPTION ( ' N ' , OPT_SCREEN_NOCALLERID ) ,
2011-03-18 02:31:27 +00:00
AST_APP_OPTION_ARG ( ' o ' , OPT_ORIGINAL_CLID , OPT_ARG_ORIGINAL_CLID ) ,
2007-12-12 20:05:13 +00:00
AST_APP_OPTION_ARG ( ' O ' , OPT_OPERMODE , OPT_ARG_OPERMODE ) ,
2005-11-03 21:40:36 +00:00
AST_APP_OPTION ( ' p ' , OPT_SCREENING ) ,
AST_APP_OPTION_ARG ( ' P ' , OPT_PRIVACY , OPT_ARG_PRIVACY ) ,
2009-12-19 08:59:31 +00:00
AST_APP_OPTION_ARG ( ' r ' , OPT_RINGBACK , OPT_ARG_RINGBACK ) ,
2005-11-03 21:40:36 +00:00
AST_APP_OPTION_ARG ( ' S ' , OPT_DURATION_STOP , OPT_ARG_DURATION_STOP ) ,
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
AST_APP_OPTION_ARG ( ' s ' , OPT_FORCE_CID_TAG , OPT_ARG_FORCE_CID_TAG ) ,
AST_APP_OPTION_ARG ( ' u ' , OPT_FORCE_CID_PRES , OPT_ARG_FORCE_CID_PRES ) ,
2005-11-03 21:40:36 +00:00
AST_APP_OPTION ( ' t ' , OPT_CALLEE_TRANSFER ) ,
AST_APP_OPTION ( ' T ' , OPT_CALLER_TRANSFER ) ,
2007-06-19 23:36:34 +00:00
AST_APP_OPTION_ARG ( ' U ' , OPT_CALLEE_GOSUB , OPT_ARG_CALLEE_GOSUB ) ,
2005-11-03 21:40:36 +00:00
AST_APP_OPTION ( ' w ' , OPT_CALLEE_MONITOR ) ,
AST_APP_OPTION ( ' W ' , OPT_CALLER_MONITOR ) ,
2007-11-30 21:19:57 +00:00
AST_APP_OPTION ( ' x ' , OPT_CALLEE_MIXMONITOR ) ,
AST_APP_OPTION ( ' X ' , OPT_CALLER_MIXMONITOR ) ,
2009-04-15 15:24:50 +00:00
AST_APP_OPTION ( ' z ' , OPT_CANCEL_TIMEOUT ) ,
2007-11-14 01:40:47 +00:00
END_OPTIONS ) ;
2005-11-03 21:40:36 +00:00
2008-07-14 17:54:11 +00:00
# define CAN_EARLY_BRIDGE(flags,chan,peer) (!ast_test_flag64(flags, OPT_CALLEE_HANGUP | \
2007-10-01 14:27:02 +00:00
OPT_CALLER_HANGUP | OPT_CALLEE_TRANSFER | OPT_CALLER_TRANSFER | \
2009-10-19 19:49:09 +00:00
OPT_CALLEE_MONITOR | OPT_CALLER_MONITOR | OPT_CALLEE_PARK | \
OPT_CALLER_PARK | OPT_ANNOUNCE | OPT_CALLEE_MACRO | OPT_CALLEE_GOSUB ) & & \
2012-02-20 23:43:27 +00:00
! ast_channel_audiohooks ( chan ) & & ! ast_channel_audiohooks ( peer ) & & \
ast_framehook_list_is_empty ( ast_channel_framehooks ( chan ) ) & & ast_framehook_list_is_empty ( ast_channel_framehooks ( peer ) ) )
2007-10-01 13:53:09 +00:00
2006-12-19 16:36:45 +00:00
/*
* The list of active channels
*/
struct chanlist {
struct chanlist * next ;
1999-12-04 21:35:07 +00:00
struct ast_channel * chan ;
2007-07-17 19:40:29 +00:00
uint64_t flags ;
2010-05-20 19:40:03 +00:00
/*! Saved connected party info from an AST_CONTROL_CONNECTED_LINE. */
2009-04-03 22:41:46 +00:00
struct ast_party_connected_line connected ;
2010-05-20 19:40:03 +00:00
/*! TRUE if an AST_CONTROL_CONNECTED_LINE update was saved to the connected element. */
unsigned int pending_connected_update : 1 ;
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
struct ast_aoc_decoded * aoc_s_rate_list ;
1999-12-04 21:35:07 +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 detect_disconnect ( struct ast_channel * chan , char code , struct ast_str * featurecode ) ;
1999-12-04 21:35:07 +00:00
2009-10-09 18:13:57 +00:00
static void chanlist_free ( struct chanlist * outgoing )
{
ast_party_connected_line_free ( & outgoing - > connected ) ;
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
ast_aoc_destroy_decoded ( outgoing - > aoc_s_rate_list ) ;
2009-10-09 18:13:57 +00:00
ast_free ( outgoing ) ;
}
2007-07-09 08:27:37 +00:00
static void hanguptree ( struct chanlist * outgoing , struct ast_channel * exception , int answered_elsewhere )
1999-12-04 21:35:07 +00:00
{
/* Hang up a tree of stuff */
2006-12-19 16:36:45 +00:00
struct chanlist * oo ;
2005-01-18 03:12:53 +00:00
while ( outgoing ) {
1999-12-04 21:35:07 +00:00
/* Hangup any existing lines we have open */
2007-07-09 08:27:37 +00:00
if ( outgoing - > chan & & ( outgoing - > chan ! = exception ) ) {
2009-01-29 17:08:22 +00:00
if ( answered_elsewhere ) {
/* The flag is used for local channel inheritance and stuff */
2012-03-13 18:20:34 +00:00
ast_set_flag ( ast_channel_flags ( outgoing - > chan ) , AST_FLAG_ANSWERED_ELSEWHERE ) ;
2009-01-29 17:08:22 +00:00
/* This is for the channel drivers */
2012-02-20 23:43:27 +00:00
ast_channel_hangupcause_set ( outgoing - > chan , AST_CAUSE_ANSWERED_ELSEWHERE ) ;
2009-01-29 17:08:22 +00:00
}
1999-12-04 21:35:07 +00:00
ast_hangup ( outgoing - > chan ) ;
2007-07-09 08:27:37 +00:00
}
1999-12-04 21:35:07 +00:00
oo = outgoing ;
2007-12-12 20:05:13 +00:00
outgoing = outgoing - > next ;
2009-10-09 18:13:57 +00:00
chanlist_free ( oo ) ;
1999-12-04 21:35:07 +00:00
}
}
2004-06-22 17:42:14 +00:00
# define AST_MAX_WATCHERS 256
2001-05-07 03:15:48 +00:00
2006-11-03 22:36:17 +00:00
/*
* argument to handle_cause ( ) and other functions .
*/
struct cause_args {
struct ast_channel * chan ;
int busy ;
int congestion ;
int nochan ;
} ;
static void handle_cause ( int cause , struct cause_args * num )
{
2012-02-20 23:43:27 +00:00
struct ast_cdr * cdr = ast_channel_cdr ( num - > chan ) ;
2006-11-03 22:36:17 +00:00
switch ( cause ) {
case AST_CAUSE_BUSY :
if ( cdr )
ast_cdr_busy ( cdr ) ;
num - > busy + + ;
break ;
case AST_CAUSE_CONGESTION :
if ( cdr )
ast_cdr_failed ( cdr ) ;
num - > congestion + + ;
break ;
2008-07-08 20:30:29 +00:00
case AST_CAUSE_NO_ROUTE_DESTINATION :
2006-11-03 22:36:17 +00:00
case AST_CAUSE_UNREGISTERED :
if ( cdr )
ast_cdr_failed ( cdr ) ;
num - > nochan + + ;
break ;
2009-04-20 21:24:34 +00:00
case AST_CAUSE_NO_ANSWER :
2009-04-20 21:29:29 +00:00
if ( cdr ) {
ast_cdr_noanswer ( cdr ) ;
}
break ;
2006-11-03 22:36:17 +00:00
case AST_CAUSE_NORMAL_CLEARING :
break ;
default :
num - > nochan + + ;
break ;
}
}
2005-01-18 03:12:53 +00:00
2008-02-09 11:27:10 +00:00
static int onedigit_goto ( struct ast_channel * chan , const char * context , char exten , int pri )
2005-01-18 03:12:53 +00:00
{
2005-04-29 15:04:26 +00:00
char rexten [ 2 ] = { exten , ' \0 ' } ;
2005-01-18 03:12:53 +00:00
if ( context ) {
2005-06-01 18:02:46 +00:00
if ( ! ast_goto_if_exists ( chan , context , rexten , pri ) )
2005-01-18 03:12:53 +00:00
return 1 ;
} else {
2012-02-13 17:27:06 +00:00
if ( ! ast_goto_if_exists ( chan , ast_channel_context ( chan ) , rexten , pri ) )
2005-01-18 03:12:53 +00:00
return 1 ;
2012-02-13 17:27:06 +00:00
else if ( ! ast_strlen_zero ( ast_channel_macrocontext ( chan ) ) ) {
if ( ! ast_goto_if_exists ( chan , ast_channel_macrocontext ( chan ) , rexten , pri ) )
2005-01-18 03:12:53 +00:00
return 1 ;
}
}
return 0 ;
}
2004-10-26 22:25:43 +00:00
2009-04-09 17:39:10 +00:00
/* do not call with chan lock held */
2006-04-19 14:14:40 +00:00
static const char * get_cid_name ( char * name , int namelen , struct ast_channel * chan )
2005-02-01 01:53:25 +00:00
{
2009-04-09 20:40:34 +00:00
const char * context ;
const char * exten ;
ast_channel_lock ( chan ) ;
2012-02-13 17:27:06 +00:00
context = ast_strdupa ( S_OR ( ast_channel_macrocontext ( chan ) , ast_channel_context ( chan ) ) ) ;
exten = ast_strdupa ( S_OR ( ast_channel_macroexten ( chan ) , ast_channel_exten ( chan ) ) ) ;
2009-04-09 20:40:34 +00:00
ast_channel_unlock ( chan ) ;
2005-02-01 01:53:25 +00:00
2006-04-19 14:14:40 +00:00
return ast_get_hint ( NULL , 0 , name , namelen , chan , context , exten ) ? name : " " ;
2005-02-01 01:53:25 +00:00
}
2007-12-06 15:04:34 +00:00
static void senddialevent ( struct ast_channel * src , struct ast_channel * dst , const char * dialstring )
2005-02-07 15:19:34 +00:00
{
2009-11-13 20:42:03 +00:00
struct ast_channel * chans [ ] = { src , dst } ;
ast_manager_event_multichan ( EVENT_FLAG_CALL , " Dial " , 2 , chans ,
2008-02-09 11:27:10 +00:00
" SubEvent: Begin \r \n "
" Channel: %s \r \n "
" Destination: %s \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-02-09 11:27:10 +00:00
" UniqueID: %s \r \n "
" DestUniqueID: %s \r \n "
" Dialstring: %s \r \n " ,
2012-01-09 22:15:50 +00:00
ast_channel_name ( src ) , ast_channel_name ( dst ) ,
2012-02-29 16:52:47 +00:00
S_COR ( ast_channel_caller ( src ) - > id . number . valid , ast_channel_caller ( src ) - > id . number . str , " <unknown> " ) ,
S_COR ( ast_channel_caller ( src ) - > id . name . valid , ast_channel_caller ( src ) - > id . name . str , " <unknown> " ) ,
S_COR ( ast_channel_connected ( src ) - > id . number . valid , ast_channel_connected ( src ) - > id . number . str , " <unknown> " ) ,
S_COR ( ast_channel_connected ( src ) - > id . name . valid , ast_channel_connected ( src ) - > id . name . str , " <unknown> " ) ,
2012-01-24 20:12:09 +00:00
ast_channel_uniqueid ( src ) , ast_channel_uniqueid ( dst ) ,
2010-07-14 15:48:36 +00:00
dialstring ? dialstring : " " ) ;
2005-02-07 15:19:34 +00:00
}
2009-11-13 20:42:03 +00:00
static void senddialendevent ( struct ast_channel * src , const char * dialstatus )
2006-10-30 23:11:55 +00:00
{
2009-11-13 20:42:03 +00:00
ast_manager_event ( src , EVENT_FLAG_CALL , " Dial " ,
2008-02-09 11:27:10 +00:00
" SubEvent: End \r \n "
" Channel: %s \r \n "
" UniqueID: %s \r \n "
" DialStatus: %s \r \n " ,
2012-01-24 20:12:09 +00:00
ast_channel_name ( src ) , ast_channel_uniqueid ( src ) , dialstatus ) ;
2008-02-09 11:27:10 +00:00
}
2006-10-30 23:11:55 +00:00
2006-11-21 11:53:06 +00:00
/*!
* helper function for wait_for_answer ( )
*
2012-03-14 17:39:45 +00:00
* \ param o Outgoing call channel list .
* \ param num Incoming call channel cause accumulation
* \ param peerflags Dial option flags
* \ param single_caller_bored From wait_for_answer : single & & ! caller_entertained
* \ param to Remaining call timeout time .
* \ param forced_clid OPT_FORCECLID caller id to send
* \ param stored_clid Caller id representing the called party if needed
*
2006-11-21 11:53:06 +00:00
* XXX this code is highly suspicious , as it essentially overwrites
* the outgoing channel without properly deleting it .
2009-06-03 20:30:10 +00:00
*
2012-03-14 17:39:45 +00:00
* \ todo eventually this function should be intergrated into and replaced by ast_call_forward ( )
2006-11-21 11:53:06 +00:00
*/
2006-12-19 16:36:45 +00:00
static void do_forward ( struct chanlist * o ,
2012-03-14 17:39:45 +00:00
struct cause_args * num , struct ast_flags64 * peerflags , int single_caller_bored , int * to ,
2011-03-18 02:31:27 +00:00
struct ast_party_id * forced_clid , struct ast_party_id * stored_clid )
2006-11-04 00:01:40 +00:00
{
char tmpchan [ 256 ] ;
2007-02-27 22:17:42 +00:00
struct ast_channel * original = o - > chan ;
2006-11-04 00:01:40 +00:00
struct ast_channel * c = o - > chan ; /* the winner */
struct ast_channel * in = num - > chan ; /* the input channel */
char * stuff ;
char * tech ;
int cause ;
2011-03-18 02:31:27 +00:00
struct ast_party_caller caller ;
2006-11-04 00:01:40 +00:00
2012-01-24 20:12:09 +00:00
ast_copy_string ( tmpchan , ast_channel_call_forward ( c ) , sizeof ( tmpchan ) ) ;
2006-11-04 00:01:40 +00:00
if ( ( stuff = strchr ( tmpchan , ' / ' ) ) ) {
* stuff + + = ' \0 ' ;
tech = tmpchan ;
} else {
2008-06-18 13:09:02 +00:00
const char * forward_context ;
ast_channel_lock ( c ) ;
forward_context = pbx_builtin_getvar_helper ( c , " FORWARD_CONTEXT " ) ;
2009-05-30 03:26:06 +00:00
if ( ast_strlen_zero ( forward_context ) ) {
forward_context = NULL ;
}
2012-02-13 17:27:06 +00:00
snprintf ( tmpchan , sizeof ( tmpchan ) , " %s@%s " , ast_channel_call_forward ( c ) , forward_context ? forward_context : ast_channel_context ( c ) ) ;
2008-06-18 13:09:02 +00:00
ast_channel_unlock ( c ) ;
2006-11-04 00:01:40 +00:00
stuff = tmpchan ;
tech = " Local " ;
}
2009-06-26 15:28:53 +00:00
2012-01-24 20:12:09 +00:00
ast_cel_report_event ( in , AST_CEL_FORWARD , NULL , ast_channel_call_forward ( c ) , NULL ) ;
2009-06-26 15:28:53 +00:00
2006-11-04 00:01:40 +00:00
/* Before processing channel, go ahead and check for forwarding */
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " Now forwarding %s to '%s/%s' (thanks to %s) \n " , ast_channel_name ( in ) , tech , stuff , ast_channel_name ( c ) ) ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
/* If we have been told to ignore forwards, just set this channel to null and continue processing extensions normally */
if ( ast_test_flag64 ( peerflags , OPT_IGNORE_FORWARDING ) ) {
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " Forwarding %s to '%s/%s' prevented. \n " , ast_channel_name ( in ) , tech , stuff ) ;
2006-11-04 00:01:40 +00:00
c = o - > chan = NULL ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
cause = AST_CAUSE_BUSY ;
} else {
/* Setup parameters */
2012-02-20 23:43:27 +00:00
c = o - > chan = ast_request ( tech , ast_channel_nativeformats ( in ) , in , stuff , & cause ) ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
if ( c ) {
2012-03-14 17:39:45 +00:00
if ( single_caller_bored ) {
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
ast_channel_make_compatible ( o - > chan , in ) ;
2012-03-14 17:39:45 +00:00
}
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
ast_channel_inherit_variables ( in , o - > chan ) ;
ast_channel_datastore_inherit ( in , o - > chan ) ;
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
/* When a call is forwarded, we don't want to track new interfaces
* dialed for CC purposes . Setting the done flag will ensure that
* any Dial operations that happen later won ' t record CC interfaces .
*/
ast_ignore_cc ( o - > chan ) ;
2012-01-09 22:15:50 +00:00
ast_log ( LOG_NOTICE , " Not accepting call completion offers from call-forward recipient %s \n " , ast_channel_name ( o - > chan ) ) ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
} else
2010-07-23 22:24:52 +00:00
ast_log ( LOG_NOTICE ,
" Forwarding failed to create channel to dial '%s/%s' (cause = %d) \n " ,
tech , stuff , cause ) ;
2006-11-04 00:01:40 +00:00
}
if ( ! c ) {
2008-02-09 11:27:10 +00:00
ast_clear_flag64 ( o , DIAL_STILLGOING ) ;
2006-11-04 00:01:40 +00:00
handle_cause ( cause , num ) ;
2008-11-26 19:57:11 +00:00
ast_hangup ( original ) ;
2006-11-04 00:01:40 +00:00
} else {
2010-09-21 20:33:20 +00:00
struct ast_party_redirecting redirecting ;
2012-03-14 17:39:45 +00:00
if ( single_caller_bored & & CAN_EARLY_BRIDGE ( peerflags , c , in ) ) {
2009-04-02 17:20:52 +00:00
ast_rtp_instance_early_bridge_make_compatible ( c , in ) ;
}
2009-04-03 22:41:46 +00:00
2012-02-29 16:52:47 +00:00
ast_channel_set_redirecting ( c , ast_channel_redirecting ( original ) , NULL ) ;
2009-04-03 22:41:46 +00:00
ast_channel_lock ( c ) ;
while ( ast_channel_trylock ( in ) ) {
CHANNEL_DEADLOCK_AVOIDANCE ( c ) ;
}
2012-02-29 16:52:47 +00:00
if ( ! ast_channel_redirecting ( c ) - > from . number . valid
| | ast_strlen_zero ( ast_channel_redirecting ( c ) - > from . number . str ) ) {
2010-04-03 02:12:33 +00:00
/*
* The call was not previously redirected so it is
* now redirected from this number .
*/
2012-02-29 16:52:47 +00:00
ast_party_number_free ( & ast_channel_redirecting ( c ) - > from . number ) ;
ast_party_number_init ( & ast_channel_redirecting ( c ) - > from . number ) ;
ast_channel_redirecting ( c ) - > from . number . valid = 1 ;
ast_channel_redirecting ( c ) - > from . number . str =
2012-02-13 17:27:06 +00:00
ast_strdup ( S_OR ( ast_channel_macroexten ( in ) , ast_channel_exten ( in ) ) ) ;
2010-04-03 02:12:33 +00:00
}
2009-04-03 22:41:46 +00:00
2012-02-29 16:52:47 +00:00
ast_channel_dialed ( c ) - > transit_network_select = ast_channel_dialed ( in ) - > transit_network_select ;
2009-04-03 22:41:46 +00:00
2011-03-18 02:31:27 +00:00
/* Determine CallerID to store in outgoing channel. */
2012-02-29 16:52:47 +00:00
ast_party_caller_set_init ( & caller , ast_channel_caller ( c ) ) ;
2011-03-18 02:31:27 +00:00
if ( ast_test_flag64 ( peerflags , OPT_ORIGINAL_CLID ) ) {
caller . id = * stored_clid ;
ast_channel_set_caller_event ( c , & caller , NULL ) ;
2012-02-29 16:52:47 +00:00
} else if ( ast_strlen_zero ( S_COR ( ast_channel_caller ( c ) - > id . number . valid ,
ast_channel_caller ( c ) - > id . number . str , NULL ) ) ) {
2011-03-18 02:31:27 +00:00
/*
* The new channel has no preset CallerID number by the channel
* driver . Use the dialplan extension and hint name .
*/
caller . id = * stored_clid ;
ast_channel_set_caller_event ( c , & caller , NULL ) ;
}
/* Determine CallerID for outgoing channel to send. */
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( o , OPT_FORCECLID ) ) {
2011-03-18 02:31:27 +00:00
struct ast_party_connected_line connected ;
ast_party_connected_line_init ( & connected ) ;
connected . id = * forced_clid ;
2012-02-29 16:52:47 +00:00
ast_party_connected_line_copy ( ast_channel_connected ( c ) , & connected ) ;
2006-11-04 00:01:40 +00:00
} else {
2012-02-29 16:52:47 +00:00
ast_connected_line_copy_from_caller ( ast_channel_connected ( c ) , ast_channel_caller ( in ) ) ;
2006-11-04 00:01:40 +00:00
}
2011-03-18 02:31:27 +00:00
2012-01-24 20:12:09 +00:00
ast_channel_accountcode_set ( c , ast_channel_accountcode ( in ) ) ;
2011-03-18 02:31:27 +00:00
2012-02-13 17:27:06 +00:00
ast_channel_appl_set ( c , " AppDial " ) ;
ast_channel_data_set ( c , " (Outgoing Line) " ) ;
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
/*
* We must unlock c before calling ast_channel_redirecting_macro , because
* we put c into autoservice there . That is pretty much a guaranteed
* deadlock . This is why the handling of c ' s lock may seem a bit unusual
* here .
*/
2010-09-21 20:33:20 +00:00
ast_party_redirecting_init ( & redirecting ) ;
2012-02-29 16:52:47 +00:00
ast_party_redirecting_copy ( & redirecting , ast_channel_redirecting ( c ) ) ;
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
ast_channel_unlock ( c ) ;
2012-02-27 16:50:19 +00:00
if ( ast_channel_redirecting_sub ( c , in , & redirecting , 0 ) & &
ast_channel_redirecting_macro ( c , in , & redirecting , 1 , 0 ) ) {
2010-09-21 20:33:20 +00:00
ast_channel_update_redirecting ( in , & redirecting , NULL ) ;
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
}
2010-09-21 20:33:20 +00:00
ast_party_redirecting_free ( & redirecting ) ;
ast_channel_unlock ( in ) ;
2009-04-03 22:41:46 +00:00
ast_clear_flag64 ( peerflags , OPT_IGNORE_CONNECTEDLINE ) ;
2009-04-15 15:24:50 +00:00
if ( ast_test_flag64 ( peerflags , OPT_CANCEL_TIMEOUT ) ) {
* to = - 1 ;
}
2006-11-04 00:01:40 +00:00
2010-07-23 22:24:52 +00:00
if ( ast_call ( c , stuff , 0 ) ) {
ast_log ( LOG_NOTICE , " Forwarding failed to dial '%s/%s' \n " ,
tech , stuff ) ;
2008-02-09 11:27:10 +00:00
ast_clear_flag64 ( o , DIAL_STILLGOING ) ;
2007-02-27 22:17:42 +00:00
ast_hangup ( original ) ;
2008-11-26 19:57:11 +00:00
ast_hangup ( c ) ;
2006-11-04 00:01:40 +00:00
c = o - > chan = NULL ;
num - > nochan + + ;
} else {
2009-04-10 15:49:16 +00:00
ast_channel_lock ( c ) ;
while ( ast_channel_trylock ( in ) ) {
CHANNEL_DEADLOCK_AVOIDANCE ( c ) ;
}
2007-12-06 15:04:34 +00:00
senddialevent ( in , c , stuff ) ;
2011-03-18 02:31:27 +00:00
ast_channel_unlock ( in ) ;
ast_channel_unlock ( c ) ;
2006-11-21 11:53:06 +00:00
/* Hangup the original channel now, in case we needed it */
2007-02-27 22:17:42 +00:00
ast_hangup ( original ) ;
2006-11-04 00:01:40 +00:00
}
2012-03-14 17:39:45 +00:00
if ( single_caller_bored ) {
2009-01-23 19:09:18 +00:00
ast_indicate ( in , - 1 ) ;
}
2006-11-04 00:01:40 +00:00
}
}
2006-11-04 11:00:49 +00:00
/* argument used for some functions. */
struct privacy_args {
2008-02-09 11:27:10 +00:00
int sentringing ;
int privdb_val ;
char privcid [ 256 ] ;
char privintro [ 1024 ] ;
char status [ 256 ] ;
2006-11-04 11:00:49 +00:00
} ;
static struct ast_channel * wait_for_answer ( struct ast_channel * in ,
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
struct chanlist * outgoing , int * to , struct ast_flags64 * peerflags ,
2009-12-19 08:59:31 +00:00
char * opt_args [ ] ,
2006-11-04 11:00:49 +00:00
struct privacy_args * pa ,
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
const struct cause_args * num_in , int * result , char * dtmf_progress ,
2011-03-18 02:31:27 +00:00
const int ignore_cc ,
struct ast_party_id * forced_clid , struct ast_party_id * stored_clid )
1999-12-04 21:35:07 +00:00
{
2006-11-03 22:36:17 +00:00
struct cause_args num = * num_in ;
int prestart = num . busy + num . congestion + num . nochan ;
1999-12-04 21:35:07 +00:00
int orig = * to ;
struct ast_channel * peer = NULL ;
2006-04-19 16:10:11 +00:00
/* single is set if only one destination is enabled */
2009-04-03 22:41:46 +00:00
int single = outgoing & & ! outgoing - > next ;
2012-03-14 17:39:45 +00:00
int caller_entertained = outgoing
& & ast_test_flag64 ( outgoing , OPT_MUSICBACK | OPT_RINGBACK ) ;
2007-08-08 21:44:58 +00:00
# ifdef HAVE_EPOLL
struct chanlist * epollo ;
# endif
2009-04-03 22:41:46 +00:00
struct ast_party_connected_line connected_caller ;
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_str * featurecode = ast_str_alloca ( FEATURE_MAX_LEN + 1 ) ;
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
int cc_recall_core_id ;
int is_cc_recall ;
int cc_frame_received = 0 ;
int num_ringing = 0 ;
2009-05-05 20:54:07 +00:00
ast_party_connected_line_init ( & connected_caller ) ;
2001-05-07 03:15:48 +00:00
if ( single ) {
2003-11-05 20:53:49 +00:00
/* Turn off hold music, etc */
2012-03-14 17:39:45 +00:00
if ( ! caller_entertained ) {
2009-04-03 22:41:46 +00:00
ast_deactivate_generator ( in ) ;
2009-12-19 08:59:31 +00:00
/* If we are calling a single channel, and not providing ringback or music, */
/* then, make them compatible for in-band tone purpose */
Merged revisions 296002 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r296002 | russell | 2010-11-24 11:13:08 -0600 (Wed, 24 Nov 2010) | 52 lines
Merged revisions 296001 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r296001 | russell | 2010-11-24 11:03:16 -0600 (Wed, 24 Nov 2010) | 45 lines
Merged revisions 296000 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r296000 | russell | 2010-11-24 10:48:39 -0600 (Wed, 24 Nov 2010) | 38 lines
Handle failures building translation paths more effectively.
The problem scenario occurred on a heavily loaded system that was using the
codec_dahdi module and exceeded the hardware transcoding capacity. The failure
mode at that point was not good. The report came in to us as an Asterisk
lock-up. The "core show locks" shows a ton of threads locked up (but no
obvious deadlock). Upon deeper investigation, when the system is in this
state, the CPU was maxed out. The CPU was being consumed by the Asterisk
logger spewing messages on every audio frame for calls set up after transcoder
capacity was reached.
The purpose of this patch is to make Asterisk handle failures to create a
translation path in a more graceful manner. If we can't translate, then the
call just needs to be dropped, as it's not going to work. These are the
changes:
1) In set_format() of channel.c (which is called by set_read_format() and
set_write_format()), it was ignoring if ast_translator_build_path() failed and
returned NULL. It now pays attention to that case and returns a result
reflecting failure. With this change in place, the bridging code will
immediately detect a failure and end the bridge instead of proceeding to try to
bridge frames that can't be translated and making channel drivers freak out by
sending them frames in a format they weren't expecting.
2) In ast_indicate_data() of channel.c, failure of ast_playtones_start() was
ignored. It is now reflected in the return value of the function. This didn't
turn out to have any affect on the bug, but seemed like a good change to leave
in.
3) In app_dial(), when only sending a call to a single endpoint, it will
attempt to do some bridging of its own of early audio. It uses
make_compatible() when it's going to do this. However, it ignored failure from
make compatible. So, even with the fix from #1, if there was early audio going
through app_dial, there would still be a period of invalid frames passing
through. After detecting failure here, Dial() exits.
ABE-2658
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@296034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-11-24 17:23:39 +00:00
if ( ast_channel_make_compatible ( outgoing - > chan , in ) < 0 ) {
/* If these channels can not be made compatible,
* there is no point in continuing . The bridge
* will just fail if it gets that far .
*/
* to = - 1 ;
strcpy ( pa - > status , " CONGESTION " ) ;
2012-02-20 23:43:27 +00:00
ast_cdr_failed ( ast_channel_cdr ( in ) ) ;
Merged revisions 296002 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r296002 | russell | 2010-11-24 11:13:08 -0600 (Wed, 24 Nov 2010) | 52 lines
Merged revisions 296001 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r296001 | russell | 2010-11-24 11:03:16 -0600 (Wed, 24 Nov 2010) | 45 lines
Merged revisions 296000 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r296000 | russell | 2010-11-24 10:48:39 -0600 (Wed, 24 Nov 2010) | 38 lines
Handle failures building translation paths more effectively.
The problem scenario occurred on a heavily loaded system that was using the
codec_dahdi module and exceeded the hardware transcoding capacity. The failure
mode at that point was not good. The report came in to us as an Asterisk
lock-up. The "core show locks" shows a ton of threads locked up (but no
obvious deadlock). Upon deeper investigation, when the system is in this
state, the CPU was maxed out. The CPU was being consumed by the Asterisk
logger spewing messages on every audio frame for calls set up after transcoder
capacity was reached.
The purpose of this patch is to make Asterisk handle failures to create a
translation path in a more graceful manner. If we can't translate, then the
call just needs to be dropped, as it's not going to work. These are the
changes:
1) In set_format() of channel.c (which is called by set_read_format() and
set_write_format()), it was ignoring if ast_translator_build_path() failed and
returned NULL. It now pays attention to that case and returns a result
reflecting failure. With this change in place, the bridging code will
immediately detect a failure and end the bridge instead of proceeding to try to
bridge frames that can't be translated and making channel drivers freak out by
sending them frames in a format they weren't expecting.
2) In ast_indicate_data() of channel.c, failure of ast_playtones_start() was
ignored. It is now reflected in the return value of the function. This didn't
turn out to have any affect on the bug, but seemed like a good change to leave
in.
3) In app_dial(), when only sending a call to a single endpoint, it will
attempt to do some bridging of its own of early audio. It uses
make_compatible() when it's going to do this. However, it ignored failure from
make compatible. So, even with the fix from #1, if there was early audio going
through app_dial, there would still be a period of invalid frames passing
through. After detecting failure here, Dial() exits.
ABE-2658
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@296034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-11-24 17:23:39 +00:00
return NULL ;
}
2009-12-19 08:59:31 +00:00
}
2009-04-03 22:41:46 +00:00
2010-05-20 19:40:03 +00:00
if ( ! ast_test_flag64 ( peerflags , OPT_IGNORE_CONNECTEDLINE ) & & ! ast_test_flag64 ( outgoing , DIAL_CALLERID_ABSENT ) ) {
2009-04-03 22:41:46 +00:00
ast_channel_lock ( outgoing - > chan ) ;
2012-02-29 16:52:47 +00:00
ast_connected_line_copy_from_caller ( & connected_caller , ast_channel_caller ( outgoing - > chan ) ) ;
2009-04-03 22:41:46 +00:00
ast_channel_unlock ( outgoing - > chan ) ;
connected_caller . source = AST_CONNECTED_LINE_UPDATE_SOURCE_ANSWER ;
2010-07-14 15:48:36 +00:00
ast_channel_update_connected_line ( in , & connected_caller , NULL ) ;
2009-04-03 22:41:46 +00:00
ast_party_connected_line_free ( & connected_caller ) ;
}
2001-05-07 03:15:48 +00:00
}
2007-08-08 21:44:58 +00:00
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
is_cc_recall = ast_cc_is_recall ( in , & cc_recall_core_id , NULL ) ;
2007-08-08 21:44:58 +00:00
# ifdef HAVE_EPOLL
for ( epollo = outgoing ; epollo ; epollo = epollo - > next )
ast_poll_channel_add ( in , epollo - > chan ) ;
2008-02-09 11:27:10 +00:00
# endif
2005-01-18 03:12:53 +00:00
while ( * to & & ! peer ) {
2006-12-19 16:36:45 +00:00
struct chanlist * o ;
2008-02-09 11:27:10 +00:00
int pos = 0 ; /* how many channels do we handle */
2006-04-19 14:02:49 +00:00
int numlines = prestart ;
2006-04-19 16:10:11 +00:00
struct ast_channel * winner ;
struct ast_channel * watchers [ AST_MAX_WATCHERS ] ;
2006-04-19 14:02:49 +00:00
watchers [ pos + + ] = in ;
for ( o = outgoing ; o ; o = o - > next ) {
2001-05-07 03:15:48 +00:00
/* Keep track of important channels */
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( o , DIAL_STILLGOING ) & & o - > chan )
2001-05-07 03:15:48 +00:00
watchers [ pos + + ] = o - > chan ;
numlines + + ;
1999-12-04 21:35:07 +00:00
}
2008-02-09 11:27:10 +00:00
if ( pos = = 1 ) { /* only the input channel is available */
2006-11-03 22:36:17 +00:00
if ( numlines = = ( num . busy + num . congestion + num . nochan ) ) {
2007-07-26 15:49:18 +00:00
ast_verb ( 2 , " Everyone is busy/congested at this time (%d:%d/%d/%d) \n " , numlines , num . busy , num . congestion , num . nochan ) ;
2006-11-03 22:36:17 +00:00
if ( num . busy )
2008-02-09 11:27:10 +00:00
strcpy ( pa - > status , " BUSY " ) ;
2006-11-03 22:36:17 +00:00
else if ( num . congestion )
2006-11-04 11:00:49 +00:00
strcpy ( pa - > status , " CONGESTION " ) ;
2006-11-03 22:36:17 +00:00
else if ( num . nochan )
2006-11-04 11:00:49 +00:00
strcpy ( pa - > status , " CHANUNAVAIL " ) ;
1999-12-04 21:35:07 +00:00
} else {
2007-07-26 15:49:18 +00:00
ast_verb ( 3 , " No one is available to answer at this time (%d:%d/%d/%d) \n " , numlines , num . busy , num . congestion , num . nochan ) ;
1999-12-04 21:35:07 +00:00
}
2001-05-07 03:15:48 +00:00
* to = 0 ;
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
if ( is_cc_recall ) {
ast_cc_failed ( cc_recall_core_id , " Everyone is busy/congested for the recall. How sad " ) ;
}
1999-12-04 21:35:07 +00:00
return NULL ;
}
2001-05-07 03:15:48 +00:00
winner = ast_waitfor_n ( watchers , pos , to ) ;
2006-04-19 14:02:49 +00:00
for ( o = outgoing ; o ; o = o - > next ) {
struct ast_frame * f ;
struct ast_channel * c = o - > chan ;
if ( c = = NULL )
continue ;
2012-02-20 23:43:27 +00:00
if ( ast_test_flag64 ( o , DIAL_STILLGOING ) & & ast_channel_state ( c ) = = AST_STATE_UP ) {
2002-09-02 15:20:28 +00:00
if ( ! peer ) {
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " %s answered %s \n " , ast_channel_name ( c ) , ast_channel_name ( in ) ) ;
2009-04-03 22:41:46 +00:00
if ( ! single & & ! ast_test_flag64 ( peerflags , OPT_IGNORE_CONNECTEDLINE ) ) {
2010-05-20 19:40:03 +00:00
if ( o - > pending_connected_update ) {
2012-02-27 16:50:19 +00:00
if ( ast_channel_connected_line_sub ( c , in , & o - > connected , 0 ) & &
ast_channel_connected_line_macro ( c , in , & o - > connected , 1 , 0 ) ) {
2010-07-14 15:48:36 +00:00
ast_channel_update_connected_line ( in , & o - > connected , NULL ) ;
2009-06-01 20:57:31 +00:00
}
2010-05-20 19:40:03 +00:00
} else if ( ! ast_test_flag64 ( o , DIAL_CALLERID_ABSENT ) ) {
2009-04-03 22:41:46 +00:00
ast_channel_lock ( c ) ;
2012-02-29 16:52:47 +00:00
ast_connected_line_copy_from_caller ( & connected_caller , ast_channel_caller ( c ) ) ;
2009-04-03 22:41:46 +00:00
ast_channel_unlock ( c ) ;
connected_caller . source = AST_CONNECTED_LINE_UPDATE_SOURCE_ANSWER ;
2010-07-14 15:48:36 +00:00
ast_channel_update_connected_line ( in , & connected_caller , NULL ) ;
2009-04-03 22:41:46 +00:00
ast_party_connected_line_free ( & connected_caller ) ;
}
}
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
if ( o - > aoc_s_rate_list ) {
size_t encoded_size ;
struct ast_aoc_encoded * encoded ;
if ( ( encoded = ast_aoc_encode ( o - > aoc_s_rate_list , & encoded_size , o - > chan ) ) ) {
ast_indicate_data ( in , AST_CONTROL_AOC , encoded , encoded_size ) ;
ast_aoc_destroy_encoded ( encoded ) ;
}
}
2006-04-19 14:02:49 +00:00
peer = c ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
ast_copy_flags64 ( peerflags , o ,
2008-02-09 11:27:10 +00:00
OPT_CALLEE_TRANSFER | OPT_CALLER_TRANSFER |
OPT_CALLEE_HANGUP | OPT_CALLER_HANGUP |
OPT_CALLEE_MONITOR | OPT_CALLER_MONITOR |
OPT_CALLEE_PARK | OPT_CALLER_PARK |
OPT_CALLEE_MIXMONITOR | OPT_CALLER_MIXMONITOR |
DIAL_NOFORWARDHTML ) ;
2012-01-24 20:12:09 +00:00
ast_channel_dialcontext_set ( c , " " ) ;
2012-02-13 17:27:06 +00:00
ast_channel_exten_set ( c , " " ) ;
2002-09-02 15:20:28 +00:00
}
2006-04-19 14:02:49 +00:00
continue ;
}
if ( c ! = winner )
continue ;
2006-11-04 00:01:40 +00:00
/* here, o->chan == c == winner */
2012-01-24 20:12:09 +00:00
if ( ! ast_strlen_zero ( ast_channel_call_forward ( c ) ) ) {
2009-07-14 17:03:58 +00:00
pa - > sentringing = 0 ;
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
if ( ! ignore_cc & & ( f = ast_read ( c ) ) ) {
if ( f - > frametype = = AST_FRAME_CONTROL & & f - > subclass . integer = = AST_CONTROL_CC ) {
/* This channel is forwarding the call, and is capable of CC, so
* be sure to add the new device interface to the list
*/
ast_handle_cc_control_frame ( in , c , f - > data . ptr ) ;
}
ast_frfree ( f ) ;
}
2012-03-14 17:39:45 +00:00
do_forward ( o , & num , peerflags , single & & ! caller_entertained , to ,
forced_clid , stored_clid ) ;
2006-04-19 14:53:18 +00:00
continue ;
2006-04-19 14:02:49 +00:00
}
f = ast_read ( winner ) ;
if ( ! f ) {
2012-02-20 23:43:27 +00:00
ast_channel_hangupcause_set ( in , ast_channel_hangupcause ( c ) ) ;
2007-12-03 14:14:43 +00:00
# ifdef HAVE_EPOLL
ast_poll_channel_del ( in , c ) ;
# endif
2006-04-19 14:53:18 +00:00
ast_hangup ( c ) ;
c = o - > chan = NULL ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
ast_clear_flag64 ( o , DIAL_STILLGOING ) ;
2012-02-20 23:43:27 +00:00
handle_cause ( ast_channel_hangupcause ( in ) , & num ) ;
2006-04-19 14:53:18 +00:00
continue ;
}
2012-03-14 17:39:45 +00:00
switch ( f - > frametype ) {
case AST_FRAME_CONTROL :
2009-11-04 14:05:12 +00:00
switch ( f - > subclass . integer ) {
2006-04-19 14:53:18 +00:00
case AST_CONTROL_ANSWER :
/* This is our guy if someone answered. */
if ( ! peer ) {
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " %s answered %s \n " , ast_channel_name ( c ) , ast_channel_name ( in ) ) ;
2009-04-03 22:41:46 +00:00
if ( ! single & & ! ast_test_flag64 ( peerflags , OPT_IGNORE_CONNECTEDLINE ) ) {
2010-05-20 19:40:03 +00:00
if ( o - > pending_connected_update ) {
2012-02-27 16:50:19 +00:00
if ( ast_channel_connected_line_sub ( c , in , & o - > connected , 0 ) & &
ast_channel_connected_line_macro ( c , in , & o - > connected , 1 , 0 ) ) {
2010-07-14 15:48:36 +00:00
ast_channel_update_connected_line ( in , & o - > connected , NULL ) ;
2009-06-01 20:57:31 +00:00
}
2010-05-20 19:40:03 +00:00
} else if ( ! ast_test_flag64 ( o , DIAL_CALLERID_ABSENT ) ) {
2009-04-03 22:41:46 +00:00
ast_channel_lock ( c ) ;
2012-02-29 16:52:47 +00:00
ast_connected_line_copy_from_caller ( & connected_caller , ast_channel_caller ( c ) ) ;
2009-04-03 22:41:46 +00:00
ast_channel_unlock ( c ) ;
connected_caller . source = AST_CONNECTED_LINE_UPDATE_SOURCE_ANSWER ;
2010-07-14 15:48:36 +00:00
ast_channel_update_connected_line ( in , & connected_caller , NULL ) ;
2009-04-03 22:41:46 +00:00
ast_party_connected_line_free ( & connected_caller ) ;
}
}
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
if ( o - > aoc_s_rate_list ) {
size_t encoded_size ;
struct ast_aoc_encoded * encoded ;
if ( ( encoded = ast_aoc_encode ( o - > aoc_s_rate_list , & encoded_size , o - > chan ) ) ) {
ast_indicate_data ( in , AST_CONTROL_AOC , encoded , encoded_size ) ;
ast_aoc_destroy_encoded ( encoded ) ;
}
}
2006-04-19 14:53:18 +00:00
peer = c ;
2012-02-20 23:43:27 +00:00
if ( ast_channel_cdr ( peer ) ) {
ast_channel_cdr ( peer ) - > answer = ast_tvnow ( ) ;
ast_channel_cdr ( peer ) - > disposition = AST_CDR_ANSWERED ;
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
}
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
ast_copy_flags64 ( peerflags , o ,
2008-02-09 11:27:10 +00:00
OPT_CALLEE_TRANSFER | OPT_CALLER_TRANSFER |
OPT_CALLEE_HANGUP | OPT_CALLER_HANGUP |
OPT_CALLEE_MONITOR | OPT_CALLER_MONITOR |
OPT_CALLEE_PARK | OPT_CALLER_PARK |
OPT_CALLEE_MIXMONITOR | OPT_CALLER_MIXMONITOR |
DIAL_NOFORWARDHTML ) ;
2012-01-24 20:12:09 +00:00
ast_channel_dialcontext_set ( c , " " ) ;
2012-02-13 17:27:06 +00:00
ast_channel_exten_set ( c , " " ) ;
2008-07-14 17:54:11 +00:00
if ( CAN_EARLY_BRIDGE ( peerflags , in , peer ) )
2007-10-01 13:53:09 +00:00
/* Setup early bridge if appropriate */
ast_channel_early_bridge ( in , peer ) ;
2006-04-19 14:53:18 +00:00
}
/* If call has been answered, then the eventual hangup is likely to be normal hangup */
2012-02-20 23:43:27 +00:00
ast_channel_hangupcause_set ( in , AST_CAUSE_NORMAL_CLEARING ) ;
ast_channel_hangupcause_set ( c , AST_CAUSE_NORMAL_CLEARING ) ;
2006-04-19 14:53:18 +00:00
break ;
case AST_CONTROL_BUSY :
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " %s is busy \n " , ast_channel_name ( c ) ) ;
2012-02-20 23:43:27 +00:00
ast_channel_hangupcause_set ( in , ast_channel_hangupcause ( c ) ) ;
2006-04-19 14:53:18 +00:00
ast_hangup ( c ) ;
c = o - > chan = NULL ;
2008-02-09 11:27:10 +00:00
ast_clear_flag64 ( o , DIAL_STILLGOING ) ;
2006-11-03 22:36:17 +00:00
handle_cause ( AST_CAUSE_BUSY , & num ) ;
2006-04-19 14:53:18 +00:00
break ;
case AST_CONTROL_CONGESTION :
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " %s is circuit-busy \n " , ast_channel_name ( c ) ) ;
2012-02-20 23:43:27 +00:00
ast_channel_hangupcause_set ( in , ast_channel_hangupcause ( c ) ) ;
2006-04-19 14:50:17 +00:00
ast_hangup ( c ) ;
c = o - > chan = NULL ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
ast_clear_flag64 ( o , DIAL_STILLGOING ) ;
2006-11-03 22:36:17 +00:00
handle_cause ( AST_CAUSE_CONGESTION , & num ) ;
2006-04-19 14:53:18 +00:00
break ;
case AST_CONTROL_RINGING :
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
/* This is a tricky area to get right when using a native
* CC agent . The reason is that we do the best we can to send only a
* single ringing notification to the caller .
*
* Call completion complicates the logic used here . CCNR is typically
* offered during a ringing message . Let ' s say that party A calls
* parties B , C , and D . B and C do not support CC requests , but D
* does . If we were to receive a ringing notification from B before
* the others , then we would end up sending a ringing message to
* A with no CCNR offer present .
*
* The approach that we have taken is that if we receive a ringing
* response from a party and no CCNR offer is present , we need to
* wait . Specifically , we need to wait until either a ) a called party
* offers CCNR in its ringing response or b ) all called parties have
* responded in some way to our call and none offers CCNR .
*
* The drawback to this is that if one of the parties has a delayed
* response or , god forbid , one just plain doesn ' t respond to our
* outgoing call , then this will result in a significant delay between
* when the caller places the call and hears ringback .
*
* Note also that if CC is disabled for this call , then it is perfectly
* fine for ringing frames to get sent through .
*/
+ + num_ringing ;
if ( ignore_cc | | cc_frame_received | | num_ringing = = numlines ) {
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " %s is ringing \n " , ast_channel_name ( c ) ) ;
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
/* Setup early media if appropriate */
2012-03-14 17:39:45 +00:00
if ( single & & ! caller_entertained
& & CAN_EARLY_BRIDGE ( peerflags , in , c ) ) {
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
ast_channel_early_bridge ( in , c ) ;
2012-03-14 17:39:45 +00:00
}
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
if ( ! ( pa - > sentringing ) & & ! ast_test_flag64 ( outgoing , OPT_MUSICBACK ) & & ast_strlen_zero ( opt_args [ OPT_ARG_RINGBACK ] ) ) {
ast_indicate ( in , AST_CONTROL_RINGING ) ;
pa - > sentringing + + ;
}
2006-04-19 14:53:18 +00:00
}
break ;
case AST_CONTROL_PROGRESS :
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " %s is making progress passing it to %s \n " , ast_channel_name ( c ) , ast_channel_name ( in ) ) ;
2006-05-09 11:44:50 +00:00
/* Setup early media if appropriate */
2012-03-14 17:39:45 +00:00
if ( single & & ! caller_entertained
& & CAN_EARLY_BRIDGE ( peerflags , in , c ) ) {
2006-09-21 19:27:26 +00:00
ast_channel_early_bridge ( in , c ) ;
2012-03-14 17:39:45 +00:00
}
2011-04-18 16:25:06 +00:00
if ( ! ast_test_flag64 ( outgoing , OPT_RINGBACK ) ) {
2009-10-12 23:48:09 +00:00
if ( single | | ( ! single & & ! pa - > sentringing ) ) {
ast_indicate ( in , AST_CONTROL_PROGRESS ) ;
}
2011-04-18 16:25:06 +00:00
}
if ( ! ast_strlen_zero ( dtmf_progress ) ) {
ast_verb ( 3 ,
" Sending DTMF '%s' to the called party as result of receiving a PROGRESS message. \n " ,
dtmf_progress ) ;
ast_dtmf_stream ( c , in , dtmf_progress , 250 , 0 ) ;
}
2006-04-19 14:53:18 +00:00
break ;
case AST_CONTROL_VIDUPDATE :
2008-03-05 22:43:22 +00:00
case AST_CONTROL_SRCUPDATE :
2012-03-14 17:39:45 +00:00
case AST_CONTROL_SRCCHANGE :
if ( ! single | | caller_entertained ) {
break ;
}
ast_verb ( 3 , " %s requested media update control %d, passing it to %s \n " ,
ast_channel_name ( c ) , f - > subclass . integer , ast_channel_name ( in ) ) ;
ast_indicate ( in , f - > subclass . integer ) ;
2008-03-05 22:43:22 +00:00
break ;
2009-04-03 22:41:46 +00:00
case AST_CONTROL_CONNECTED_LINE :
if ( ast_test_flag64 ( peerflags , OPT_IGNORE_CONNECTEDLINE ) ) {
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " Connected line update to %s prevented. \n " , ast_channel_name ( in ) ) ;
2009-04-03 22:41:46 +00:00
} else if ( ! single ) {
struct ast_party_connected_line connected ;
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " %s connected line has changed. Saving it until answer for %s \n " , ast_channel_name ( c ) , ast_channel_name ( in ) ) ;
2009-04-03 22:41:46 +00:00
ast_party_connected_line_set_init ( & connected , & o - > connected ) ;
ast_connected_line_parse_data ( f - > data . ptr , f - > datalen , & connected ) ;
2010-07-14 15:48:36 +00:00
ast_party_connected_line_set ( & o - > connected , & connected , NULL ) ;
2009-04-03 22:41:46 +00:00
ast_party_connected_line_free ( & connected ) ;
2010-05-20 19:40:03 +00:00
o - > pending_connected_update = 1 ;
2009-04-03 22:41:46 +00:00
} else {
2012-02-27 16:50:19 +00:00
if ( ast_channel_connected_line_sub ( c , in , f , 1 ) & &
ast_channel_connected_line_macro ( c , in , f , 1 , 1 ) ) {
2009-06-01 20:57:31 +00:00
ast_indicate_data ( in , AST_CONTROL_CONNECTED_LINE , f - > data . ptr , f - > datalen ) ;
}
2009-04-03 22:41:46 +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 :
{
struct ast_aoc_decoded * decoded = ast_aoc_decode ( f - > data . ptr , f - > datalen , o - > chan ) ;
if ( decoded & & ( ast_aoc_get_msg_type ( decoded ) = = AST_AOC_S ) ) {
ast_aoc_destroy_decoded ( o - > aoc_s_rate_list ) ;
o - > aoc_s_rate_list = decoded ;
} else {
ast_aoc_destroy_decoded ( decoded ) ;
}
}
break ;
2009-04-03 22:41:46 +00:00
case AST_CONTROL_REDIRECTING :
if ( ast_test_flag64 ( peerflags , OPT_IGNORE_CONNECTEDLINE ) ) {
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " Redirecting update to %s prevented. \n " , ast_channel_name ( in ) ) ;
2011-02-04 18:57:39 +00:00
} else if ( single ) {
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " %s redirecting info has changed, passing it to %s \n " , ast_channel_name ( c ) , ast_channel_name ( in ) ) ;
2012-02-27 16:50:19 +00:00
if ( ast_channel_redirecting_sub ( c , in , f , 1 ) & &
ast_channel_redirecting_macro ( c , in , f , 1 , 1 ) ) {
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
ast_indicate_data ( in , AST_CONTROL_REDIRECTING , f - > data . ptr , f - > datalen ) ;
}
2009-07-14 17:03:58 +00:00
pa - > sentringing = 0 ;
2009-04-03 22:41:46 +00:00
}
break ;
2006-04-19 14:53:18 +00:00
case AST_CONTROL_PROCEEDING :
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " %s is proceeding passing it to %s \n " , ast_channel_name ( c ) , ast_channel_name ( in ) ) ;
2012-03-14 17:39:45 +00:00
if ( single & & ! caller_entertained
& & CAN_EARLY_BRIDGE ( peerflags , in , c ) ) {
2006-09-21 19:27:26 +00:00
ast_channel_early_bridge ( in , c ) ;
2012-03-14 17:39:45 +00:00
}
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ! ast_test_flag64 ( outgoing , OPT_RINGBACK ) )
2006-04-19 14:53:18 +00:00
ast_indicate ( in , AST_CONTROL_PROCEEDING ) ;
break ;
case AST_CONTROL_HOLD :
2012-03-14 17:39:45 +00:00
/* XXX this should be saved like AST_CONTROL_CONNECTED_LINE for !single || caller_entertained */
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " Call on %s placed on hold \n " , ast_channel_name ( c ) ) ;
2012-03-14 17:39:45 +00:00
ast_indicate_data ( in , AST_CONTROL_HOLD , f - > data . ptr , f - > datalen ) ;
2006-04-19 14:53:18 +00:00
break ;
case AST_CONTROL_UNHOLD :
2012-03-14 17:39:45 +00:00
/* XXX this should be saved like AST_CONTROL_CONNECTED_LINE for !single || caller_entertained */
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " Call on %s left from hold \n " , ast_channel_name ( c ) ) ;
2006-04-19 14:53:18 +00:00
ast_indicate ( in , AST_CONTROL_UNHOLD ) ;
break ;
case AST_CONTROL_OFFHOOK :
case AST_CONTROL_FLASH :
/* Ignore going off hook and flash */
break ;
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
case AST_CONTROL_CC :
if ( ! ignore_cc ) {
ast_handle_cc_control_frame ( in , c , f - > data . ptr ) ;
cc_frame_received = 1 ;
}
break ;
2006-04-19 14:53:18 +00:00
case - 1 :
2012-03-14 17:39:45 +00:00
if ( single & & ! caller_entertained ) {
2012-01-09 22:15:50 +00:00
ast_verb ( 3 , " %s stopped sounds \n " , ast_channel_name ( c ) ) ;
2006-04-19 14:53:18 +00:00
ast_indicate ( in , - 1 ) ;
2006-11-04 11:00:49 +00:00
pa - > sentringing = 0 ;
2006-04-19 14:53:18 +00:00
}
break ;
default :
2009-11-04 14:05:12 +00:00
ast_debug ( 1 , " Dunno what to do with control type %d \n " , f - > subclass . integer ) ;
2011-02-04 18:57:39 +00:00
break ;
2012-03-14 17:39:45 +00:00
}
break ;
case AST_FRAME_VOICE :
case AST_FRAME_IMAGE :
if ( caller_entertained ) {
2011-02-04 18:57:39 +00:00
break ;
2006-04-19 15:15:03 +00:00
}
2012-03-14 17:39:45 +00:00
/* Fall through */
case AST_FRAME_TEXT :
if ( single & & ast_write ( in , f ) ) {
ast_log ( LOG_WARNING , " Unable to write frametype: %d \n " ,
f - > frametype ) ;
}
break ;
case AST_FRAME_HTML :
if ( single & & ! ast_test_flag64 ( outgoing , DIAL_NOFORWARDHTML )
& & ast_channel_sendhtml ( in , f - > subclass . integer , f - > data . ptr , f - > datalen ) = = - 1 ) {
ast_log ( LOG_WARNING , " Unable to send URL \n " ) ;
}
break ;
default :
break ;
1999-12-04 21:35:07 +00:00
}
2006-04-19 14:02:49 +00:00
ast_frfree ( f ) ;
} /* end for */
2001-05-07 03:15:48 +00:00
if ( winner = = in ) {
2006-04-19 14:02:49 +00:00
struct ast_frame * f = ast_read ( in ) ;
1999-12-04 21:35:07 +00:00
#if 0
if ( f & & ( f - > frametype ! = AST_FRAME_VOICE ) )
2005-09-07 19:13:00 +00:00
printf ( " Frame type: %d, %d \n " , f - > frametype , f - > subclass ) ;
2001-10-15 17:39:25 +00:00
else if ( ! f | | ( f - > frametype ! = AST_FRAME_VOICE ) )
printf ( " Hangup received on %s \n " , in - > name ) ;
1999-12-04 21:35:07 +00:00
# endif
2009-11-04 14:05:12 +00:00
if ( ! f | | ( ( f - > frametype = = AST_FRAME_CONTROL ) & & ( f - > subclass . integer = = AST_CONTROL_HANGUP ) ) ) {
1999-12-04 21:35:07 +00:00
/* Got hung up */
2006-01-17 18:54:56 +00:00
* to = - 1 ;
2006-11-04 11:00:49 +00:00
strcpy ( pa - > status , " CANCEL " ) ;
2012-02-20 23:43:27 +00:00
ast_cdr_noanswer ( ast_channel_cdr ( in ) ) ;
2008-04-24 22:16:48 +00:00
if ( f ) {
2008-05-22 16:29:54 +00:00
if ( f - > data . uint32 ) {
2012-02-20 23:43:27 +00:00
ast_channel_hangupcause_set ( in , f - > data . uint32 ) ;
2008-05-22 16:29:54 +00:00
}
2004-12-06 17:12:21 +00:00
ast_frfree ( f ) ;
2008-04-24 22:16:48 +00:00
}
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
if ( is_cc_recall ) {
ast_cc_completed ( in , " CC completed, although the caller hung up (cancelled) " ) ;
}
1999-12-04 21:35:07 +00:00
return NULL ;
}
2005-01-18 03:12:53 +00:00
2006-11-03 22:01:34 +00:00
/* now f is guaranteed non-NULL */
if ( f - > frametype = = AST_FRAME_DTMF ) {
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( peerflags , OPT_DTMF_EXIT ) ) {
2008-06-18 13:09:02 +00:00
const char * context ;
ast_channel_lock ( in ) ;
context = pbx_builtin_getvar_helper ( in , " EXITCONTEXT " ) ;
2009-11-04 14:05:12 +00:00
if ( onedigit_goto ( in , context , ( char ) f - > subclass . integer , 1 ) ) {
ast_verb ( 3 , " User hit %c to disconnect call. \n " , f - > subclass . integer ) ;
2007-12-12 20:05:13 +00:00
* to = 0 ;
2012-02-20 23:43:27 +00:00
ast_cdr_noanswer ( ast_channel_cdr ( in ) ) ;
2009-11-04 14:05:12 +00:00
* result = f - > subclass . integer ;
2006-11-04 11:00:49 +00:00
strcpy ( pa - > status , " CANCEL " ) ;
2005-01-18 03:12:53 +00:00
ast_frfree ( f ) ;
2008-06-18 13:09:02 +00:00
ast_channel_unlock ( in ) ;
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
if ( is_cc_recall ) {
ast_cc_completed ( in , " CC completed, but the caller used DTMF to exit " ) ;
}
2005-01-18 03:12:53 +00:00
return NULL ;
}
2008-06-18 13:09:02 +00:00
ast_channel_unlock ( in ) ;
2005-01-18 03:12:53 +00:00
}
2008-02-09 11:27:10 +00:00
if ( ast_test_flag64 ( peerflags , OPT_CALLER_HANGUP ) & &
2009-11-04 14:05:12 +00:00
detect_disconnect ( in , f - > subclass . integer , featurecode ) ) {
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
ast_verb ( 3 , " User requested call disconnect. \n " ) ;
2007-12-12 20:05:13 +00:00
* to = 0 ;
2006-11-04 11:00:49 +00:00
strcpy ( pa - > status , " CANCEL " ) ;
2012-02-20 23:43:27 +00:00
ast_cdr_noanswer ( ast_channel_cdr ( in ) ) ;
2005-01-18 03:12:53 +00:00
ast_frfree ( f ) ;
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
if ( is_cc_recall ) {
ast_cc_completed ( in , " CC completed, but the caller hung up with DTMF " ) ;
}
2005-01-18 03:12:53 +00:00
return NULL ;
}
2002-09-02 15:20:28 +00:00
}
2005-01-18 03:12:53 +00:00
2011-04-11 23:20:39 +00:00
/* Send the frame from the in channel to all outgoing channels. */
for ( o = outgoing ; o ; o = o - > next ) {
if ( ! o - > chan | | ! ast_test_flag64 ( o , DIAL_STILLGOING ) ) {
/* This outgoing channel has died so don't send the frame to it. */
continue ;
}
2011-02-04 20:30:48 +00:00
switch ( f - > frametype ) {
case AST_FRAME_HTML :
/* Forward HTML stuff */
2011-04-11 23:20:39 +00:00
if ( ! ast_test_flag64 ( o , DIAL_NOFORWARDHTML )
& & ast_channel_sendhtml ( o - > chan , f - > subclass . integer , f - > data . ptr , f - > datalen ) = = - 1 ) {
2011-02-04 20:30:48 +00:00
ast_log ( LOG_WARNING , " Unable to send URL \n " ) ;
2009-06-01 20:57:31 +00:00
}
2011-02-04 20:30:48 +00:00
break ;
case AST_FRAME_VOICE :
case AST_FRAME_IMAGE :
2012-03-14 17:39:45 +00:00
if ( ! single | | caller_entertained ) {
/*
* We are calling multiple parties or caller is being
* entertained and has thus not been made compatible .
* No need to check any other called parties .
*/
goto skip_frame ;
}
/* Fall through */
2011-02-04 20:30:48 +00:00
case AST_FRAME_TEXT :
case AST_FRAME_DTMF_BEGIN :
case AST_FRAME_DTMF_END :
2011-04-11 23:20:39 +00:00
if ( ast_write ( o - > chan , f ) ) {
2011-02-04 20:30:48 +00:00
ast_log ( LOG_WARNING , " Unable to forward frametype: %d \n " ,
f - > frametype ) ;
}
break ;
case AST_FRAME_CONTROL :
switch ( f - > subclass . integer ) {
case AST_CONTROL_HOLD :
2012-03-14 17:39:45 +00:00
ast_verb ( 3 , " Call on %s placed on hold \n " , ast_channel_name ( o - > chan ) ) ;
ast_indicate_data ( o - > chan , AST_CONTROL_HOLD , f - > data . ptr , f - > datalen ) ;
break ;
2011-02-04 20:30:48 +00:00
case AST_CONTROL_UNHOLD :
2012-03-14 17:39:45 +00:00
ast_verb ( 3 , " Call on %s left from hold \n " , ast_channel_name ( o - > chan ) ) ;
ast_indicate ( o - > chan , AST_CONTROL_UNHOLD ) ;
break ;
2011-02-04 20:30:48 +00:00
case AST_CONTROL_VIDUPDATE :
case AST_CONTROL_SRCUPDATE :
2012-03-14 17:39:45 +00:00
case AST_CONTROL_SRCCHANGE :
if ( ! single | | caller_entertained ) {
/*
* We are calling multiple parties or caller is being
* entertained and has thus not been made compatible .
* No need to check any other called parties .
*/
goto skip_frame ;
}
ast_verb ( 3 , " %s requested media update control %d, passing it to %s \n " ,
2012-01-09 22:15:50 +00:00
ast_channel_name ( in ) , f - > subclass . integer , ast_channel_name ( o - > chan ) ) ;
2012-03-14 17:39:45 +00:00
ast_indicate ( o - > chan , f - > subclass . integer ) ;
2011-02-04 20:30:48 +00:00
break ;
case AST_CONTROL_CONNECTED_LINE :
2012-02-27 16:50:19 +00:00
if ( ast_channel_connected_line_sub ( in , o - > chan , f , 1 ) & &
ast_channel_connected_line_macro ( in , o - > chan , f , 0 , 1 ) ) {
2011-04-11 23:20:39 +00:00
ast_indicate_data ( o - > chan , f - > subclass . integer , f - > data . ptr , f - > datalen ) ;
2011-02-04 20:30:48 +00:00
}
break ;
case AST_CONTROL_REDIRECTING :
2012-02-27 16:50:19 +00:00
if ( ast_channel_redirecting_sub ( in , o - > chan , f , 1 ) & &
ast_channel_redirecting_macro ( in , o - > chan , f , 0 , 1 ) ) {
2011-04-11 23:20:39 +00:00
ast_indicate_data ( o - > chan , f - > subclass . integer , f - > data . ptr , f - > datalen ) ;
2011-02-04 20:30:48 +00:00
}
break ;
default :
2012-03-14 17:39:45 +00:00
/* We are not going to do anything with this frame. */
goto skip_frame ;
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-02-04 20:30:48 +00:00
break ;
default :
2012-03-14 17:39:45 +00:00
/* We are not going to do anything with this frame. */
goto skip_frame ;
2009-06-01 20:57:31 +00:00
}
2005-08-30 02:12:09 +00:00
}
2012-03-14 17:39:45 +00:00
skip_frame : ;
2005-08-03 20:17:53 +00:00
ast_frfree ( f ) ;
1999-12-04 21:35:07 +00:00
}
2007-07-26 15:49:18 +00:00
if ( ! * to )
ast_verb ( 3 , " Nobody picked up in %d ms \n " , orig ) ;
2008-02-09 11:27:10 +00:00
if ( ! * to | | ast_check_hangup ( in ) )
2012-02-20 23:43:27 +00:00
ast_cdr_noanswer ( ast_channel_cdr ( in ) ) ;
1999-12-04 21:35:07 +00:00
}
2008-02-09 11:27:10 +00:00
2007-08-08 21:44:58 +00:00
# ifdef HAVE_EPOLL
2007-12-03 14:14:43 +00:00
for ( epollo = outgoing ; epollo ; epollo = epollo - > next ) {
if ( epollo - > chan )
ast_poll_channel_del ( in , epollo - > chan ) ;
}
2007-08-08 21:44:58 +00:00
# endif
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
if ( is_cc_recall ) {
ast_cc_completed ( in , " Recall completed! " ) ;
}
1999-12-04 21:35:07 +00:00
return peer ;
2006-04-19 14:02:49 +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 detect_disconnect ( struct ast_channel * chan , char code , struct ast_str * featurecode )
{
struct ast_flags features = { AST_FEATURE_DISCONNECT } ; /* only concerned with disconnect feature */
2009-03-19 20:30:39 +00:00
struct ast_call_feature feature = { 0 , } ;
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
int res ;
ast_str_append ( & featurecode , 1 , " %c " , code ) ;
res = ast_feature_detect ( chan , & features , ast_str_buffer ( featurecode ) , & feature ) ;
if ( res ! = AST_FEATURE_RETURN_STOREDIGITS ) {
ast_str_reset ( featurecode ) ;
}
if ( feature . feature_mask & AST_FEATURE_DISCONNECT ) {
return 1 ;
}
return 0 ;
}
2006-04-19 14:02:49 +00:00
static void replace_macro_delimiter ( char * s )
{
for ( ; * s ; s + + )
if ( * s = = ' ^ ' )
2007-07-23 19:51:41 +00:00
* s = ' , ' ;
1999-12-04 21:35:07 +00:00
}
2006-04-19 17:58:07 +00:00
/* returns true if there is a valid privacy reply */
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
static int valid_priv_reply ( struct ast_flags64 * opts , int res )
2006-04-19 17:58:07 +00:00
{
if ( res < ' 1 ' )
return 0 ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( opts , OPT_PRIVACY ) & & res < = ' 5 ' )
2006-04-19 17:58:07 +00:00
return 1 ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( opts , OPT_SCREENING ) & & res < = ' 4 ' )
2006-04-19 17:58:07 +00:00
return 1 ;
return 0 ;
}
2006-11-04 11:00:49 +00:00
static int do_privacy ( struct ast_channel * chan , struct ast_channel * peer ,
2008-02-09 11:27:10 +00:00
struct ast_flags64 * opts , char * * opt_args , struct privacy_args * pa )
2006-11-04 11:00:49 +00:00
{
int res2 ;
int loopcount = 0 ;
2008-02-09 11:27:10 +00:00
/* Get the user's intro, store it in priv-callerintros/$CID,
unless it is already there - - this should be done before the
2006-11-04 11:00:49 +00:00
call is actually dialed */
2008-02-09 11:27:10 +00:00
/* all ring indications and moh for the caller has been halted as soon as the
2006-11-04 11:00:49 +00:00
target extension was picked up . We are going to have to kill some
time and make the caller believe the peer hasn ' t picked up yet */
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( opts , OPT_MUSICBACK ) & & ! ast_strlen_zero ( opt_args [ OPT_ARG_MUSICBACK ] ) ) {
2012-01-24 20:12:09 +00:00
char * original_moh = ast_strdupa ( ast_channel_musicclass ( chan ) ) ;
2006-11-04 11:00:49 +00:00
ast_indicate ( chan , - 1 ) ;
2012-01-24 20:12:09 +00:00
ast_channel_musicclass_set ( chan , opt_args [ OPT_ARG_MUSICBACK ] ) ;
2006-11-04 11:00:49 +00:00
ast_moh_start ( chan , opt_args [ OPT_ARG_MUSICBACK ] , NULL ) ;
2012-01-24 20:12:09 +00:00
ast_channel_musicclass_set ( chan , original_moh ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
} else if ( ast_test_flag64 ( opts , OPT_RINGBACK ) ) {
2006-11-04 11:00:49 +00:00
ast_indicate ( chan , AST_CONTROL_RINGING ) ;
pa - > sentringing + + ;
}
/* Start autoservice on the other chan ?? */
res2 = ast_autoservice_start ( chan ) ;
/* Now Stream the File */
for ( loopcount = 0 ; loopcount < 3 ; loopcount + + ) {
2008-02-09 11:27:10 +00:00
if ( res2 & & loopcount = = 0 ) /* error in ast_autoservice_start() */
2006-11-04 11:00:49 +00:00
break ;
2008-02-09 11:27:10 +00:00
if ( ! res2 ) /* on timeout, play the message again */
2007-12-12 20:05:13 +00:00
res2 = ast_play_and_wait ( peer , " priv-callpending " ) ;
2006-11-04 11:00:49 +00:00
if ( ! valid_priv_reply ( opts , res2 ) )
res2 = 0 ;
2008-02-09 11:27:10 +00:00
/* priv-callpending script:
2006-11-04 11:00:49 +00:00
" I have a caller waiting, who introduces themselves as: "
*/
if ( ! res2 )
res2 = ast_play_and_wait ( peer , pa - > privintro ) ;
if ( ! valid_priv_reply ( opts , res2 ) )
res2 = 0 ;
/* now get input from the called party, as to their choice */
2007-12-12 20:05:13 +00:00
if ( ! res2 ) {
2006-11-04 11:00:49 +00:00
/* XXX can we have both, or they are mutually exclusive ? */
2007-12-12 20:05:13 +00:00
if ( ast_test_flag64 ( opts , OPT_PRIVACY ) )
res2 = ast_play_and_wait ( peer , " priv-callee-options " ) ;
if ( ast_test_flag64 ( opts , OPT_SCREENING ) )
res2 = ast_play_and_wait ( peer , " screen-callee-options " ) ;
2006-11-04 11:00:49 +00:00
}
/*! \page DialPrivacy Dial Privacy scripts
\ par priv - callee - options script :
" Dial 1 if you wish this caller to reach you directly in the future,
and immediately connect to their incoming call
2008-02-09 11:27:10 +00:00
Dial 2 if you wish to send this caller to voicemail now and
2006-11-04 11:00:49 +00:00
forevermore .
Dial 3 to send this caller to the torture menus , now and forevermore .
Dial 4 to send this caller to a simple " go away " menu , now and forevermore .
Dial 5 to allow this caller to come straight thru to you in the future ,
but right now , just this once , send them to voicemail . "
\ par screen - callee - options script :
" Dial 1 if you wish to immediately connect to the incoming call
Dial 2 if you wish to send this caller to voicemail .
Dial 3 to send this caller to the torture menus .
Dial 4 to send this caller to a simple " go away " menu .
*/
if ( valid_priv_reply ( opts , res2 ) )
break ;
/* invalid option */
res2 = ast_play_and_wait ( peer , " vm-sorry " ) ;
}
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( opts , OPT_MUSICBACK ) ) {
2006-11-04 11:00:49 +00:00
ast_moh_stop ( chan ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
} else if ( ast_test_flag64 ( opts , OPT_RINGBACK ) ) {
2006-11-04 11:00:49 +00:00
ast_indicate ( chan , - 1 ) ;
2007-12-12 20:05:13 +00:00
pa - > sentringing = 0 ;
2006-11-04 11:00:49 +00:00
}
ast_autoservice_stop ( chan ) ;
2007-12-12 20:05:13 +00:00
if ( ast_test_flag64 ( opts , OPT_PRIVACY ) & & ( res2 > = ' 1 ' & & res2 < = ' 5 ' ) ) {
2006-11-04 11:00:49 +00:00
/* map keypresses to various things, the index is res2 - '1' */
2009-05-12 13:59:35 +00:00
static const char * const _val [ ] = { " ALLOW " , " DENY " , " TORTURE " , " KILL " , " ALLOW " } ;
2006-11-04 11:00:49 +00:00
static const int _flag [ ] = { AST_PRIVACY_ALLOW , AST_PRIVACY_DENY , AST_PRIVACY_TORTURE , AST_PRIVACY_KILL , AST_PRIVACY_ALLOW } ;
int i = res2 - ' 1 ' ;
2007-07-26 15:49:18 +00:00
ast_verb ( 3 , " --Set privacy database entry %s/%s to %s \n " ,
2008-02-09 11:27:10 +00:00
opt_args [ OPT_ARG_PRIVACY ] , pa - > privcid , _val [ i ] ) ;
2006-11-04 11:00:49 +00:00
ast_privacy_set ( opt_args [ OPT_ARG_PRIVACY ] , pa - > privcid , _flag [ i ] ) ;
}
switch ( res2 ) {
case ' 1 ' :
break ;
case ' 2 ' :
ast_copy_string ( pa - > status , " NOANSWER " , sizeof ( pa - > status ) ) ;
break ;
case ' 3 ' :
ast_copy_string ( pa - > status , " TORTURE " , sizeof ( pa - > status ) ) ;
break ;
case ' 4 ' :
ast_copy_string ( pa - > status , " DONTCALL " , sizeof ( pa - > status ) ) ;
break ;
case ' 5 ' :
/* XXX should we set status to DENY ? */
2007-12-12 20:05:13 +00:00
if ( ast_test_flag64 ( opts , OPT_PRIVACY ) )
2006-11-04 11:00:49 +00:00
break ;
/* if not privacy, then 5 is the same as "default" case */
2008-02-09 11:27:10 +00:00
default : /* bad input or -1 if failure to start autoservice */
2006-11-04 11:00:49 +00:00
/* well, if the user messes up, ... he had his chance... What Is The Best Thing To Do? */
/* well, there seems basically two choices. Just patch the caller thru immediately,
or , . . . put ' em thru to voicemail . */
/* since the callee may have hung up, let's do the voicemail thing, no database decision */
ast_log ( LOG_NOTICE , " privacy: no valid response from the callee. Sending the caller to voicemail, the callee isn't responding \n " ) ;
/* XXX should we set status to DENY ? */
/* XXX what about the privacy flags ? */
break ;
}
2008-02-09 11:27:10 +00:00
if ( res2 = = ' 1 ' ) { /* the only case where we actually connect */
/* if the intro is NOCALLERID, then there's no reason to leave it on disk, it'll
2006-11-04 11:00:49 +00:00
just clog things up , and it ' s not useful information , not being tied to a CID */
2007-12-12 20:05:13 +00:00
if ( strncmp ( pa - > privcid , " NOCALLERID " , 10 ) = = 0 | | ast_test_flag64 ( opts , OPT_SCREEN_NOINTRO ) ) {
2006-11-04 11:00:49 +00:00
ast_filedelete ( pa - > privintro , NULL ) ;
2007-12-12 20:05:13 +00:00
if ( ast_fileexists ( pa - > privintro , NULL , NULL ) > 0 )
2006-11-04 11:00:49 +00:00
ast_log ( LOG_NOTICE , " privacy: ast_filedelete didn't do its job on %s \n " , pa - > privintro ) ;
2007-07-26 15:49:18 +00:00
else
ast_verb ( 3 , " Successfully deleted %s intro file \n " , pa - > privintro ) ;
2006-11-04 11:00:49 +00:00
}
2008-02-09 11:27:10 +00:00
return 0 ; /* the good exit path */
2006-11-04 11:00:49 +00:00
} else {
ast_hangup ( peer ) ; /* hang up on the callee -- he didn't want to talk anyway! */
return - 1 ;
}
}
2006-12-19 09:15:23 +00:00
/*! \brief returns 1 if successful, 0 or <0 if the caller should 'goto out' */
static int setup_privacy_args ( struct privacy_args * pa ,
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
struct ast_flags64 * opts , char * opt_args [ ] , struct ast_channel * chan )
2006-12-19 09:15:23 +00:00
{
char callerid [ 60 ] ;
int res ;
char * l ;
2012-02-29 16:52:47 +00:00
if ( ast_channel_caller ( chan ) - > id . number . valid
& & ! ast_strlen_zero ( ast_channel_caller ( chan ) - > id . number . str ) ) {
l = ast_strdupa ( ast_channel_caller ( chan ) - > id . number . str ) ;
2006-12-19 09:15:23 +00:00
ast_shrink_phone_number ( l ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( opts , OPT_PRIVACY ) ) {
2007-12-14 14:48:38 +00:00
ast_verb ( 3 , " Privacy DB is '%s', clid is '%s' \n " , opt_args [ OPT_ARG_PRIVACY ] , l ) ;
2006-12-19 09:15:23 +00:00
pa - > privdb_val = ast_privacy_check ( opt_args [ OPT_ARG_PRIVACY ] , l ) ;
} else {
2007-12-14 14:48:38 +00:00
ast_verb ( 3 , " Privacy Screening, clid is '%s' \n " , l ) ;
2006-12-19 09:15:23 +00:00
pa - > privdb_val = AST_PRIVACY_UNKNOWN ;
}
} else {
char * tnam , * tn2 ;
2012-01-09 22:15:50 +00:00
tnam = ast_strdupa ( ast_channel_name ( chan ) ) ;
2006-12-19 09:15:23 +00:00
/* clean the channel name so slashes don't try to end up in disk file name */
for ( tn2 = tnam ; * tn2 ; tn2 + + ) {
2007-12-14 14:48:38 +00:00
if ( * tn2 = = ' / ' ) /* any other chars to be afraid of? */
2006-12-19 09:15:23 +00:00
* tn2 = ' = ' ;
}
2007-07-26 15:49:18 +00:00
ast_verb ( 3 , " Privacy-- callerid is empty \n " ) ;
2006-12-19 09:15:23 +00:00
2012-02-13 17:27:06 +00:00
snprintf ( callerid , sizeof ( callerid ) , " NOCALLERID_%s%s " , ast_channel_exten ( chan ) , tnam ) ;
2006-12-19 09:15:23 +00:00
l = callerid ;
pa - > privdb_val = AST_PRIVACY_UNKNOWN ;
}
2008-02-09 11:27:10 +00:00
2007-12-12 20:05:13 +00:00
ast_copy_string ( pa - > privcid , l , sizeof ( pa - > privcid ) ) ;
2006-12-19 09:15:23 +00:00
2009-04-03 22:41:46 +00:00
if ( strncmp ( pa - > privcid , " NOCALLERID " , 10 ) ! = 0 & & ast_test_flag64 ( opts , OPT_SCREEN_NOCALLERID ) ) {
/* if callerid is set and OPT_SCREEN_NOCALLERID is set also */
2007-12-14 14:48:38 +00:00
ast_verb ( 3 , " CallerID set (%s); N option set; Screening should be off \n " , pa - > privcid ) ;
2006-12-19 09:15:23 +00:00
pa - > privdb_val = AST_PRIVACY_ALLOW ;
2009-04-03 22:41:46 +00:00
} else if ( ast_test_flag64 ( opts , OPT_SCREEN_NOCALLERID ) & & strncmp ( pa - > privcid , " NOCALLERID " , 10 ) = = 0 ) {
2007-12-14 14:48:38 +00:00
ast_verb ( 3 , " CallerID blank; N option set; Screening should happen; dbval is %d \n " , pa - > privdb_val ) ;
2006-12-19 09:15:23 +00:00
}
2007-12-12 20:05:13 +00:00
if ( pa - > privdb_val = = AST_PRIVACY_DENY ) {
2007-12-14 14:48:38 +00:00
ast_verb ( 3 , " Privacy DB reports PRIVACY_DENY for this callerid. Dial reports unavailable \n " ) ;
2006-12-19 09:15:23 +00:00
ast_copy_string ( pa - > status , " NOANSWER " , sizeof ( pa - > status ) ) ;
return 0 ;
2007-12-12 20:05:13 +00:00
} else if ( pa - > privdb_val = = AST_PRIVACY_KILL ) {
2006-12-19 09:15:23 +00:00
ast_copy_string ( pa - > status , " DONTCALL " , sizeof ( pa - > status ) ) ;
return 0 ; /* Is this right? */
2007-12-12 20:05:13 +00:00
} else if ( pa - > privdb_val = = AST_PRIVACY_TORTURE ) {
2006-12-19 09:15:23 +00:00
ast_copy_string ( pa - > status , " TORTURE " , sizeof ( pa - > status ) ) ;
return 0 ; /* is this right??? */
2007-12-12 20:05:13 +00:00
} else if ( pa - > privdb_val = = AST_PRIVACY_UNKNOWN ) {
2008-02-09 11:27:10 +00:00
/* Get the user's intro, store it in priv-callerintros/$CID,
unless it is already there - - this should be done before the
2006-12-19 09:15:23 +00:00
call is actually dialed */
/* make sure the priv-callerintros dir actually exists */
snprintf ( pa - > privintro , sizeof ( pa - > privintro ) , " %s/sounds/priv-callerintros " , ast_config_AST_DATA_DIR ) ;
2007-06-22 04:35:12 +00:00
if ( ( res = ast_mkdir ( pa - > privintro , 0755 ) ) ) {
ast_log ( LOG_WARNING , " privacy: can't create directory priv-callerintros: %s \n " , strerror ( res ) ) ;
2006-12-19 09:15:23 +00:00
return - 1 ;
}
2007-06-22 04:35:12 +00:00
snprintf ( pa - > privintro , sizeof ( pa - > privintro ) , " priv-callerintros/%s " , pa - > privcid ) ;
if ( ast_fileexists ( pa - > privintro , NULL , NULL ) > 0 & & strncmp ( pa - > privcid , " NOCALLERID " , 10 ) ! = 0 ) {
2006-12-19 09:15:23 +00:00
/* the DELUX version of this code would allow this caller the
option to hear and retape their previously recorded intro .
*/
} else {
int duration ; /* for feedback from play_and_wait */
/* the file doesn't exist yet. Let the caller submit his
vocal intro for posterity */
/* priv-recordintro script:
" At the tone, please say your name: "
*/
2012-02-08 20:49:48 +00:00
int silencethreshold = ast_dsp_get_threshold_from_settings ( THRESHOLD_SILENCE ) ;
2007-02-17 03:57:23 +00:00
ast_answer ( chan ) ;
Merged revisions 337120 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10
................
r337120 | mjordan | 2011-09-20 17:49:36 -0500 (Tue, 20 Sep 2011) | 28 lines
Merged revisions 337118 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r337118 | mjordan | 2011-09-20 17:38:54 -0500 (Tue, 20 Sep 2011) | 21 lines
Fix for incorrect voicemail duration in external notifications
This patch fixes an issue where the voicemail duration was being reported
with a duration significantly less than the actual sound file duration.
Voicemails that contained mostly silence were reporting the duration of
only the sound in the file, as opposed to the duration of the file with
the silence. This patch fixes this by having two durations reported in
the __ast_play_and_record family of functions - the sound_duration and the
actual duration of the file. The sound_duration, which is optional, now
reports the duration of the sound in the file, while the actual full duration
of the file is reported in the duration parameter. This allows the voicemail
applications to use the sound_duration for minimum duration checking, while
reporting the full duration to external parties if the voicemail is kept.
(issue ASTERISK-2234)
(closes issue ASTERISK-16981)
Reported by: Mary Ciuciu, Byron Clark, Brad House, Karsten Wemheuer, KevinH
Tested by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1443
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2011-09-20 23:02:25 +00:00
res = ast_play_and_record ( chan , " priv-recordintro " , pa - > privintro , 4 , " sln " , & duration , NULL , silencethreshold , 2000 , 0 ) ; /* NOTE: I've reduced the total time to 4 sec */
2006-12-19 09:15:23 +00:00
/* don't think we'll need a lock removed, we took care of
conflicts by naming the pa . privintro file */
if ( res = = - 1 ) {
/* Delete the file regardless since they hung up during recording */
ast_filedelete ( pa - > privintro , NULL ) ;
2007-12-12 20:05:13 +00:00
if ( ast_fileexists ( pa - > privintro , NULL , NULL ) > 0 )
ast_log ( LOG_NOTICE , " privacy: ast_filedelete didn't do its job on %s \n " , pa - > privintro ) ;
2007-07-26 15:49:18 +00:00
else
ast_verb ( 3 , " Successfully deleted %s intro file \n " , pa - > privintro ) ;
2006-12-19 09:15:23 +00:00
return - 1 ;
}
2012-01-24 20:12:09 +00:00
if ( ! ast_streamfile ( chan , " vm-dialout " , ast_channel_language ( chan ) ) )
2006-12-19 09:15:23 +00:00
ast_waitstream ( chan , " " ) ;
}
}
2008-02-09 11:27:10 +00:00
return 1 ; /* success */
2006-12-19 09:15:23 +00:00
}
2008-11-09 01:27:00 +00:00
static void end_bridge_callback ( void * data )
{
char buf [ 80 ] ;
time_t end ;
struct ast_channel * chan = data ;
2012-02-20 23:43:27 +00:00
if ( ! ast_channel_cdr ( chan ) ) {
2008-11-12 17:41:56 +00:00
return ;
}
2008-11-09 01:27:00 +00:00
time ( & end ) ;
ast_channel_lock ( chan ) ;
2012-02-20 23:43:27 +00:00
if ( ast_channel_cdr ( chan ) - > answer . tv_sec ) {
snprintf ( buf , sizeof ( buf ) , " %ld " , ( long ) end - ast_channel_cdr ( chan ) - > answer . tv_sec ) ;
2008-11-09 01:27:00 +00:00
pbx_builtin_setvar_helper ( chan , " ANSWEREDTIME " , buf ) ;
}
2012-02-20 23:43:27 +00:00
if ( ast_channel_cdr ( chan ) - > start . tv_sec ) {
snprintf ( buf , sizeof ( buf ) , " %ld " , ( long ) end - ast_channel_cdr ( chan ) - > start . tv_sec ) ;
2008-11-09 01:27:00 +00:00
pbx_builtin_setvar_helper ( chan , " DIALEDTIME " , buf ) ;
}
ast_channel_unlock ( chan ) ;
}
2008-11-18 18:31:08 +00:00
static void end_bridge_callback_data_fixup ( struct ast_bridge_config * bconfig , struct ast_channel * originator , struct ast_channel * terminator ) {
bconfig - > end_bridge_callback_data = originator ;
}
2009-12-19 08:59:31 +00:00
static int dial_handle_playtones ( struct ast_channel * chan , const char * data )
{
struct ast_tone_zone_sound * ts = NULL ;
int res ;
const char * str = data ;
if ( ast_strlen_zero ( str ) ) {
ast_debug ( 1 , " Nothing to play \n " ) ;
return - 1 ;
}
2012-02-20 23:43:27 +00:00
ts = ast_get_indication_tone ( ast_channel_zone ( chan ) , str ) ;
2009-12-19 08:59:31 +00:00
if ( ts & & ts - > data [ 0 ] ) {
res = ast_playtones_start ( chan , 0 , ts - > data , 0 ) ;
} else {
res = - 1 ;
}
if ( ts ) {
ts = ast_tone_zone_sound_unref ( ts ) ;
}
if ( res ) {
ast_log ( LOG_WARNING , " Unable to start playtone \' %s \' \n " , str ) ;
}
return res ;
}
2009-05-21 21:13:09 +00:00
static int dial_exec_full ( struct ast_channel * chan , const char * data , struct ast_flags64 * peerflags , int * continue_exec )
1999-12-04 21:35:07 +00:00
{
2008-02-09 11:27:10 +00:00
int res = - 1 ; /* default: error */
char * rest , * cur ; /* scan the list of destinations */
struct chanlist * outgoing = NULL ; /* list of destinations */
2004-06-21 13:30:58 +00:00
struct ast_channel * peer ;
2008-02-09 11:27:10 +00:00
int to ; /* timeout */
2006-11-03 22:36:17 +00:00
struct cause_args num = { chan , 0 , 0 , 0 } ;
2004-10-26 22:25:43 +00:00
int cause ;
2007-05-17 16:49:50 +00:00
char numsubst [ 256 ] ;
2006-11-04 00:50:18 +00:00
2007-12-12 20:05:13 +00:00
struct ast_bridge_config config = { { 0 , } } ;
2008-11-12 21:34:51 +00:00
struct timeval calldurationlimit = { 0 , } ;
2009-03-17 17:17:51 +00:00
char * dtmfcalled = NULL , * dtmfcalling = NULL , * dtmf_progress = NULL ;
2006-11-04 11:00:49 +00:00
struct privacy_args pa = {
. sentringing = 0 ,
. privdb_val = 0 ,
2007-02-03 20:46:36 +00:00
. status = " INVALIDARGS " ,
2006-11-04 11:00:49 +00:00
} ;
2006-04-11 16:15:11 +00:00
int sentringing = 0 , moh = 0 ;
2005-12-20 17:52:31 +00:00
const char * outbound_group = NULL ;
2006-04-19 16:54:04 +00:00
int result = 0 ;
2005-11-02 21:46:52 +00:00
char * parse ;
2006-04-22 11:30:06 +00:00
int opermode = 0 ;
2009-11-02 18:08:54 +00:00
int delprivintro = 0 ;
2005-11-02 21:46:52 +00:00
AST_DECLARE_APP_ARGS ( args ,
2008-02-09 11:27:10 +00:00
AST_APP_ARG ( peers ) ;
AST_APP_ARG ( timeout ) ;
AST_APP_ARG ( options ) ;
AST_APP_ARG ( url ) ;
2005-11-02 21:46:52 +00:00
) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
struct ast_flags64 opts = { 0 , } ;
2005-11-02 21:46:52 +00:00
char * opt_args [ OPT_ARG_ARRAY_SIZE ] ;
2007-12-04 17:35:40 +00:00
struct ast_datastore * datastore = NULL ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
int fulldial = 0 , num_dialed = 0 ;
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
int ignore_cc = 0 ;
char device_name [ AST_CHANNEL_NAME ] ;
2011-03-18 02:31:27 +00:00
char forced_clid_name [ AST_MAX_EXTENSION ] ;
char stored_clid_name [ AST_MAX_EXTENSION ] ;
int force_forwards_only ; /*!< TRUE if force CallerID on call forward only. Legacy behaviour.*/
/*!
* \ brief Forced CallerID party information to send .
* \ note This will not have any malloced strings so do not free it .
*/
struct ast_party_id forced_clid ;
/*!
* \ brief Stored CallerID information if needed .
*
* \ note If OPT_ORIGINAL_CLID set then this is the o option
* CallerID . Otherwise it is the dialplan extension and hint
* name .
*
* \ note This will not have any malloced strings so do not free it .
*/
struct ast_party_id stored_clid ;
/*!
* \ brief CallerID party information to store .
* \ note This will not have any malloced strings so do not free it .
*/
struct ast_party_caller caller ;
2005-03-17 22:39:04 +00:00
2008-10-28 17:07:39 +00:00
/* Reset all DIAL variables back to blank, to prevent confusion (in case we don't reset all of them). */
pbx_builtin_setvar_helper ( chan , " DIALSTATUS " , " " ) ;
pbx_builtin_setvar_helper ( chan , " DIALEDPEERNUMBER " , " " ) ;
pbx_builtin_setvar_helper ( chan , " DIALEDPEERNAME " , " " ) ;
pbx_builtin_setvar_helper ( chan , " ANSWEREDTIME " , " " ) ;
pbx_builtin_setvar_helper ( chan , " DIALEDTIME " , " " ) ;
2005-10-26 19:48:14 +00:00
if ( ast_strlen_zero ( data ) ) {
2005-11-02 21:46:52 +00:00
ast_log ( LOG_WARNING , " Dial requires an argument (technology/number) \n " ) ;
2007-02-03 20:46:36 +00:00
pbx_builtin_setvar_helper ( chan , " DIALSTATUS " , pa . status ) ;
1999-12-04 21:35:07 +00:00
return - 1 ;
}
2004-09-22 05:19:06 +00:00
2006-05-10 13:22:15 +00:00
parse = ast_strdupa ( data ) ;
2008-02-09 11:27:10 +00:00
2005-11-02 21:46:52 +00:00
AST_STANDARD_APP_ARGS ( args , parse ) ;
2006-04-19 14:02:49 +00:00
if ( ! ast_strlen_zero ( args . options ) & &
2008-02-09 11:27:10 +00:00
ast_app_parse_options64 ( dial_exec_options , & opts , opt_args , args . options ) ) {
2007-02-03 20:46:36 +00:00
pbx_builtin_setvar_helper ( chan , " DIALSTATUS " , pa . status ) ;
2006-04-19 14:02:49 +00:00
goto done ;
2007-02-03 20:46:36 +00:00
}
2003-01-17 05:10:52 +00:00
2005-11-02 21:46:52 +00:00
if ( ast_strlen_zero ( args . peers ) ) {
ast_log ( LOG_WARNING , " Dial requires an argument (technology/number) \n " ) ;
2007-02-03 20:46:36 +00:00
pbx_builtin_setvar_helper ( chan , " DIALSTATUS " , pa . status ) ;
2006-04-19 14:02:49 +00:00
goto done ;
2005-11-02 21:46:52 +00:00
}
2004-04-26 23:22:34 +00:00
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
if ( ast_cc_call_init ( chan , & ignore_cc ) ) {
goto done ;
}
2009-11-02 18:08:54 +00:00
if ( ast_test_flag64 ( & opts , OPT_SCREEN_NOINTRO ) & & ! ast_strlen_zero ( opt_args [ OPT_ARG_SCREEN_NOINTRO ] ) ) {
delprivintro = atoi ( opt_args [ OPT_ARG_SCREEN_NOINTRO ] ) ;
if ( delprivintro < 0 | | delprivintro > 1 ) {
ast_log ( LOG_WARNING , " Unknown argument %d specified to n option, ignoring \n " , delprivintro ) ;
delprivintro = 0 ;
}
}
2009-12-19 08:59:31 +00:00
if ( ! ast_test_flag64 ( & opts , OPT_RINGBACK ) ) {
opt_args [ OPT_ARG_RINGBACK ] = NULL ;
}
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( & opts , OPT_OPERMODE ) ) {
2006-11-04 01:16:20 +00:00
opermode = ast_strlen_zero ( opt_args [ OPT_ARG_OPERMODE ] ) ? 1 : atoi ( opt_args [ OPT_ARG_OPERMODE ] ) ;
2007-07-26 15:49:18 +00:00
ast_verb ( 3 , " Setting operator services mode to %d. \n " , opermode ) ;
2006-04-22 11:30:06 +00:00
}
2009-03-17 17:17:51 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( & opts , OPT_DURATION_STOP ) & & ! ast_strlen_zero ( opt_args [ OPT_ARG_DURATION_STOP ] ) ) {
2008-11-12 21:34:51 +00:00
calldurationlimit . tv_sec = atoi ( opt_args [ OPT_ARG_DURATION_STOP ] ) ;
if ( ! calldurationlimit . tv_sec ) {
2006-04-11 16:15:11 +00:00
ast_log ( LOG_WARNING , " Dial does not accept S(%s), hanging up. \n " , opt_args [ OPT_ARG_DURATION_STOP ] ) ;
2007-02-03 20:46:36 +00:00
pbx_builtin_setvar_helper ( chan , " DIALSTATUS " , pa . status ) ;
2006-04-19 14:02:49 +00:00
goto done ;
2006-04-11 16:15:11 +00:00
}
2011-04-19 14:25:47 +00:00
ast_verb ( 3 , " Setting call duration limit to %.3lf seconds. \n " , calldurationlimit . tv_sec + calldurationlimit . tv_usec / 1000000.0 ) ;
2005-11-02 21:46:52 +00:00
}
2005-03-17 22:39:04 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( & opts , OPT_SENDDTMF ) & & ! ast_strlen_zero ( opt_args [ OPT_ARG_SENDDTMF ] ) ) {
2009-03-17 17:17:51 +00:00
dtmf_progress = opt_args [ OPT_ARG_SENDDTMF ] ;
dtmfcalled = strsep ( & dtmf_progress , " : " ) ;
dtmfcalling = strsep ( & dtmf_progress , " : " ) ;
2005-11-02 21:46:52 +00:00
}
2005-03-17 22:39:04 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( & opts , OPT_DURATION_LIMIT ) & & ! ast_strlen_zero ( opt_args [ OPT_ARG_DURATION_LIMIT ] ) ) {
2009-09-24 20:29:51 +00:00
if ( ast_bridge_timelimit ( chan , & config , opt_args [ OPT_ARG_DURATION_LIMIT ] , & calldurationlimit ) )
2006-04-19 14:02:49 +00:00
goto done ;
2003-01-17 05:10:52 +00:00
}
2005-11-02 21:46:52 +00:00
2011-03-18 02:31:27 +00:00
/* Setup the forced CallerID information to send if used. */
ast_party_id_init ( & forced_clid ) ;
force_forwards_only = 0 ;
if ( ast_test_flag64 ( & opts , OPT_FORCECLID ) ) {
if ( ast_strlen_zero ( opt_args [ OPT_ARG_FORCECLID ] ) ) {
ast_channel_lock ( chan ) ;
2012-02-13 17:27:06 +00:00
forced_clid . number . str = ast_strdupa ( S_OR ( ast_channel_macroexten ( chan ) , ast_channel_exten ( chan ) ) ) ;
2011-03-18 02:31:27 +00:00
ast_channel_unlock ( chan ) ;
forced_clid_name [ 0 ] = ' \0 ' ;
forced_clid . name . str = ( char * ) get_cid_name ( forced_clid_name ,
sizeof ( forced_clid_name ) , chan ) ;
force_forwards_only = 1 ;
} else {
/* Note: The opt_args[OPT_ARG_FORCECLID] string value is altered here. */
ast_callerid_parse ( opt_args [ OPT_ARG_FORCECLID ] , & forced_clid . name . str ,
& forced_clid . number . str ) ;
}
if ( ! ast_strlen_zero ( forced_clid . name . str ) ) {
forced_clid . name . valid = 1 ;
}
if ( ! ast_strlen_zero ( forced_clid . number . str ) ) {
forced_clid . number . valid = 1 ;
}
}
if ( ast_test_flag64 ( & opts , OPT_FORCE_CID_TAG )
& & ! ast_strlen_zero ( opt_args [ OPT_ARG_FORCE_CID_TAG ] ) ) {
forced_clid . tag = opt_args [ OPT_ARG_FORCE_CID_TAG ] ;
}
forced_clid . number . presentation = AST_PRES_ALLOWED_USER_NUMBER_PASSED_SCREEN ;
if ( ast_test_flag64 ( & opts , OPT_FORCE_CID_PRES )
& & ! ast_strlen_zero ( opt_args [ OPT_ARG_FORCE_CID_PRES ] ) ) {
int pres ;
pres = ast_parse_caller_presentation ( opt_args [ OPT_ARG_FORCE_CID_PRES ] ) ;
if ( 0 < = pres ) {
forced_clid . number . presentation = pres ;
}
}
/* Setup the stored CallerID information if needed. */
ast_party_id_init ( & stored_clid ) ;
if ( ast_test_flag64 ( & opts , OPT_ORIGINAL_CLID ) ) {
if ( ast_strlen_zero ( opt_args [ OPT_ARG_ORIGINAL_CLID ] ) ) {
ast_channel_lock ( chan ) ;
2012-02-29 16:52:47 +00:00
ast_party_id_set_init ( & stored_clid , & ast_channel_caller ( chan ) - > id ) ;
if ( ! ast_strlen_zero ( ast_channel_caller ( chan ) - > id . name . str ) ) {
stored_clid . name . str = ast_strdupa ( ast_channel_caller ( chan ) - > id . name . str ) ;
2011-03-18 02:31:27 +00:00
}
2012-02-29 16:52:47 +00:00
if ( ! ast_strlen_zero ( ast_channel_caller ( chan ) - > id . number . str ) ) {
stored_clid . number . str = ast_strdupa ( ast_channel_caller ( chan ) - > id . number . str ) ;
2011-03-18 02:31:27 +00:00
}
2012-02-29 16:52:47 +00:00
if ( ! ast_strlen_zero ( ast_channel_caller ( chan ) - > id . subaddress . str ) ) {
stored_clid . subaddress . str = ast_strdupa ( ast_channel_caller ( chan ) - > id . subaddress . str ) ;
2011-03-18 02:31:27 +00:00
}
2012-02-29 16:52:47 +00:00
if ( ! ast_strlen_zero ( ast_channel_caller ( chan ) - > id . tag ) ) {
stored_clid . tag = ast_strdupa ( ast_channel_caller ( chan ) - > id . tag ) ;
2011-03-18 02:31:27 +00:00
}
ast_channel_unlock ( chan ) ;
} else {
/* Note: The opt_args[OPT_ARG_ORIGINAL_CLID] string value is altered here. */
ast_callerid_parse ( opt_args [ OPT_ARG_ORIGINAL_CLID ] , & stored_clid . name . str ,
& stored_clid . number . str ) ;
if ( ! ast_strlen_zero ( stored_clid . name . str ) ) {
stored_clid . name . valid = 1 ;
}
if ( ! ast_strlen_zero ( stored_clid . number . str ) ) {
stored_clid . number . valid = 1 ;
}
}
} else {
/*
* In case the new channel has no preset CallerID number by the
* channel driver , setup the dialplan extension and hint name .
*/
stored_clid_name [ 0 ] = ' \0 ' ;
stored_clid . name . str = ( char * ) get_cid_name ( stored_clid_name ,
sizeof ( stored_clid_name ) , chan ) ;
if ( ast_strlen_zero ( stored_clid . name . str ) ) {
stored_clid . name . str = NULL ;
} else {
stored_clid . name . valid = 1 ;
}
ast_channel_lock ( chan ) ;
2012-02-13 17:27:06 +00:00
stored_clid . number . str = ast_strdupa ( S_OR ( ast_channel_macroexten ( chan ) , ast_channel_exten ( chan ) ) ) ;
2011-03-18 02:31:27 +00:00
stored_clid . number . valid = 1 ;
ast_channel_unlock ( chan ) ;
}
2012-02-20 23:43:27 +00:00
if ( ast_test_flag64 ( & opts , OPT_RESETCDR ) & & ast_channel_cdr ( chan ) )
ast_cdr_reset ( ast_channel_cdr ( chan ) , NULL ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( & opts , OPT_PRIVACY ) & & ast_strlen_zero ( opt_args [ OPT_ARG_PRIVACY ] ) )
2012-02-13 17:27:06 +00:00
opt_args [ OPT_ARG_PRIVACY ] = ast_strdupa ( ast_channel_exten ( chan ) ) ;
2005-07-12 03:23:31 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( & opts , OPT_PRIVACY ) | | ast_test_flag64 ( & opts , OPT_SCREENING ) ) {
2006-12-19 09:15:23 +00:00
res = setup_privacy_args ( & pa , & opts , opt_args , chan ) ;
if ( res < = 0 )
2005-07-12 03:23:31 +00:00
goto out ;
2008-02-09 11:27:10 +00:00
res = - 1 ; /* reset default */
2003-01-17 05:10:52 +00:00
}
2004-11-07 21:49:43 +00:00
2007-02-15 16:24:13 +00:00
if ( continue_exec )
* continue_exec = 0 ;
2008-02-09 11:27:10 +00:00
2004-11-07 21:49:43 +00:00
/* If a channel group has been specified, get it for use when we create peer channels */
2008-06-18 13:09:02 +00:00
ast_channel_lock ( chan ) ;
2007-04-13 19:18:46 +00:00
if ( ( outbound_group = pbx_builtin_getvar_helper ( chan , " OUTBOUND_GROUP_ONCE " ) ) ) {
2008-06-18 13:09:02 +00:00
outbound_group = ast_strdupa ( outbound_group ) ;
2007-04-13 19:18:46 +00:00
pbx_builtin_setvar_helper ( chan , " OUTBOUND_GROUP_ONCE " , NULL ) ;
2008-06-18 13:09:02 +00:00
} else if ( ( outbound_group = pbx_builtin_getvar_helper ( chan , " OUTBOUND_GROUP " ) ) ) {
outbound_group = ast_strdupa ( outbound_group ) ;
2007-04-13 19:18:46 +00:00
}
2008-06-18 13:09:02 +00:00
ast_channel_unlock ( chan ) ;
2009-10-19 19:49:09 +00:00
ast_copy_flags64 ( peerflags , & opts , OPT_DTMF_EXIT | OPT_GO_ON | OPT_ORIGINAL_CLID | OPT_CALLER_HANGUP | OPT_IGNORE_FORWARDING | OPT_IGNORE_CONNECTEDLINE |
2010-01-05 18:46:19 +00:00
OPT_CANCEL_TIMEOUT | OPT_ANNOUNCE | OPT_CALLEE_MACRO | OPT_CALLEE_GOSUB | OPT_FORCECLID ) ;
2008-03-01 01:30:37 +00:00
2006-04-19 14:02:49 +00:00
/* loop through the list of dial destinations */
rest = args . peers ;
while ( ( cur = strsep ( & rest , " & " ) ) ) {
2006-12-19 16:36:45 +00:00
struct chanlist * tmp ;
2008-02-09 11:27:10 +00:00
struct ast_channel * tc ; /* channel for this destination */
1999-12-18 07:01:48 +00:00
/* Get a technology/[device:]number pair */
2006-04-19 16:36:15 +00:00
char * number = cur ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
char * interface = ast_strdupa ( number ) ;
2006-04-19 16:36:15 +00:00
char * tech = strsep ( & number , " / " ) ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
/* find if we already dialed this interface */
struct ast_dialed_interface * di ;
2012-02-29 16:52:47 +00:00
AST_LIST_HEAD ( , ast_dialed_interface ) * dialed_interfaces ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
num_dialed + + ;
2011-01-31 23:08:38 +00:00
if ( ast_strlen_zero ( number ) ) {
2005-11-02 21:46:52 +00:00
ast_log ( LOG_WARNING , " Dial argument takes format (technology/[device:]number1) \n " ) ;
1999-12-04 21:35:07 +00:00
goto out ;
}
2006-04-19 14:02:49 +00:00
if ( ! ( tmp = ast_calloc ( 1 , sizeof ( * tmp ) ) ) )
1999-12-04 21:35:07 +00:00
goto out ;
2005-11-02 21:46:52 +00:00
if ( opts . flags ) {
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
ast_copy_flags64 ( tmp , & opts ,
2008-02-09 11:27:10 +00:00
OPT_CANCEL_ELSEWHERE |
OPT_CALLEE_TRANSFER | OPT_CALLER_TRANSFER |
OPT_CALLEE_HANGUP | OPT_CALLER_HANGUP |
OPT_CALLEE_MONITOR | OPT_CALLER_MONITOR |
OPT_CALLEE_PARK | OPT_CALLER_PARK |
OPT_CALLEE_MIXMONITOR | OPT_CALLER_MIXMONITOR |
OPT_RINGBACK | OPT_MUSICBACK | OPT_FORCECLID ) ;
ast_set2_flag64 ( tmp , args . url , DIAL_NOFORWARDHTML ) ;
2002-05-17 14:33:10 +00:00
}
2005-07-07 23:32:37 +00:00
ast_copy_string ( numsubst , number , sizeof ( numsubst ) ) ;
1999-12-04 21:35:07 +00:00
/* Request the peer */
2007-12-07 16:40:41 +00:00
ast_channel_lock ( chan ) ;
datastore = ast_channel_datastore_find ( chan , & dialed_interface_info , NULL ) ;
2010-05-20 19:40:03 +00:00
/*
* Seed the chanlist ' s connected line information with previously
* acquired connected line info from the incoming channel . The
* previously acquired connected line info could have been set
* through the CONNECTED_LINE dialplan function .
2009-04-03 22:41:46 +00:00
*/
2012-02-29 16:52:47 +00:00
ast_party_connected_line_copy ( & tmp - > connected , ast_channel_connected ( chan ) ) ;
2007-12-07 16:40:41 +00:00
ast_channel_unlock ( chan ) ;
if ( datastore )
dialed_interfaces = datastore - > data ;
else {
2008-08-05 16:56:11 +00:00
if ( ! ( datastore = ast_datastore_alloc ( & dialed_interface_info , NULL ) ) ) {
2008-02-09 11:27:10 +00:00
ast_log ( LOG_WARNING , " Unable to create channel datastore for dialed interfaces. Aborting! \n " ) ;
2009-10-09 18:13:57 +00:00
chanlist_free ( tmp ) ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
goto out ;
}
2007-12-07 16:40:41 +00:00
datastore - > inheritance = DATASTORE_INHERIT_FOREVER ;
if ( ! ( dialed_interfaces = ast_calloc ( 1 , sizeof ( * dialed_interfaces ) ) ) ) {
2009-10-09 18:13:57 +00:00
ast_datastore_free ( datastore ) ;
chanlist_free ( tmp ) ;
2007-12-07 16:40:41 +00:00
goto out ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
}
2007-12-07 16:40:41 +00:00
datastore - > data = dialed_interfaces ;
AST_LIST_HEAD_INIT ( dialed_interfaces ) ;
ast_channel_lock ( chan ) ;
ast_channel_datastore_add ( chan , datastore ) ;
ast_channel_unlock ( chan ) ;
}
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
AST_LIST_LOCK ( dialed_interfaces ) ;
AST_LIST_TRAVERSE ( dialed_interfaces , di , list ) {
2007-12-07 16:40:41 +00:00
if ( ! strcasecmp ( di - > interface , interface ) ) {
2008-02-09 11:27:10 +00:00
ast_log ( LOG_WARNING , " Skipping dialing interface '%s' again since it has already been dialed \n " ,
2007-12-07 16:40:41 +00:00
di - > interface ) ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
break ;
}
}
2007-12-07 16:40:41 +00:00
AST_LIST_UNLOCK ( dialed_interfaces ) ;
if ( di ) {
fulldial + + ;
2009-10-09 18:13:57 +00:00
chanlist_free ( tmp ) ;
2007-12-07 16:40:41 +00:00
continue ;
}
/* It is always ok to dial a Local interface. We only keep track of
* which " real " interfaces have been dialed . The Local channel will
* inherit this list so that if it ends up dialing a real interface ,
* it won ' t call one that has already been called . */
if ( strcasecmp ( tech , " Local " ) ) {
if ( ! ( di = ast_calloc ( 1 , sizeof ( * di ) + strlen ( interface ) ) ) ) {
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
AST_LIST_UNLOCK ( dialed_interfaces ) ;
2009-10-09 18:13:57 +00:00
chanlist_free ( tmp ) ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
goto out ;
}
strcpy ( di - > interface , interface ) ;
2007-12-07 16:40:41 +00:00
AST_LIST_LOCK ( dialed_interfaces ) ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
AST_LIST_INSERT_TAIL ( dialed_interfaces , di , list ) ;
2007-12-07 02:52:38 +00:00
AST_LIST_UNLOCK ( dialed_interfaces ) ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
}
2012-02-20 23:43:27 +00:00
tc = ast_request ( tech , ast_channel_nativeformats ( chan ) , chan , numsubst , & cause ) ;
2006-12-19 09:58:40 +00:00
if ( ! tc ) {
1999-12-04 21:35:07 +00:00
/* If we can't, just go on to the next call */
2006-12-19 09:58:40 +00:00
ast_log ( LOG_WARNING , " Unable to create channel of type '%s' (cause %d - %s) \n " ,
2008-02-09 11:27:10 +00:00
tech , cause , ast_cause2str ( cause ) ) ;
2006-11-03 22:36:17 +00:00
handle_cause ( cause , & num ) ;
2008-02-09 11:27:10 +00:00
if ( ! rest ) /* we are on the last destination */
2012-02-20 23:43:27 +00:00
ast_channel_hangupcause_set ( chan , cause ) ;
2009-10-09 18:13:57 +00:00
chanlist_free ( tmp ) ;
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
if ( ! ignore_cc & & ( cause = = AST_CAUSE_BUSY | | cause = = AST_CAUSE_CONGESTION ) ) {
if ( ! ast_cc_callback ( chan , tech , numsubst , ast_cc_busy_interface ) ) {
ast_cc_extension_monitor_add_dialstring ( chan , interface , " " ) ;
}
}
1999-12-04 21:35:07 +00:00
continue ;
}
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
ast_channel_get_device_name ( tc , device_name , sizeof ( device_name ) ) ;
if ( ! ignore_cc ) {
ast_cc_extension_monitor_add_dialstring ( chan , interface , device_name ) ;
}
2006-12-19 09:58:40 +00:00
pbx_builtin_setvar_helper ( tc , " DIALEDPEERNUMBER " , numsubst ) ;
2004-11-01 02:23:28 +00:00
2009-04-03 22:41:46 +00:00
ast_channel_lock ( tc ) ;
while ( ast_channel_trylock ( chan ) ) {
CHANNEL_DEADLOCK_AVOIDANCE ( tc ) ;
}
2005-12-20 17:52:31 +00:00
/* Setup outgoing SDP to match incoming one */
2009-10-19 19:49:09 +00:00
if ( ! outgoing & & ! rest & & CAN_EARLY_BRIDGE ( peerflags , chan , tc ) ) {
2009-04-02 17:20:52 +00:00
ast_rtp_instance_early_bridge_make_compatible ( tc , chan ) ;
}
2005-12-20 17:52:31 +00:00
2005-01-08 17:23:29 +00:00
/* Inherit specially named variables from parent channel */
2006-12-19 09:58:40 +00:00
ast_channel_inherit_variables ( chan , tc ) ;
2008-09-13 13:54:15 +00:00
ast_channel_datastore_inherit ( chan , tc ) ;
2004-11-01 02:23:28 +00:00
2012-02-13 17:27:06 +00:00
ast_channel_appl_set ( tc , " AppDial " ) ;
ast_channel_data_set ( tc , " (Outgoing Line) " ) ;
2012-02-29 16:52:47 +00:00
memset ( ast_channel_whentohangup ( tc ) , 0 , sizeof ( * ast_channel_whentohangup ( tc ) ) ) ;
2006-04-19 16:19:52 +00:00
2011-03-18 02:31:27 +00:00
/* Determine CallerID to store in outgoing channel. */
2012-02-29 16:52:47 +00:00
ast_party_caller_set_init ( & caller , ast_channel_caller ( tc ) ) ;
2011-03-18 02:31:27 +00:00
if ( ast_test_flag64 ( peerflags , OPT_ORIGINAL_CLID ) ) {
caller . id = stored_clid ;
ast_channel_set_caller_event ( tc , & caller , NULL ) ;
ast_set_flag64 ( tmp , DIAL_CALLERID_ABSENT ) ;
2012-02-29 16:52:47 +00:00
} else if ( ast_strlen_zero ( S_COR ( ast_channel_caller ( tc ) - > id . number . valid ,
ast_channel_caller ( tc ) - > id . number . str , NULL ) ) ) {
2011-03-18 02:31:27 +00:00
/*
* The new channel has no preset CallerID number by the channel
* driver . Use the dialplan extension and hint name .
*/
caller . id = stored_clid ;
if ( ! caller . id . name . valid
2012-02-29 16:52:47 +00:00
& & ! ast_strlen_zero ( S_COR ( ast_channel_connected ( chan ) - > id . name . valid ,
ast_channel_connected ( chan ) - > id . name . str , NULL ) ) ) {
2011-03-18 02:31:27 +00:00
/*
* No hint name available . We have a connected name supplied by
* the dialplan we can use instead .
*/
2011-04-26 18:02:07 +00:00
caller . id . name . valid = 1 ;
2012-02-29 16:52:47 +00:00
caller . id . name = ast_channel_connected ( chan ) - > id . name ;
2009-04-03 22:41:46 +00:00
}
2011-03-18 02:31:27 +00:00
ast_channel_set_caller_event ( tc , & caller , NULL ) ;
2010-05-20 19:40:03 +00:00
ast_set_flag64 ( tmp , DIAL_CALLERID_ABSENT ) ;
2012-02-29 16:52:47 +00:00
} else if ( ast_strlen_zero ( S_COR ( ast_channel_caller ( tc ) - > id . name . valid , ast_channel_caller ( tc ) - > id . name . str ,
2011-03-18 02:31:27 +00:00
NULL ) ) ) {
/* The new channel has no preset CallerID name by the channel driver. */
2012-02-29 16:52:47 +00:00
if ( ! ast_strlen_zero ( S_COR ( ast_channel_connected ( chan ) - > id . name . valid ,
ast_channel_connected ( chan ) - > id . name . str , NULL ) ) ) {
2011-03-18 02:31:27 +00:00
/*
* We have a connected name supplied by the dialplan we can
* use instead .
*/
2011-04-26 18:02:07 +00:00
caller . id . name . valid = 1 ;
2012-02-29 16:52:47 +00:00
caller . id . name = ast_channel_connected ( chan ) - > id . name ;
2011-03-18 02:31:27 +00:00
ast_channel_set_caller_event ( tc , & caller , NULL ) ;
}
2009-04-03 22:41:46 +00:00
}
2010-01-05 18:46:19 +00:00
2011-03-18 02:31:27 +00:00
/* Determine CallerID for outgoing channel to send. */
if ( ast_test_flag64 ( peerflags , OPT_FORCECLID ) & & ! force_forwards_only ) {
2010-01-05 18:46:19 +00:00
struct ast_party_connected_line connected ;
2012-02-29 16:52:47 +00:00
ast_party_connected_line_set_init ( & connected , ast_channel_connected ( tc ) ) ;
2011-03-18 02:31:27 +00:00
connected . id = forced_clid ;
2011-02-15 19:53:32 +00:00
ast_channel_set_connected_line ( tc , & connected , NULL ) ;
2010-01-05 18:46:19 +00:00
} else {
2012-02-29 16:52:47 +00:00
ast_connected_line_copy_from_caller ( ast_channel_connected ( tc ) , ast_channel_caller ( chan ) ) ;
2010-01-05 18:46:19 +00:00
}
2009-04-03 22:41:46 +00:00
2012-02-29 16:52:47 +00:00
ast_party_redirecting_copy ( ast_channel_redirecting ( tc ) , ast_channel_redirecting ( chan ) ) ;
2009-04-03 22:41:46 +00:00
2012-02-29 16:52:47 +00:00
ast_channel_dialed ( tc ) - > transit_network_select = ast_channel_dialed ( chan ) - > transit_network_select ;
2009-04-03 22:41:46 +00:00
2012-01-24 20:12:09 +00:00
if ( ! ast_strlen_zero ( ast_channel_accountcode ( chan ) ) ) {
2012-02-29 19:48:33 +00:00
ast_channel_accountcode_set ( tc , ast_channel_accountcode ( chan ) ) ;
2009-06-26 15:28:53 +00:00
}
2012-02-29 19:48:33 +00:00
if ( ast_strlen_zero ( ast_channel_musicclass ( tc ) ) ) {
2012-01-24 20:12:09 +00:00
ast_channel_musicclass_set ( tc , ast_channel_musicclass ( chan ) ) ;
2012-02-29 19:48:33 +00:00
}
2009-04-03 22:41:46 +00:00
/* Pass ADSI CPE and transfer capability */
2012-02-20 23:43:27 +00:00
ast_channel_adsicpe_set ( tc , ast_channel_adsicpe ( chan ) ) ;
ast_channel_transfercapability_set ( tc , ast_channel_transfercapability ( chan ) ) ;
2004-11-07 21:49:43 +00:00
/* If we have an outbound group, set this peer channel to it */
if ( outbound_group )
2006-12-19 09:58:40 +00:00
ast_app_group_set_channel ( tc , outbound_group ) ;
2009-01-29 17:08:22 +00:00
/* If the calling channel has the ANSWERED_ELSEWHERE flag set, inherit it. This is to support local channels */
2012-03-13 18:20:34 +00:00
if ( ast_test_flag ( ast_channel_flags ( chan ) , AST_FLAG_ANSWERED_ELSEWHERE ) )
ast_set_flag ( ast_channel_flags ( tc ) , AST_FLAG_ANSWERED_ELSEWHERE ) ;
2009-01-29 17:08:22 +00:00
/* Check if we're forced by configuration */
if ( ast_test_flag64 ( & opts , OPT_CANCEL_ELSEWHERE ) )
2012-03-13 18:20:34 +00:00
ast_set_flag ( ast_channel_flags ( tc ) , AST_FLAG_ANSWERED_ELSEWHERE ) ;
2009-01-29 17:08:22 +00:00
2004-11-07 21:49:43 +00:00
2006-10-13 21:20:18 +00:00
/* Inherit context and extension */
2012-02-13 17:27:06 +00:00
ast_channel_dialcontext_set ( tc , ast_strlen_zero ( ast_channel_macrocontext ( chan ) ) ? ast_channel_context ( chan ) : ast_channel_macrocontext ( chan ) ) ;
if ( ! ast_strlen_zero ( ast_channel_macroexten ( chan ) ) )
ast_channel_exten_set ( tc , ast_channel_macroexten ( chan ) ) ;
2007-02-16 18:53:17 +00:00
else
2012-02-13 17:27:06 +00:00
ast_channel_exten_set ( tc , ast_channel_exten ( chan ) ) ;
2006-10-13 21:20:18 +00:00
2009-04-10 17:32:25 +00:00
ast_channel_unlock ( tc ) ;
2011-09-26 19:40:12 +00:00
ast_channel_unlock ( chan ) ;
2008-02-09 11:27:10 +00:00
res = ast_call ( tc , numsubst , 0 ) ; /* Place the call, but don't wait on the answer */
2011-09-26 19:40:12 +00:00
ast_channel_lock ( chan ) ;
2003-08-14 20:48:44 +00:00
/* Save the info in cdr's that we called them */
2012-02-20 23:43:27 +00:00
if ( ast_channel_cdr ( chan ) )
ast_cdr_setdestchan ( ast_channel_cdr ( chan ) , ast_channel_name ( tc ) ) ;
2003-08-14 20:48:44 +00:00
2004-06-20 06:24:25 +00:00
/* check the results of ast_call */
1999-12-04 21:35:07 +00:00
if ( res ) {
/* Again, keep going even if there's an error */
2007-06-14 19:39:12 +00:00
ast_debug ( 1 , " ast call on peer returned %d \n " , res ) ;
2011-03-18 02:31:27 +00:00
ast_verb ( 3 , " Couldn't call %s/%s \n " , tech , numsubst ) ;
2012-02-20 23:43:27 +00:00
if ( ast_channel_hangupcause ( tc ) ) {
ast_channel_hangupcause_set ( chan , ast_channel_hangupcause ( tc ) ) ;
2008-11-20 17:39:06 +00:00
}
2009-04-03 22:41:46 +00:00
ast_channel_unlock ( chan ) ;
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
ast_cc_call_failed ( chan , tc , interface ) ;
2006-12-19 09:58:40 +00:00
ast_hangup ( tc ) ;
tc = NULL ;
2009-10-09 18:13:57 +00:00
chanlist_free ( tmp ) ;
1999-12-04 21:35:07 +00:00
continue ;
2005-01-16 07:58:51 +00:00
} else {
2007-12-06 15:04:34 +00:00
senddialevent ( chan , tc , numsubst ) ;
2011-03-18 02:31:27 +00:00
ast_verb ( 3 , " Called %s/%s \n " , tech , numsubst ) ;
2009-04-09 20:40:34 +00:00
ast_channel_unlock ( chan ) ;
2005-01-16 07:58:51 +00:00
}
2008-02-09 11:27:10 +00:00
/* Put them in the list of outgoing thingies... We're ready now.
1999-12-04 21:35:07 +00:00
XXX If we ' re forcibly removed , these outgoing calls won ' t get
hung up XXX */
2008-02-09 11:27:10 +00:00
ast_set_flag64 ( tmp , DIAL_STILLGOING ) ;
2006-12-19 09:58:40 +00:00
tmp - > chan = tc ;
1999-12-04 21:35:07 +00:00
tmp - > next = outgoing ;
outgoing = tmp ;
2002-09-02 15:20:28 +00:00
/* If this line is up, don't try anybody else */
2012-02-20 23:43:27 +00:00
if ( ast_channel_state ( outgoing - > chan ) = = AST_STATE_UP )
2002-09-02 15:20:28 +00:00
break ;
2006-04-19 14:02:49 +00:00
}
2001-03-30 18:47:35 +00:00
2006-04-19 14:02:49 +00:00
if ( ast_strlen_zero ( args . timeout ) ) {
to = - 1 ;
} else {
2005-11-02 21:46:52 +00:00
to = atoi ( args . timeout ) ;
2004-04-02 07:47:23 +00:00
if ( to > 0 )
to * = 1000 ;
2008-10-14 23:57:46 +00:00
else {
ast_log ( LOG_WARNING , " Invalid timeout specified: '%s'. Setting timeout to infinite \n " , args . timeout ) ;
to = - 1 ;
}
2006-04-19 14:02:49 +00:00
}
2004-06-21 18:28:35 +00:00
2006-04-19 14:02:49 +00:00
if ( ! outgoing ) {
2006-11-04 11:00:49 +00:00
strcpy ( pa . status , " CHANUNAVAIL " ) ;
2007-12-12 20:05:13 +00:00
if ( fulldial = = num_dialed ) {
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
res = - 1 ;
goto out ;
}
2006-04-19 14:02:49 +00:00
} else {
2004-06-23 03:16:58 +00:00
/* Our status will at least be NOANSWER */
2006-11-04 11:00:49 +00:00
strcpy ( pa . status , " NOANSWER " ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( outgoing , OPT_MUSICBACK ) ) {
2006-07-19 20:44:39 +00:00
moh = 1 ;
2007-02-09 19:39:26 +00:00
if ( ! ast_strlen_zero ( opt_args [ OPT_ARG_MUSICBACK ] ) ) {
2012-01-24 20:12:09 +00:00
char * original_moh = ast_strdupa ( ast_channel_musicclass ( chan ) ) ;
ast_channel_musicclass_set ( chan , opt_args [ OPT_ARG_MUSICBACK ] ) ;
2007-02-09 19:39:26 +00:00
ast_moh_start ( chan , opt_args [ OPT_ARG_MUSICBACK ] , NULL ) ;
2012-01-24 20:12:09 +00:00
ast_channel_musicclass_set ( chan , original_moh ) ;
2007-02-09 19:39:26 +00:00
} else {
ast_moh_start ( chan , NULL , NULL ) ;
}
2006-12-01 23:39:59 +00:00
ast_indicate ( chan , AST_CONTROL_PROGRESS ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
} else if ( ast_test_flag64 ( outgoing , OPT_RINGBACK ) ) {
2009-12-19 08:59:31 +00:00
if ( ! ast_strlen_zero ( opt_args [ OPT_ARG_RINGBACK ] ) ) {
if ( dial_handle_playtones ( chan , opt_args [ OPT_ARG_RINGBACK ] ) ) {
ast_indicate ( chan , AST_CONTROL_RINGING ) ;
sentringing + + ;
} else {
ast_indicate ( chan , AST_CONTROL_PROGRESS ) ;
}
} else {
ast_indicate ( chan , AST_CONTROL_RINGING ) ;
sentringing + + ;
}
2004-06-22 13:53:45 +00:00
}
2006-04-19 14:02:49 +00:00
}
2004-06-21 18:28:35 +00:00
2011-03-18 02:31:27 +00:00
peer = wait_for_answer ( chan , outgoing , & to , peerflags , opt_args , & pa , & num , & result ,
dtmf_progress , ignore_cc , & forced_clid , & stored_clid ) ;
Merged revisions 90735 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@90873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-12-04 17:08:36 +00:00
2011-05-18 20:07:07 +00:00
/* The ast_channel_datastore_remove() function could fail here if the
* datastore was moved to another channel during a masquerade . If this is
* the case , don ' t free the datastore here because later , when the channel
* to which the datastore was moved hangs up , it will attempt to free this
* datastore again , causing a crash
*/
ast_channel_lock ( chan ) ;
2011-07-18 20:51:47 +00:00
datastore = ast_channel_datastore_find ( chan , & dialed_interface_info , NULL ) ; /* make sure we weren't cleaned up already */
if ( datastore & & ! ast_channel_datastore_remove ( chan , datastore ) ) {
2011-05-18 20:07:07 +00:00
ast_datastore_free ( datastore ) ;
}
ast_channel_unlock ( chan ) ;
1999-12-04 21:35:07 +00:00
if ( ! peer ) {
2005-01-18 03:12:53 +00:00
if ( result ) {
res = result ;
2006-04-19 14:02:49 +00:00
} else if ( to ) { /* Musta gotten hung up */
1999-12-04 21:35:07 +00:00
res = - 1 ;
2006-04-19 14:02:49 +00:00
} else { /* Nobody answered, next please? */
2005-09-07 19:13:00 +00:00
res = 0 ;
2006-04-19 14:02:49 +00:00
}
} else {
2006-04-19 16:36:15 +00:00
const char * number ;
2009-11-04 21:39:33 +00:00
if ( ast_test_flag64 ( & opts , OPT_CALLER_ANSWER ) )
ast_answer ( chan ) ;
2006-11-04 11:00:49 +00:00
strcpy ( pa . status , " ANSWER " ) ;
2008-10-31 18:55:33 +00:00
pbx_builtin_setvar_helper ( chan , " DIALSTATUS " , pa . status ) ;
1999-12-04 21:35:07 +00:00
/* Ah ha! Someone answered within the desired timeframe. Of course after this
2008-02-09 11:27:10 +00:00
we will always return with - 1 so that it is hung up properly after the
1999-12-04 21:35:07 +00:00
conversation . */
2007-07-09 08:27:37 +00:00
hanguptree ( outgoing , peer , 1 ) ;
1999-12-04 21:35:07 +00:00
outgoing = NULL ;
2009-11-04 21:39:33 +00:00
/* If appropriate, log that we have a destination channel and set the answer time */
2012-02-20 23:43:27 +00:00
if ( ast_channel_cdr ( chan ) ) {
ast_cdr_setdestchan ( ast_channel_cdr ( chan ) , ast_channel_name ( peer ) ) ;
ast_cdr_setanswer ( ast_channel_cdr ( chan ) , ast_channel_cdr ( peer ) - > answer ) ;
2009-11-04 21:39:33 +00:00
}
2012-01-09 22:15:50 +00:00
if ( ast_channel_name ( peer ) )
pbx_builtin_setvar_helper ( chan , " DIALEDPEERNAME " , ast_channel_name ( peer ) ) ;
2008-06-18 13:09:02 +00:00
ast_channel_lock ( peer ) ;
number = pbx_builtin_getvar_helper ( peer , " DIALEDPEERNUMBER " ) ;
2005-01-27 16:33:12 +00:00
if ( ! number )
number = numsubst ;
pbx_builtin_setvar_helper ( chan , " DIALEDPEERNUMBER " , number ) ;
2008-06-18 13:09:02 +00:00
ast_channel_unlock ( peer ) ;
2008-02-09 11:27:10 +00:00
if ( ! ast_strlen_zero ( args . url ) & & ast_channel_supports_html ( peer ) ) {
ast_debug ( 1 , " app_dial: sendurl=%s. \n " , args . url ) ;
ast_channel_sendurl ( peer , args . url ) ;
}
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ( ast_test_flag64 ( & opts , OPT_PRIVACY ) | | ast_test_flag64 ( & opts , OPT_SCREENING ) ) & & pa . privdb_val = = AST_PRIVACY_UNKNOWN ) {
2006-11-04 11:00:49 +00:00
if ( do_privacy ( chan , peer , & opts , opt_args , & pa ) ) {
2006-04-19 18:00:32 +00:00
res = 0 ;
goto out ;
}
2005-07-12 03:23:31 +00:00
}
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ! ast_test_flag64 ( & opts , OPT_ANNOUNCE ) | | ast_strlen_zero ( opt_args [ OPT_ARG_ANNOUNCE ] ) ) {
2006-04-19 14:02:49 +00:00
res = 0 ;
} else {
2006-04-19 16:54:04 +00:00
int digit = 0 ;
2009-11-04 21:03:33 +00:00
struct ast_channel * chans [ 2 ] ;
struct ast_channel * active_chan ;
chans [ 0 ] = chan ;
chans [ 1 ] = peer ;
/* we need to stream the announcment while monitoring the caller for a hangup */
/* stream the file */
2012-01-24 20:12:09 +00:00
res = ast_streamfile ( peer , opt_args [ OPT_ARG_ANNOUNCE ] , ast_channel_language ( peer ) ) ;
2009-11-04 21:03:33 +00:00
if ( res ) {
res = 0 ;
ast_log ( LOG_ERROR , " error streaming file '%s' to callee \n " , opt_args [ OPT_ARG_ANNOUNCE ] ) ;
2004-05-20 00:29:09 +00:00
}
2012-03-13 18:20:34 +00:00
ast_set_flag ( ast_channel_flags ( peer ) , AST_FLAG_END_DTMF_ONLY ) ;
2012-02-20 23:43:27 +00:00
while ( ast_channel_stream ( peer ) ) {
2009-11-04 21:03:33 +00:00
int ms ;
2012-02-20 23:43:27 +00:00
ms = ast_sched_wait ( ast_channel_sched ( peer ) ) ;
2009-11-04 21:03:33 +00:00
2012-03-13 18:20:34 +00:00
if ( ms < 0 & & ! ast_channel_timingfunc ( peer ) ) {
2009-11-04 21:03:33 +00:00
ast_stopstream ( peer ) ;
break ;
}
if ( ms < 0 )
ms = 1000 ;
active_chan = ast_waitfor_n ( chans , 2 , & ms ) ;
if ( active_chan ) {
struct ast_frame * fr = ast_read ( active_chan ) ;
if ( ! fr ) {
ast_hangup ( peer ) ;
res = - 1 ;
goto done ;
}
switch ( fr - > frametype ) {
case AST_FRAME_DTMF_END :
digit = fr - > subclass . integer ;
if ( active_chan = = peer & & strchr ( AST_DIGIT_ANY , res ) ) {
ast_stopstream ( peer ) ;
res = ast_senddigit ( chan , digit , 0 ) ;
}
break ;
case AST_FRAME_CONTROL :
switch ( fr - > subclass . integer ) {
case AST_CONTROL_HANGUP :
ast_frfree ( fr ) ;
ast_hangup ( peer ) ;
res = - 1 ;
goto done ;
default :
break ;
}
break ;
default :
/* Ignore all others */
break ;
}
ast_frfree ( fr ) ;
}
2012-02-20 23:43:27 +00:00
ast_sched_runq ( ast_channel_sched ( peer ) ) ;
2009-11-04 21:03:33 +00:00
}
2012-03-13 18:20:34 +00:00
ast_clear_flag ( ast_channel_flags ( peer ) , AST_FLAG_END_DTMF_ONLY ) ;
2006-04-19 14:02:49 +00:00
}
2005-03-17 22:39:04 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( chan & & peer & & ast_test_flag64 ( & opts , OPT_GOTO ) & & ! ast_strlen_zero ( opt_args [ OPT_ARG_GOTO ] ) ) {
2010-07-09 16:05:58 +00:00
/* chan and peer are going into the PBX, they both
* should probably get CDR records . */
2012-02-20 23:43:27 +00:00
ast_clear_flag ( ast_channel_cdr ( chan ) , AST_CDR_FLAG_DIALED ) ;
ast_clear_flag ( ast_channel_cdr ( peer ) , AST_CDR_FLAG_DIALED ) ;
2010-07-09 16:05:58 +00:00
2006-04-19 14:02:49 +00:00
replace_macro_delimiter ( opt_args [ OPT_ARG_GOTO ] ) ;
2005-11-02 21:46:52 +00:00
ast_parseable_goto ( chan , opt_args [ OPT_ARG_GOTO ] ) ;
2007-12-05 22:55:49 +00:00
/* peer goes to the same context and extension as chan, so just copy info from chan*/
2012-02-13 17:27:06 +00:00
ast_channel_context_set ( peer , ast_channel_context ( chan ) ) ;
ast_channel_exten_set ( peer , ast_channel_exten ( chan ) ) ;
2012-02-20 23:43:27 +00:00
ast_channel_priority_set ( peer , ast_channel_priority ( chan ) + 2 ) ;
2005-03-17 22:39:04 +00:00
ast_pbx_start ( peer ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
hanguptree ( outgoing , NULL , ast_test_flag64 ( & opts , OPT_CANCEL_ELSEWHERE ) ? 1 : 0 ) ;
2007-02-15 16:24:13 +00:00
if ( continue_exec )
* continue_exec = 1 ;
res = 0 ;
2006-04-19 14:02:49 +00:00
goto done ;
2005-03-17 22:39:04 +00:00
}
2003-07-02 14:06:12 +00:00
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( & opts , OPT_CALLEE_MACRO ) & & ! ast_strlen_zero ( opt_args [ OPT_ARG_CALLEE_MACRO ] ) ) {
2006-04-19 16:54:04 +00:00
struct ast_app * theapp ;
2006-04-19 18:07:19 +00:00
const char * macro_result ;
2006-04-19 16:54:04 +00:00
2004-09-10 02:31:30 +00:00
res = ast_autoservice_start ( chan ) ;
if ( res ) {
ast_log ( LOG_ERROR , " Unable to start autoservice on calling channel \n " ) ;
res = - 1 ;
}
2006-04-19 16:54:04 +00:00
theapp = pbx_findapp ( " Macro " ) ;
2004-09-10 02:31:30 +00:00
2008-02-09 11:27:10 +00:00
if ( theapp & & ! res ) { /* XXX why check res here ? */
2009-01-09 00:13:12 +00:00
/* Set peer->exten and peer->context so that MACRO_EXTEN and MACRO_CONTEXT get set */
2012-02-13 17:27:06 +00:00
ast_channel_context_set ( peer , ast_channel_context ( chan ) ) ;
ast_channel_exten_set ( peer , ast_channel_exten ( chan ) ) ;
2009-01-09 00:13:12 +00:00
2006-04-19 14:02:49 +00:00
replace_macro_delimiter ( opt_args [ OPT_ARG_CALLEE_MACRO ] ) ;
2006-04-19 16:54:04 +00:00
res = pbx_exec ( peer , theapp , opt_args [ OPT_ARG_CALLEE_MACRO ] ) ;
2007-06-14 19:39:12 +00:00
ast_debug ( 1 , " Macro exited with status %d \n " , res ) ;
2004-09-10 02:31:30 +00:00
res = 0 ;
} else {
ast_log ( LOG_ERROR , " Could not find application Macro \n " ) ;
res = - 1 ;
}
if ( ast_autoservice_stop ( chan ) < 0 ) {
res = - 1 ;
}
2004-11-22 22:11:10 +00:00
2008-06-18 13:09:02 +00:00
ast_channel_lock ( peer ) ;
2006-04-19 18:07:19 +00:00
if ( ! res & & ( macro_result = pbx_builtin_getvar_helper ( peer , " MACRO_RESULT " ) ) ) {
2006-11-04 01:16:20 +00:00
char * macro_transfer_dest ;
2005-01-05 23:05:49 +00:00
2006-11-04 01:16:20 +00:00
if ( ! strcasecmp ( macro_result , " BUSY " ) ) {
2006-11-04 11:00:49 +00:00
ast_copy_string ( pa . status , macro_result , sizeof ( pa . status ) ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
ast_set_flag64 ( peerflags , OPT_GO_ON ) ;
2006-11-04 01:16:20 +00:00
res = - 1 ;
} else if ( ! strcasecmp ( macro_result , " CONGESTION " ) | | ! strcasecmp ( macro_result , " CHANUNAVAIL " ) ) {
2006-11-04 11:00:49 +00:00
ast_copy_string ( pa . status , macro_result , sizeof ( pa . status ) ) ;
2008-02-09 11:27:10 +00:00
ast_set_flag64 ( peerflags , OPT_GO_ON ) ;
2006-11-04 01:16:20 +00:00
res = - 1 ;
} else if ( ! strcasecmp ( macro_result , " CONTINUE " ) ) {
2008-02-09 11:27:10 +00:00
/* hangup peer and keep chan alive assuming the macro has changed
the context / exten / priority or perhaps
2006-11-04 01:16:20 +00:00
the next priority in the current exten is desired .
*/
2008-02-09 11:27:10 +00:00
ast_set_flag64 ( peerflags , OPT_GO_ON ) ;
2006-11-04 01:16:20 +00:00
res = - 1 ;
} else if ( ! strcasecmp ( macro_result , " ABORT " ) ) {
/* Hangup both ends unless the caller has the g flag */
res = - 1 ;
} else if ( ! strncasecmp ( macro_result , " GOTO: " , 5 ) & & ( macro_transfer_dest = ast_strdupa ( macro_result + 5 ) ) ) {
res = - 1 ;
/* perform a transfer to a new extension */
if ( strchr ( macro_transfer_dest , ' ^ ' ) ) { /* context^exten^priority*/
replace_macro_delimiter ( macro_transfer_dest ) ;
if ( ! ast_parseable_goto ( chan , macro_transfer_dest ) )
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
ast_set_flag64 ( peerflags , OPT_GO_ON ) ;
2004-11-22 22:11:10 +00:00
}
2006-11-04 01:16:20 +00:00
}
2004-11-22 22:11:10 +00:00
}
2008-06-18 13:09:02 +00:00
ast_channel_unlock ( peer ) ;
2004-09-10 02:31:30 +00:00
}
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( & opts , OPT_CALLEE_GOSUB ) & & ! ast_strlen_zero ( opt_args [ OPT_ARG_CALLEE_GOSUB ] ) ) {
2007-06-19 23:36:34 +00:00
struct ast_app * theapp ;
const char * gosub_result ;
2007-06-20 17:35:08 +00:00
char * gosub_args , * gosub_argstart ;
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
int res9 = - 1 ;
2007-06-19 23:36:34 +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
res9 = ast_autoservice_start ( chan ) ;
if ( res9 ) {
2007-06-19 23:36:34 +00:00
ast_log ( LOG_ERROR , " Unable to start autoservice on calling channel \n " ) ;
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
res9 = - 1 ;
2007-06-19 23:36:34 +00:00
}
theapp = pbx_findapp ( " Gosub " ) ;
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 ( theapp & & ! res9 ) {
2007-06-19 23:36:34 +00:00
replace_macro_delimiter ( opt_args [ OPT_ARG_CALLEE_GOSUB ] ) ;
2007-06-20 17:35:08 +00:00
/* Set where we came from */
2012-02-13 17:27:06 +00:00
ast_channel_context_set ( peer , " app_dial_gosub_virtual_context " ) ;
ast_channel_exten_set ( peer , " s " ) ;
2012-02-20 23:43:27 +00:00
ast_channel_priority_set ( peer , 0 ) ;
2007-06-20 17:35:08 +00:00
2008-05-30 16:10:46 +00:00
gosub_argstart = strchr ( opt_args [ OPT_ARG_CALLEE_GOSUB ] , ' , ' ) ;
2007-06-20 17:35:08 +00:00
if ( gosub_argstart ) {
2011-02-14 06:54:08 +00:00
const char * what_is_s = " s " ;
2007-06-20 17:35:08 +00:00
* gosub_argstart = 0 ;
2012-02-29 16:52:47 +00:00
if ( ! ast_exists_extension ( peer , opt_args [ OPT_ARG_CALLEE_GOSUB ] , " s " , 1 , S_COR ( ast_channel_caller ( peer ) - > id . number . valid , ast_channel_caller ( peer ) - > id . number . str , NULL ) ) & &
ast_exists_extension ( peer , opt_args [ OPT_ARG_CALLEE_GOSUB ] , " ~~s~~ " , 1 , S_COR ( ast_channel_caller ( peer ) - > id . number . valid , ast_channel_caller ( peer ) - > id . number . str , NULL ) ) ) {
2011-02-14 06:54:08 +00:00
what_is_s = " ~~s~~ " ;
}
if ( asprintf ( & gosub_args , " %s,%s,1(%s) " , opt_args [ OPT_ARG_CALLEE_GOSUB ] , what_is_s , gosub_argstart + 1 ) < 0 ) {
2008-11-02 18:52:13 +00:00
ast_log ( LOG_WARNING , " asprintf() failed: %s \n " , strerror ( errno ) ) ;
gosub_args = NULL ;
}
2008-05-30 16:10:46 +00:00
* gosub_argstart = ' , ' ;
2007-06-20 17:35:08 +00:00
} else {
2011-02-14 06:54:08 +00:00
const char * what_is_s = " s " ;
2012-02-29 16:52:47 +00:00
if ( ! ast_exists_extension ( peer , opt_args [ OPT_ARG_CALLEE_GOSUB ] , " s " , 1 , S_COR ( ast_channel_caller ( peer ) - > id . number . valid , ast_channel_caller ( peer ) - > id . number . str , NULL ) ) & &
ast_exists_extension ( peer , opt_args [ OPT_ARG_CALLEE_GOSUB ] , " ~~s~~ " , 1 , S_COR ( ast_channel_caller ( peer ) - > id . number . valid , ast_channel_caller ( peer ) - > id . number . str , NULL ) ) ) {
2011-02-14 06:54:08 +00:00
what_is_s = " ~~s~~ " ;
}
if ( asprintf ( & gosub_args , " %s,%s,1 " , opt_args [ OPT_ARG_CALLEE_GOSUB ] , what_is_s ) < 0 ) {
2008-11-02 18:52:13 +00:00
ast_log ( LOG_WARNING , " asprintf() failed: %s \n " , strerror ( errno ) ) ;
gosub_args = NULL ;
}
2007-06-20 17:35:08 +00:00
}
2007-06-20 21:38:49 +00:00
2007-06-20 17:35:08 +00:00
if ( gosub_args ) {
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
res9 = pbx_exec ( peer , theapp , gosub_args ) ;
2008-12-03 18:37:46 +00:00
if ( ! res9 ) {
2012-03-08 17:48:14 +00:00
struct ast_pbx_args pbx_args ;
2008-12-18 19:33:42 +00:00
/* A struct initializer fails to compile for this case ... */
2012-03-08 17:48:14 +00:00
memset ( & pbx_args , 0 , sizeof ( pbx_args ) ) ;
pbx_args . no_hangup_chan = 1 ;
ast_pbx_run_args ( peer , & pbx_args ) ;
2008-12-03 18:37:46 +00:00
}
2007-12-12 20:05:13 +00:00
ast_free ( gosub_args ) ;
2008-12-29 18:04:52 +00:00
ast_debug ( 1 , " Gosub exited with status %d \n " , res9 ) ;
2008-12-03 18:37:46 +00:00
} else {
2007-06-20 17:35:08 +00:00
ast_log ( LOG_ERROR , " Could not Allocate string for Gosub arguments -- Gosub Call Aborted! \n " ) ;
2008-12-03 18:37:46 +00:00
}
2008-02-09 11:27:10 +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
} else if ( ! res9 ) {
2007-06-19 23:36:34 +00:00
ast_log ( LOG_ERROR , " Could not find application Gosub \n " ) ;
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
res9 = - 1 ;
2007-06-19 23:36:34 +00:00
}
if ( ast_autoservice_stop ( chan ) < 0 ) {
ast_log ( LOG_ERROR , " Could not stop autoservice on calling channel \n " ) ;
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
res9 = - 1 ;
2007-06-19 23:36:34 +00:00
}
2008-06-18 13:09:02 +00:00
ast_channel_lock ( peer ) ;
2007-06-19 23:36:34 +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
if ( ! res9 & & ( gosub_result = pbx_builtin_getvar_helper ( peer , " GOSUB_RESULT " ) ) ) {
2007-06-19 23:36:34 +00:00
char * gosub_transfer_dest ;
2010-02-02 20:32:29 +00:00
const char * gosub_retval = pbx_builtin_getvar_helper ( peer , " GOSUB_RETVAL " ) ;
/* Inherit return value from the peer, so it can be used in the master */
if ( gosub_retval ) {
pbx_builtin_setvar_helper ( chan , " GOSUB_RETVAL " , gosub_retval ) ;
}
2007-06-19 23:36:34 +00:00
if ( ! strcasecmp ( gosub_result , " BUSY " ) ) {
ast_copy_string ( pa . status , gosub_result , sizeof ( pa . status ) ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
ast_set_flag64 ( peerflags , OPT_GO_ON ) ;
2010-02-02 20:32:29 +00:00
res = - 1 ;
2007-06-19 23:36:34 +00:00
} else if ( ! strcasecmp ( gosub_result , " CONGESTION " ) | | ! strcasecmp ( gosub_result , " CHANUNAVAIL " ) ) {
ast_copy_string ( pa . status , gosub_result , sizeof ( pa . status ) ) ;
2008-02-09 11:27:10 +00:00
ast_set_flag64 ( peerflags , OPT_GO_ON ) ;
2010-02-02 20:32:29 +00:00
res = - 1 ;
2007-06-19 23:36:34 +00:00
} else if ( ! strcasecmp ( gosub_result , " CONTINUE " ) ) {
2008-02-09 11:27:10 +00:00
/* hangup peer and keep chan alive assuming the macro has changed
the context / exten / priority or perhaps
2007-06-19 23:36:34 +00:00
the next priority in the current exten is desired .
*/
2008-02-09 11:27:10 +00:00
ast_set_flag64 ( peerflags , OPT_GO_ON ) ;
2010-02-02 20:32:29 +00:00
res = - 1 ;
2007-06-19 23:36:34 +00:00
} else if ( ! strcasecmp ( gosub_result , " ABORT " ) ) {
/* Hangup both ends unless the caller has the g flag */
2010-02-02 20:32:29 +00:00
res = - 1 ;
2007-06-19 23:36:34 +00:00
} else if ( ! strncasecmp ( gosub_result , " GOTO: " , 5 ) & & ( gosub_transfer_dest = ast_strdupa ( gosub_result + 5 ) ) ) {
2010-02-02 20:32:29 +00:00
res = - 1 ;
2007-06-19 23:36:34 +00:00
/* perform a transfer to a new extension */
if ( strchr ( gosub_transfer_dest , ' ^ ' ) ) { /* context^exten^priority*/
replace_macro_delimiter ( gosub_transfer_dest ) ;
if ( ! ast_parseable_goto ( chan , gosub_transfer_dest ) )
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
ast_set_flag64 ( peerflags , OPT_GO_ON ) ;
2007-06-19 23:36:34 +00:00
}
}
}
2008-06-18 13:09:02 +00:00
ast_channel_unlock ( peer ) ;
2007-06-19 23:36:34 +00:00
}
2004-05-07 21:14:55 +00:00
if ( ! res ) {
2008-11-12 21:34:51 +00:00
if ( ! ast_tvzero ( calldurationlimit ) ) {
2012-02-29 16:52:47 +00:00
struct timeval whentohangup = ast_tvadd ( ast_tvnow ( ) , calldurationlimit ) ;
ast_channel_whentohangup_set ( peer , & whentohangup ) ;
2004-05-07 21:14:55 +00:00
}
2008-02-09 11:27:10 +00:00
if ( ! ast_strlen_zero ( dtmfcalled ) ) {
2008-02-05 23:00:15 +00:00
ast_verb ( 3 , " Sending DTMF '%s' to the called party. \n " , dtmfcalled ) ;
2007-12-12 20:05:13 +00:00
res = ast_dtmf_stream ( peer , chan , dtmfcalled , 250 , 0 ) ;
2005-04-11 02:46:25 +00:00
}
2005-10-26 19:48:14 +00:00
if ( ! ast_strlen_zero ( dtmfcalling ) ) {
2008-02-05 23:00:15 +00:00
ast_verb ( 3 , " Sending DTMF '%s' to the calling party. \n " , dtmfcalling ) ;
2007-12-12 20:05:13 +00:00
res = ast_dtmf_stream ( chan , peer , dtmfcalling , 250 , 0 ) ;
2005-04-11 02:46:25 +00:00
}
2004-05-07 20:39:14 +00:00
}
2008-10-31 18:55:33 +00:00
2008-02-09 11:27:10 +00:00
if ( res ) { /* some error */
2006-11-04 01:16:20 +00:00
res = - 1 ;
} else {
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( peerflags , OPT_CALLEE_TRANSFER ) )
2005-01-10 14:46:59 +00:00
ast_set_flag ( & ( config . features_callee ) , AST_FEATURE_REDIRECT ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( peerflags , OPT_CALLER_TRANSFER ) )
2005-01-10 14:46:59 +00:00
ast_set_flag ( & ( config . features_caller ) , AST_FEATURE_REDIRECT ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( peerflags , OPT_CALLEE_HANGUP ) )
2005-01-10 14:46:59 +00:00
ast_set_flag ( & ( config . features_callee ) , AST_FEATURE_DISCONNECT ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( peerflags , OPT_CALLER_HANGUP ) )
2005-01-10 14:46:59 +00:00
ast_set_flag ( & ( config . features_caller ) , AST_FEATURE_DISCONNECT ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( peerflags , OPT_CALLEE_MONITOR ) )
2005-01-10 14:46:59 +00:00
ast_set_flag ( & ( config . features_callee ) , AST_FEATURE_AUTOMON ) ;
2008-02-09 11:27:10 +00:00
if ( ast_test_flag64 ( peerflags , OPT_CALLER_MONITOR ) )
2005-01-10 14:46:59 +00:00
ast_set_flag ( & ( config . features_caller ) , AST_FEATURE_AUTOMON ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( peerflags , OPT_CALLEE_PARK ) )
2006-05-22 16:43:43 +00:00
ast_set_flag ( & ( config . features_callee ) , AST_FEATURE_PARKCALL ) ;
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( peerflags , OPT_CALLER_PARK ) )
2006-05-22 16:43:43 +00:00
ast_set_flag ( & ( config . features_caller ) , AST_FEATURE_PARKCALL ) ;
2007-11-30 21:19:57 +00:00
if ( ast_test_flag64 ( peerflags , OPT_CALLEE_MIXMONITOR ) )
ast_set_flag ( & ( config . features_callee ) , AST_FEATURE_AUTOMIXMON ) ;
if ( ast_test_flag64 ( peerflags , OPT_CALLER_MIXMONITOR ) )
ast_set_flag ( & ( config . features_caller ) , AST_FEATURE_AUTOMIXMON ) ;
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
if ( ast_test_flag64 ( peerflags , OPT_GO_ON ) )
ast_set_flag ( & ( config . features_caller ) , AST_FEATURE_NO_H_EXTEN ) ;
2005-01-18 03:12:53 +00:00
2008-10-31 18:55:33 +00:00
config . end_bridge_callback = end_bridge_callback ;
2008-11-09 01:27:00 +00:00
config . end_bridge_callback_data = chan ;
2008-11-18 18:31:08 +00:00
config . end_bridge_callback_data_fixup = end_bridge_callback_data_fixup ;
2004-06-21 18:28:35 +00:00
if ( moh ) {
moh = 0 ;
ast_moh_stop ( chan ) ;
} else if ( sentringing ) {
sentringing = 0 ;
ast_indicate ( chan , - 1 ) ;
}
2010-08-10 17:49:36 +00:00
/* Be sure no generators are left on it and reset the visible indication */
2004-07-07 16:02:13 +00:00
ast_deactivate_generator ( chan ) ;
2012-02-20 23:43:27 +00:00
ast_channel_visible_indication_set ( chan , 0 ) ;
2004-07-07 16:02:13 +00:00
/* Make sure channels are compatible */
res = ast_channel_make_compatible ( chan , peer ) ;
if ( res < 0 ) {
2012-01-09 22:15:50 +00:00
ast_log ( LOG_WARNING , " Had to drop call because I couldn't make %s compatible with %s \n " , ast_channel_name ( chan ) , ast_channel_name ( peer ) ) ;
2004-07-07 16:02:13 +00:00
ast_hangup ( peer ) ;
2006-04-19 16:54:04 +00:00
res = - 1 ;
goto done ;
2004-07-07 16:02:13 +00:00
}
2008-10-07 21:34:44 +00:00
if ( opermode ) {
2006-04-22 11:30:06 +00:00
struct oprmode oprmode ;
oprmode . peer = peer ;
oprmode . mode = opermode ;
2007-12-14 14:48:38 +00:00
ast_channel_setoption ( chan , AST_OPTION_OPRMODE , & oprmode , sizeof ( oprmode ) , 0 ) ;
2006-04-22 11:30:06 +00:00
}
2007-12-12 20:05:13 +00:00
res = ast_bridge_call ( chan , peer , & config ) ;
2006-04-19 16:19:52 +00:00
}
2006-11-04 01:16:20 +00:00
2012-02-13 17:27:06 +00:00
ast_channel_context_set ( peer , ast_channel_context ( chan ) ) ;
2008-02-09 11:27:10 +00:00
2010-07-14 15:48:36 +00:00
if ( ast_test_flag64 ( & opts , OPT_PEER_H )
2012-02-13 17:27:06 +00:00
& & ast_exists_extension ( peer , ast_channel_context ( peer ) , " h " , 1 ,
2012-02-29 16:52:47 +00:00
S_COR ( ast_channel_caller ( peer ) - > id . number . valid , ast_channel_caller ( peer ) - > id . number . str , NULL ) ) ) {
2007-07-27 15:46:20 +00:00
int autoloopflag ;
This commits the performance mods that give the priority processing engine in the pbx, a 25-30% speed boost. The two updates used, are, first, to merge the ast_exists_extension() and the ast_spawn_extension() where they are called sequentially in a loop in the code, into a slightly upgraded version of ast_spawn_extension(), with a few extra args; and, second, I modified the substitute_variables_helper_full, so it zeroes out the byte after the evaluated string instead of demanding you pre-zero the buffer; I also went thru the code and removed the code that zeroed this buffer before every call to the substitute_variables_helper_full. The first fix provides about a 9% speedup, and the second the rest. These figures come from the 'PIPS' benchmark I describe in blogs, conf. reports, etc.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-11-01 22:26:51 +00:00
int found ;
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
int res9 ;
2012-02-13 17:27:06 +00:00
ast_channel_exten_set ( peer , " h " ) ;
2012-02-20 23:43:27 +00:00
ast_channel_priority_set ( peer , 1 ) ;
2012-03-13 18:20:34 +00:00
autoloopflag = ast_test_flag ( ast_channel_flags ( peer ) , AST_FLAG_IN_AUTOLOOP ) ; /* save value to restore at the end */
ast_set_flag ( ast_channel_flags ( peer ) , AST_FLAG_IN_AUTOLOOP ) ;
2008-02-09 11:27:10 +00:00
2012-02-13 17:27:06 +00:00
while ( ( res9 = ast_spawn_extension ( peer , ast_channel_context ( peer ) , ast_channel_exten ( peer ) ,
2012-02-20 23:43:27 +00:00
ast_channel_priority ( peer ) ,
2012-02-29 16:52:47 +00:00
S_COR ( ast_channel_caller ( peer ) - > id . number . valid , ast_channel_caller ( peer ) - > 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 ( peer , ast_channel_priority ( peer ) + 1 ) ;
2010-07-14 15:48:36 +00:00
}
2008-02-09 11:27:10 +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
if ( found & & res9 ) {
This commits the performance mods that give the priority processing engine in the pbx, a 25-30% speed boost. The two updates used, are, first, to merge the ast_exists_extension() and the ast_spawn_extension() where they are called sequentially in a loop in the code, into a slightly upgraded version of ast_spawn_extension(), with a few extra args; and, second, I modified the substitute_variables_helper_full, so it zeroes out the byte after the evaluated string instead of demanding you pre-zero the buffer; I also went thru the code and removed the code that zeroed this buffer before every call to the substitute_variables_helper_full. The first fix provides about a 9% speedup, and the second the rest. These figures come from the 'PIPS' benchmark I describe in blogs, conf. reports, etc.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-11-01 22:26:51 +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 ( peer ) , ast_channel_exten ( peer ) , ast_channel_priority ( peer ) , ast_channel_name ( peer ) ) ;
ast_verb ( 2 , " Spawn extension (%s, %s, %d) exited non-zero on '%s' \n " , ast_channel_context ( peer ) , ast_channel_exten ( peer ) , ast_channel_priority ( peer ) , ast_channel_name ( peer ) ) ;
This commits the performance mods that give the priority processing engine in the pbx, a 25-30% speed boost. The two updates used, are, first, to merge the ast_exists_extension() and the ast_spawn_extension() where they are called sequentially in a loop in the code, into a slightly upgraded version of ast_spawn_extension(), with a few extra args; and, second, I modified the substitute_variables_helper_full, so it zeroes out the byte after the evaluated string instead of demanding you pre-zero the buffer; I also went thru the code and removed the code that zeroed this buffer before every call to the substitute_variables_helper_full. The first fix provides about a 9% speedup, and the second the rest. These figures come from the 'PIPS' benchmark I describe in blogs, conf. reports, etc.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@88166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-11-01 22:26:51 +00:00
}
2012-03-13 18:20:34 +00:00
ast_set2_flag ( ast_channel_flags ( peer ) , autoloopflag , AST_FLAG_IN_AUTOLOOP ) ; /* set it back the way it was */
2007-07-17 19:40:29 +00:00
}
2009-04-09 19:10:02 +00:00
if ( ! ast_check_hangup ( peer ) & & ast_test_flag64 ( & opts , OPT_CALLEE_GO_ON ) ) {
if ( ! ast_strlen_zero ( opt_args [ OPT_ARG_CALLEE_GO_ON ] ) ) {
replace_macro_delimiter ( opt_args [ OPT_ARG_CALLEE_GO_ON ] ) ;
ast_parseable_goto ( peer , opt_args [ OPT_ARG_CALLEE_GO_ON ] ) ;
} else { /* F() */
2012-03-08 17:48:14 +00:00
int goto_res ;
goto_res = ast_goto_if_exists ( peer , ast_channel_context ( chan ) , ast_channel_exten ( chan ) , ( ast_channel_priority ( chan ) ) + 1 ) ;
if ( goto_res = = AST_PBX_GOTO_FAILED ) {
2009-04-09 19:10:02 +00:00
ast_hangup ( peer ) ;
goto out ;
}
}
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_pbx_start ( peer ) ;
} else {
if ( ! ast_check_hangup ( chan ) )
2012-02-20 23:43:27 +00:00
ast_channel_hangupcause_set ( chan , ast_channel_hangupcause ( peer ) ) ;
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 ) ;
2004-05-22 23:17:33 +00:00
}
2008-02-09 11:27:10 +00:00
}
1999-12-04 21:35:07 +00:00
out :
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 ( moh ) {
moh = 0 ;
ast_moh_stop ( chan ) ;
} else if ( sentringing ) {
sentringing = 0 ;
ast_indicate ( chan , - 1 ) ;
}
2009-11-02 18:08:54 +00:00
if ( delprivintro & & ast_fileexists ( pa . privintro , NULL , NULL ) > 0 ) {
ast_filedelete ( pa . privintro , NULL ) ;
if ( ast_fileexists ( pa . privintro , NULL , NULL ) > 0 ) {
ast_log ( LOG_NOTICE , " privacy: ast_filedelete didn't do its job on %s \n " , pa . privintro ) ;
} else {
ast_verb ( 3 , " Successfully deleted %s intro file \n " , pa . privintro ) ;
}
}
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_channel_early_bridge ( chan , NULL ) ;
hanguptree ( outgoing , NULL , 0 ) ; /* In this case, there's no answer anywhere */
pbx_builtin_setvar_helper ( chan , " DIALSTATUS " , pa . status ) ;
senddialendevent ( chan , pa . status ) ;
ast_debug ( 1 , " Exiting with DIALSTATUS=%s. \n " , pa . status ) ;
if ( ( ast_test_flag64 ( peerflags , OPT_GO_ON ) ) & & ! ast_check_hangup ( chan ) & & ( res ! = AST_PBX_INCOMPLETE ) ) {
if ( ! ast_tvzero ( calldurationlimit ) )
2012-02-29 16:52:47 +00:00
memset ( ast_channel_whentohangup ( chan ) , 0 , sizeof ( * ast_channel_whentohangup ( chan ) ) ) ;
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
res = 0 ;
2007-06-07 14:23:21 +00:00
}
2006-04-19 14:02:49 +00:00
done :
2008-11-17 22:25:06 +00:00
if ( config . warning_sound ) {
ast_free ( ( char * ) config . warning_sound ) ;
}
if ( config . end_sound ) {
ast_free ( ( char * ) config . end_sound ) ;
}
if ( config . start_sound ) {
ast_free ( ( char * ) config . start_sound ) ;
}
Merge Call completion support into trunk.
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-04-09 15:31:32 +00:00
ast_ignore_cc ( chan ) ;
1999-12-04 21:35:07 +00:00
return res ;
}
2009-05-21 21:13:09 +00:00
static int dial_exec ( struct ast_channel * chan , const char * data )
2005-01-18 03:12:53 +00:00
{
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
struct ast_flags64 peerflags ;
2007-01-10 04:56:48 +00:00
2005-01-18 03:12:53 +00:00
memset ( & peerflags , 0 , sizeof ( peerflags ) ) ;
2007-01-10 04:56:48 +00:00
2007-02-15 16:24:13 +00:00
return dial_exec_full ( chan , data , & peerflags , NULL ) ;
2005-01-18 03:12:53 +00:00
}
2009-05-21 21:13:09 +00:00
static int retrydial_exec ( struct ast_channel * chan , const char * data )
2005-01-18 03:12:53 +00:00
{
2007-07-23 19:51:41 +00:00
char * parse ;
2005-12-20 17:52:31 +00:00
const char * context = NULL ;
2008-08-10 14:45:25 +00:00
int sleepms = 0 , loops = 0 , res = - 1 ;
2007-07-23 19:51:41 +00:00
struct ast_flags64 peerflags = { 0 , } ;
AST_DECLARE_APP_ARGS ( args ,
AST_APP_ARG ( announce ) ;
AST_APP_ARG ( sleep ) ;
AST_APP_ARG ( retries ) ;
AST_APP_ARG ( dialdata ) ;
) ;
2005-10-26 19:48:14 +00:00
if ( ast_strlen_zero ( data ) ) {
2005-10-19 18:19:02 +00:00
ast_log ( LOG_WARNING , " RetryDial requires an argument! \n " ) ;
return - 1 ;
2008-02-09 11:27:10 +00:00
}
2005-01-18 03:12:53 +00:00
2007-07-23 19:51:41 +00:00
parse = ast_strdupa ( data ) ;
AST_STANDARD_APP_ARGS ( args , parse ) ;
2005-10-19 18:19:02 +00:00
2009-03-12 13:24:12 +00:00
if ( ! ast_strlen_zero ( args . sleep ) & & ( sleepms = atoi ( args . sleep ) ) )
2008-08-10 14:45:25 +00:00
sleepms * = 1000 ;
2007-07-23 19:51:41 +00:00
2009-03-12 13:24:12 +00:00
if ( ! ast_strlen_zero ( args . retries ) ) {
loops = atoi ( args . retries ) ;
}
2007-07-23 19:51:41 +00:00
if ( ! args . dialdata ) {
ast_log ( LOG_ERROR , " %s requires a 4th argument (dialdata) \n " , rapp ) ;
2006-04-19 14:02:49 +00:00
goto done ;
2005-01-18 03:12:53 +00:00
}
2008-02-09 11:27:10 +00:00
2008-08-10 14:45:25 +00:00
if ( sleepms < 1000 )
sleepms = 10000 ;
2006-04-19 14:02:49 +00:00
2005-01-18 03:12:53 +00:00
if ( ! loops )
2008-02-09 11:27:10 +00:00
loops = - 1 ; /* run forever */
2008-06-18 13:09:02 +00:00
ast_channel_lock ( chan ) ;
2005-01-18 03:12:53 +00:00
context = pbx_builtin_getvar_helper ( chan , " EXITCONTEXT " ) ;
2008-06-18 13:09:02 +00:00
context = ! ast_strlen_zero ( context ) ? ast_strdupa ( context ) : NULL ;
ast_channel_unlock ( chan ) ;
2006-04-19 14:02:49 +00:00
res = 0 ;
2005-01-18 03:12:53 +00:00
while ( loops ) {
2007-02-15 16:24:13 +00:00
int continue_exec ;
2012-02-13 17:27:06 +00:00
ast_channel_data_set ( chan , " Retrying " ) ;
2012-03-13 18:20:34 +00:00
if ( ast_test_flag ( ast_channel_flags ( chan ) , AST_FLAG_MOH ) )
2005-01-18 03:12:53 +00:00
ast_moh_stop ( chan ) ;
2007-07-23 19:51:41 +00:00
res = dial_exec_full ( chan , args . dialdata , & peerflags , & continue_exec ) ;
2007-02-15 16:24:13 +00:00
if ( continue_exec )
2007-01-10 04:56:48 +00:00
break ;
2007-07-16 18:18:19 +00:00
2007-02-15 16:24:13 +00:00
if ( res = = 0 ) {
After some study, thought, comparing, etc. I've backed out the previous universal mod to make ast_flags a 64 bit thing. Instead, I added a 64-bit version of ast_flags (ast_flags64), and 64-bit versions of the test-flag, set-flag, etc. macros, and an app_parse_options64 routine, and I use these in app_dial alone, to eliminate the 30-option limit it had grown to meet. There is room now for 32 more options and flags. I was heavily tempted to implement some of the other ideas that were presented, but this solution does not intro any new versions of dial, doesn't have a different API, has a minimal/zero impact on code outside of dial, and doesn't seriously (I hope) affect the code structure of dial. It's the best I can think of right now. My goal was NOT to rewrite dial. I leave that to a future, coordinated effort.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@75983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-07-19 23:24:27 +00:00
if ( ast_test_flag64 ( & peerflags , OPT_DTMF_EXIT ) ) {
2007-07-23 19:51:41 +00:00
if ( ! ast_strlen_zero ( args . announce ) ) {
2012-01-24 20:12:09 +00:00
if ( ast_fileexists ( args . announce , NULL , ast_channel_language ( chan ) ) > 0 ) {
if ( ! ( res = ast_streamfile ( chan , args . announce , ast_channel_language ( chan ) ) ) )
2007-07-16 18:18:19 +00:00
ast_waitstream ( chan , AST_DIGIT_ANY ) ;
} else
2007-07-23 19:51:41 +00:00
ast_log ( LOG_WARNING , " Announce file \" %s \" specified in Retrydial does not exist \n " , args . announce ) ;
2007-07-16 18:18:19 +00:00
}
2008-08-10 14:45:25 +00:00
if ( ! res & & sleepms ) {
2012-03-13 18:20:34 +00:00
if ( ! ast_test_flag ( ast_channel_flags ( chan ) , AST_FLAG_MOH ) )
2006-07-19 20:44:39 +00:00
ast_moh_start ( chan , NULL , NULL ) ;
2008-08-10 14:45:25 +00:00
res = ast_waitfordigit ( chan , sleepms ) ;
2005-01-18 03:12:53 +00:00
}
} else {
2007-07-23 19:51:41 +00:00
if ( ! ast_strlen_zero ( args . announce ) ) {
2012-01-24 20:12:09 +00:00
if ( ast_fileexists ( args . announce , NULL , ast_channel_language ( chan ) ) > 0 ) {
if ( ! ( res = ast_streamfile ( chan , args . announce , ast_channel_language ( chan ) ) ) )
2007-07-16 18:18:19 +00:00
res = ast_waitstream ( chan , " " ) ;
} else
2007-07-23 19:51:41 +00:00
ast_log ( LOG_WARNING , " Announce file \" %s \" specified in Retrydial does not exist \n " , args . announce ) ;
2007-07-16 18:18:19 +00:00
}
2008-08-10 14:45:25 +00:00
if ( sleepms ) {
2012-03-13 18:20:34 +00:00
if ( ! ast_test_flag ( ast_channel_flags ( chan ) , AST_FLAG_MOH ) )
2006-07-19 20:44:39 +00:00
ast_moh_start ( chan , NULL , NULL ) ;
2007-07-16 18:18:19 +00:00
if ( ! res )
2008-08-10 14:45:25 +00:00
res = ast_waitfordigit ( chan , sleepms ) ;
2005-01-20 22:59:50 +00:00
}
2005-01-18 03:12:53 +00:00
}
}
2008-04-28 16:37:45 +00:00
if ( res < 0 | | res = = AST_PBX_INCOMPLETE ) {
2005-01-18 03:12:53 +00:00
break ;
2008-04-28 16:37:45 +00:00
} else if ( res > 0 ) { /* Trying to send the call elsewhere (1 digit ext) */
2005-04-29 15:04:26 +00:00
if ( onedigit_goto ( chan , context , ( char ) res , 1 ) ) {
2005-01-18 03:12:53 +00:00
res = 0 ;
break ;
}
}
loops - - ;
}
2006-04-19 14:02:49 +00:00
if ( loops = = 0 )
res = 0 ;
2007-01-10 04:56:48 +00:00
else if ( res = = 1 )
res = 0 ;
2012-03-13 18:20:34 +00:00
if ( ast_test_flag ( ast_channel_flags ( chan ) , AST_FLAG_MOH ) )
2005-01-18 03:12:53 +00:00
ast_moh_stop ( chan ) ;
2007-01-10 04:56:48 +00:00
done :
2006-04-19 14:02:49 +00:00
return res ;
2005-01-18 03:12:53 +00:00
}
2006-08-21 02:11:39 +00:00
static int unload_module ( void )
1999-12-04 21:35:07 +00:00
{
2005-10-18 22:52:21 +00:00
int res ;
2007-06-20 17:35:08 +00:00
struct ast_context * con ;
2005-10-18 22:52:21 +00:00
res = ast_unregister_application ( app ) ;
res | = ast_unregister_application ( rapp ) ;
2008-02-09 11:27:10 +00:00
if ( ( con = ast_context_find ( " app_dial_gosub_virtual_context " ) ) ) {
2008-06-16 20:43:46 +00:00
ast_context_remove_extension2 ( con , " s " , 1 , NULL , 0 ) ;
closes issue #11285, where an unload of a module that creates a dialplan context, causes a crash when you do a 'dialplan show' of that context. This is because the registrar string is defined in the module, and the stale pointer is traversed. The reporter offered a patch that would always strdup the registrar string, which is practical, but I preferred to destroy the created contexts in each module where one is created. That seemed more symmetric. There were only 6 place in asterisk where this is done: chan_sip, chan_iax2, chan_skinny, res_features, app_dial, and app_queue. The two apps destroyed the context, but left the contexts. All is fixed now and unloads should be dialplan friendly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89513 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-11-21 23:54:12 +00:00
ast_context_destroy ( con , " app_dial " ) ; /* leave nothing behind */
}
2008-02-09 11:27:10 +00:00
2005-10-18 22:52:21 +00:00
return res ;
1999-12-04 21:35:07 +00:00
}
2006-08-21 02:11:39 +00:00
static int load_module ( void )
1999-12-04 21:35:07 +00:00
{
2000-03-26 01:59:06 +00:00
int res ;
2007-06-20 17:35:08 +00:00
struct ast_context * con ;
(closes issue #6002)
Reported by: rizzo
Tested by: murf
Proposal of the changes to be made, and then an announcement of how they were accomplished:
http://lists.digium.com/pipermail/asterisk-dev/2008-February/032065.html
and:
http://lists.digium.com/pipermail/asterisk-dev/2008-March/032124.html
Here is a recap, file by file, of what I have done:
pbx/pbx_config.c
pbx/pbx_ael.c
All funcs that were passed a ptr to the context list, now will ALSO be passed a hashtab ptr to the same set.
Why? because (for the time being), the dialplan is stored in both, to facilitate a quick, low-cost move to
hash-tables to speed up dialplan processing. If it was deemed necessary to pass the context LIST, well, it
is just as necessary to have the TABLE available. This is because the list/table in question might not be
the global one, but temporary ones we would use to stage the dialplan on, and then swap into the global
position when things are ready.
We now have one external function for apps to use, "ast_context_find_or_create()" instead of the pre-existing
"find" and "create", as all existing usages used both in tandem anyway.
pbx_config, and pbx_ael, will stage the reloaded dialplan into local lists and tables, and
then call merge_contexts_and_delete, which will merge (now) existing contexts and
priorities from other registrars into this local set by copying them. Then, merge_contexts_and_delete will
lock down the contexts, swap the lists and tables, and unlock (real quick), and then
destroy the old dialplan.
chan_sip.c
chan_iax.c
chan_skinny.c
All the channel drivers that would add regcontexts now use the ast_context_find_or_create now.
chan_sip also includes a small fix to get rid of warnings about removing priorities that never got entered.
apps/app_meetme.c
apps/app_dial.c
apps/app_queue.c
All the apps that added a context/exten/priority were also modified to use ast_context_find_or_create instead.
include/asterisk/pbx.h
ast_context_create() is removed. Find_or_create_ is the new method.
ast_context_find_or_create() interface gets the hashtab added.
ast_merge_contexts_and_delete() gets the local hashtab arg added.
ast_wrlock_contexts_version() is added so you can detect if someone else got a writelock between your readlocking and writelocking.
ast_hashtab_compare_contexts was made public for use in pbx_config/pbx_ael
ast_hashtab_hash_contexts was in like fashion make public.
include/asterisk/pval.h
ast_compile_ael2() interface changed to include the local hashtab table ptr.
main/features.c
For the sake of the parking context, we use ast_context_find_or_create().
main/pbx.c
I changed all the "tree" names to "table" instead. That's because the original
implementation was based on binary trees. (had a free library). Then I moved
to hashtabs. Now, the names move forward too.
refcount field added to contexts, so you can keep track of how many modules
wanted this context to exist.
Some log messages that are warnings were inflated from LOG_NOTICE to LOG_WARNING.
Added some calls to ast_verb(3,...) for debug messages
Lots of little mods to ast_context_remove_extension2, which is now excersized in ways
it was not previously; one definite bug fixed.
find_or_create was upgraded to handle both local lists/tables as well as the globals.
context_merge() was added to do the per-context merging of the old/present contexts/extens/prios into the new/proposed local list/tables
ast_merge_contexts_and_delete() was heavily modified.
ast_add_extension2() was also upgraded to handle changes.
the context_destroy() code was re-engineered to handle the new way of doing things,
by exten/prio instead of by context.
res/ael/pval.c
res/ael/ael.tab.c
res/ael/ael.tab.h
res/ael/ael.y
res/ael/ael_lex.c
res/ael/ael.flex
utils/ael_main.c
utils/extconf.c
utils/conf2ael.c
utils/Makefile
Had to change the interface to ast_compile_ael2(), to include the hashtab ptr.
This ended up involving several external apps. The main gotcha was I had to
include lock.h and hashtab.h in several places.
As a side note, I tested this stuff pretty thoroughly, I replicated the problems
originally reported by Luigi, and made triply sure that reloads worked, and everything
worked thru "stop gracefully". I found a and fixed a few bugs as I was merging into
trunk, that did not appear in my tests of bug6002.
How's this for verbose commit messages?
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@106757 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-03-07 18:57:57 +00:00
con = ast_context_find_or_create ( NULL , NULL , " app_dial_gosub_virtual_context " , " app_dial " ) ;
2007-06-20 17:35:08 +00:00
if ( ! con )
ast_log ( LOG_ERROR , " Dial virtual context 'app_dial_gosub_virtual_context' does not exist and unable to create \n " ) ;
else
2008-12-18 19:33:42 +00:00
ast_add_extension2 ( con , 1 , " s " , 1 , NULL , NULL , " NoOp " , ast_strdup ( " " ) , ast_free_ptr , " app_dial " ) ;
2005-10-18 22:52:21 +00:00
2008-11-01 21:10:07 +00:00
res = ast_register_application_xml ( app , dial_exec ) ;
res | = ast_register_application_xml ( rapp , retrydial_exec ) ;
2008-02-09 11:27:10 +00:00
2000-03-26 01:59:06 +00:00
return res ;
1999-12-04 21:35:07 +00:00
}
2006-08-21 02:11:39 +00:00
AST_MODULE_INFO_STANDARD ( ASTERISK_GPL_KEY , " Dialing Application " ) ;