https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r67064 | file | 2007-06-04 13:41:59 -0400 (Mon, 04 Jun 2007) | 2 lines
Returning a value that indicates the parking of a call was a success when it really wasn't (because the parking slot selected was in use) is the wrong thing to do. (issue #9723 reported by mdu113)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@67065 65c4cc65-6c06-0410-ace0-fbb531ad65f3
features.conf. This allows you to create a feature one time, and then map it
into groups for various different key mappings for the same feature, as well
as easy access control to groups of features.
(patch from bbryant)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@66774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
add some new options to control what happens when you hangup on an attended
transfer before the target extension answers the transferred channel. You
can now have it send the transferee back to the transferer.
(issue #8413, patch from sergee with very minor modifications by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@62593 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r62548 | russell | 2007-05-01 16:57:10 -0500 (Tue, 01 May 2007) | 12 lines
Merged revisions 62547 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r62547 | russell | 2007-05-01 16:55:19 -0500 (Tue, 01 May 2007) | 4 lines
Remove an unnecessary check that makes it so if you hang up after doing an
attended transfer before the target extension answers the channel, the transfer
is not successful. (issue #9338, patch by svanlund)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@62549 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a "Bridge" Manager action, as well as a "Bridge" dialplan
application. The manager action will allow you to steal two active channels
in the system and bridge them together. Then, the one that did not hang up
will continue in the dialplan. Using the application will bridge the calling
channel to an arbitrary channel in the system. Whichever channel does not
hang up here will continue in the dialplan, as well.
This patch has been touched by a bunch of people over the course of a couple
years. Please forgive me if I have missed your name in the history of things.
The most recent patch came from issue #5841, but there is also a reference to
an earlier version of this patch from issue #4297. The people involved in writing
and/or reviewing the code include at least: twisted, mflorrel, heath1444, davetroy,
tim_ringenbach, moy, tmancill, serge-v, and me. There are also positive test
reports from many people.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@61281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pretty cool things.
First, you can get the device state of anything in the dialplan:
NoOp(SIP/mypeer has state ${DEVSTATE(SIP/mypeer)})
NoOp(The conference room 1234 has state ${DEVSTATE(MeetMe:1234)})
Most importantly, this allows you to create custom device states so you can
control phone lamps directly from the dialplan.
Set(DEVSTATE(Custom:mycustomlamp)=BUSY)
...
exten => mycustomlamp,hint,Custom:mycustomlamp
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@54261 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r49742 | qwell | 2007-01-05 18:24:38 -0600 (Fri, 05 Jan 2007) | 7 lines
Save 1 whopping byte of allocated memory!
This looks like it may have been a chicken/egg scenario..
You had to call a cleanup func, because everything was allocated.
Then since you had to call a cleanup func, you were forced to allocate - ie; strdup("").
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@49743 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r43779 | russell | 2006-09-27 12:55:49 -0400 (Wed, 27 Sep 2006) | 50 lines
Merged revisions 43778 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r43778 | russell | 2006-09-27 12:54:30 -0400 (Wed, 27 Sep 2006) | 42 lines
Fix a problem that occurred if a user entered a digit that matched a bridge
feature that was configured using multiple digits, and the digit that was
pressed timed out in the feature digit timeout period. For example, if blind
transfer is configured as '##', and a user presses just '#'. In this situation,
the call would lock up and no longer pass any frames.
(issue #7977 reported by festr, and issue #7982 reported by michaels and
valuable input provided by mneuhauser and kuj. Fixed by me, with testing help
and peer review from Joshua Colp).
There are a couple of issues involved in this fix:
1) When ast_generic_bridge determines that there has been a timeout, it returned
AST_BRIDGE_RETRY. Then, when ast_channel_bridge gets this result, it calls
ast_generic_bridge over again with the same timestamp for the next event.
This results in an endless loop of nothing until the call is terminated.
This is resolved by simply changing ast_generic_bridge to return
AST_BRIDGE_COMPLETE when it sees a timeout.
2) I also changed ast_channel_bridge such that if in the process of calculating
the time until the next event, it knows a timeout has already occured, to
immediately return AST_BRIDGE_COMPLETE instead of attempting to bridge the
channels anyway.
3) In the process of testing the previous two changes, I ran into a problem in
res_features where ast_channel_bridge would return because it determined
that there was a timeout. However, ast_bridge_call in res_features would
then determine by its own calculation that there was still 1 ms before the
timeout really occurs. It would then proceed, and since the bridge broke
out and did *not* return a frame, it interpreted this as the call was over
and hung up the channels.
The reason for this was because ast_bridge_call in res_features and
ast_channel_bridge in channel.c were using different times for their
calculations. channel.c uses the start_time on the bridge config, which
is the time that the feature digit was recieved. However, res_features
had another time, 'start', which was set right before calling
ast_channel_bridge. 'start' will always be slightly after start_time in the
bridge config, and sometimes enough to round up to one ms.
This is fixed by making ast_bridge_call use the same time as
ast_channel_bridge for the timeout calculation.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@43780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tilghman Lesher
Steve Murphy
Joshua Colp
Russell Bryant
Olle Johansson
Jason Parker
Kevin P. Fleming
Luigi Rizzo
Matt O'Gorman