This merges fixes for the following issues into the 1.8-digiumphones branch:
* ASTERISK-19355 - Call transfer with consultation frequently fails in cross-
linked Asterisk scenario (directmedia & sendrpid active)
* ASTERISK 19365 - Remote SIP Call legs are frequently not released in a
cross-linked Asterisk scenario (directmedia & sendrpid)
* ASTERISK-19183 - Sporadically missing connectedline event to caller channel
in directed pickup app
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8-digiumphones@362042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Custom parking extensions may not be coded such that the first and only
extension priority is the Park application. These custom parking
extensions will not be recognized as parking extensions. When a call is
blind transferred to an extension that is not recognized as a parking
extension, the normal blind transfer code causes the transferred channel
to start executing dialplan. Calls that get parked in this manner do not
know the original channel name that parked the call so the original parker
could never be called back if the parked call is not retrieved before the
timeout time. The parking space is also announced to the call being
parked as a side effect of not knowing the original parking channel.
* Fix handling of BLINDTRANSFER channel variable for call parking.
* Fixed SIP blind transfer using the wrong dialplan context variable to
check for the parking extension.
(closes issue ASTERISK-19322)
Reported by: aragon
Tested by: rmudgett, jparker
Review: https://reviewboard.asterisk.org/r/1730/
JIRA AST-766
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356521 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI UnParkedCall event was missing the Parkinglot and Uniqueid headers
that the AMI ParkedCall event contains.
(closes issue ASTERISK-19240)
Reported by: Michael Yara
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@354116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents the 'h' extension from being run on the transferee
channel when it is transferred via a native transfer mechanism such
as SIP REFER.
(closes ASTERISK-19173)
Reported by: Ross Beer
Tested by: Kristjan Vrban
Patches:
ASTERISK-19173 by Mark Michelson (license 5049)
Review: https://reviewboard.asterisk.org/r/1685
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@352199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Add locking when a channel inherits variables and datastores in
__ast_request_and_dial() and ast_call_forward(). Note: The involved
channels are not active so there was minimal potential for problems.
* Remove calls to ast_set_callerid() in __ast_request_and_dial() and
ast_call_forward() because the set information is for the wrong direction.
* Don't use C++ keywords for variable names in ast_call_forward().
* Run the redirecting interception macro if defined when forwarding a call
in ast_call_forward(). Note: Currently will never execute because the
only callers that supply a calling channel supply a hungup or zombie
channel.
* Make feature_request_and_dial() put the transferee into autoservice when
it calls ast_call_forward() in case a redirection interception macro is
run. Note: Currently will never happen because the caller channel (Party
B) is always hungup at this time.
* Make feature_request_and_dial() ignore the AST_CONTROL_PROCEEDING frame
to silence a log message.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@348464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_cdr_setcid() and ast_cdr_update() were shown in ASTERISK-18836 to
be called by different threads for the same channel. The channel driver
thread and the PBX thread running dialplan.
* Add lock protection around CDR API calls that access an ast_channel
pointer.
(closes issue ASTERISK-18836)
Reported by: gpluser
Review: https://reviewboard.asterisk.org/r/1628/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@348362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a bridge is broken, ast_bridge_call() might execute the h exten on
the calling channel. However, that channel may not have been the channel
that broke the bridge by hanging up. The channel executing the h exten
must be in a hung up state so things like AGI run in the correct mode.
* Make sure ast_bridge_call() marks the channel it is executing the h
exten on as hung up. (The AST_SOFTHANGUP_APPUNLOAD flag is used so as to
match the pbx.c main dialplan execution loop when it executes the h
exten.)
(closes issue ASTERISK-18811)
Reported by: David Hajek
Patches:
jira_asterisk_18811_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: David Hajek, rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@347595 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The fix for ASTERISK-12715 and ASTERISK-12685 added a check for the Park
application because the channel needed to be masqueraded to prevent a
crash. Since the Park application now always masquerades the channel into
the parking lot, the special check is no longer needed. The fix also
resulted in AGI exec Park attempting to double park the call and not honor
the Park application parameters.
* Removed no longer necessary call to ast_masq_park_call() by AGI exec for
the Park application. (Reverts -r146923)
* Fix Park application to only return 0 or -1. The AGI exec Park was
causing broken pipe error messages because the Park application returned 1
on successful park.
(closes issue ASTERISK-18737)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@341717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix potential deadlocks in SIP and IAX blind transfer to parking.
* Fix SIP, IAX, DAHDI analog, and MGCP channel drivers to respect the
parkext_exclusive option with transfers (Park(,,,,,exclusive_lot)
parameter). Created ast_park_call_exten() and ast_masq_park_call_exten()
to maintian API compatibility.
* Made masq_park_call() handle a failed ast_channel_masquerade() setup.
* Reduced excessive struct parkeduser.peername[] size.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@341254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Party A calls Party B.
Party A DTMF blind transfers Party B to Party C.
Party A channel continues to execute dialplan.
* Fixed the return value of builtin_blindtransfer() to return the correct
value after a transfer so the dialplan will not keep executing.
* Removed unnecessary connected line update that did not really do
anything.
* Made access to GOTO_ON_BLINDXFR thread safe in check_goto_on_transfer().
* Fixed leak of xferchan for failure cases in check_goto_on_transfer().
* Updated debug messages in builtin_blindtransfer() and
check_goto_on_transfer().
(closes issue ASTERISK-18275)
Reported by: rmudgett
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@340809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a SIP phone uses the dial application and receives a 484 Address
Incomplete response, if overlapped dialing is enabled for SIP, then
the 484 Address Incomplete is forwarded back to the SIP phone and the
HANGUPCAUSE channel variable is set to 28. Previously, the Incomplete
application dialplan logic was automatically triggered; now, explicit
dialplan usage of the application is required.
Additionally, this patch adds a new AST_CONTOL_FRAME type called
AST_CONTROL_INCOMPLETE. If a channel driver receives this control frame,
it is an indication that the dialplan expects more digits back from the
device. If the device supports overlap dialing it should attempt to
notify the device that the dialplan is waiting for more digits; otherwise,
it can handle the frame in a manner appropriate to the channel driver.
(closes issue ASTERISK-17288)
Reported by: Mikael Carlsson
Tested by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/1416/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@335064 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made AMI action Park not say anything to the parker channel (AMI header
Channel2) since the AMI action is a third party parking the call. (This
is a change in behavior that cannot be preserved without a lot of effort.)
* Made not play pbx-parkingfailed if the Park 's' option is used.
JIRA AST-660
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@334840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
JIRA ASTERISK-17183
Multi-parkinglot directs calls to wrong parkinglot.
JIRA ASTERISK-17870
Cannot retrieve parked calls.
JIRA ASTERISK-17430
ParkedCall() with no extension should pickup first available call and does not.
JIRA AST-576
Issues with parking lots
* Removed searching for parking lots by extension. Parking lots can only
be found by the parking lot name since parking lot access extensions and
spaces are not guaranteed to be unique.
* Added parking_lot_name option to the Park and ParkedCall applications.
Updated documentation for Park and ParkedCall applications.
* Add parkext_exclusive configuration option to make parking entry
extensions specify which parking lot they access.
(closes issue ASTERISK-17183)
Reported by: David Cabrejos
Tested by: rmudgett, David Cabrejos
(closes issue ASTERISK-17870)
Reported by: Remi Quezada
(closes issue ASTERISK-17430)
Reported by: Philippe Lindheimer
JIRA ASTERISK-17452
Parking_offset not used
JIRA AST-624
'next' setting for findslot does nothing
* Reimplemented since findslot feature option broken by -r114655.
(closes issue ASTERISK-17452)
Reported by: David Woolley
Tested by: rmudgett
JIRA ASTERISK-15792
Dialplan continues execution after transfer to park.
This happens for DTMF attended transfer, DTMF blind transfer, and DTMF
one-touch-parking if the party initiating these features also initiated
the call.
* Fixed the return code from the affected builtin features when parking a
call.
(closes issue ASTERISK-15792)
Reported by: Mat Murdock
Tested by: rmudgett, twilson
JIRA AST-607
The courtesytone is not playing to the expected call when picking up a
parked call.
This is mostly a documentation problem. However, the option is not reset
to the default when features.conf is reloaded.
* Updated features.conf.sample documentation for courtesytone and
parkedplay options.
* Reset the parkedplay option to default when features.conf is reloaded.
JIRA AST-615
AMI Park action followed by features reload results in orphaned channels
in parking lot.
* Reloading features.conf will not touch parking lots that have calls
still parked in them. Reload again at a later time.
Misc additional fixes:
* Added unit test for parking lot dialplan usage checking.
* Made update connected line when a parked call is retrieved from a
parking lot.
* Made retrieved parked call stop ringing or MOH depending upon how the
call was waiting in the parking lot.
* Made CLI "features show" indicate if the parking lot is enabled for use.
* Added PARKINGDYNEXTEN channel variable to allow dynamic parking lots to
specify the parking lot access extension.
* Made AMI ParkedCalls action ParkedCall events have a Parkinglot header.
* Made AMI ParkedCalls action ParkedCallsComplete event have a Total
header.
* Fixed potential deadlock from AMI Park action holding channel locks
while calling masq_park_call().
* Fixed several places where ast_strdupa() were used inside of loops.
(Mostly fixed by refactoring the loop body into its own function.)
* Fixed copy_parkinglot() copying too much from the source parking lot.
Extracted the parking lot configuration settings into struct
parkinglot_cfg.
* Refactored courtesytone playing code to put the channel not playing the
tone in autoservice.
* Fix when pbx-parkingfailed is played that the other channel is put in
autoservice if it exists.
* Fixed parkinglot reference leak in parked_call_exec() error paths.
* Fixed parkinglot_unref() use of parkinglot after it was unreffed.
* Made destroy the struct ast_parkinglot parkings lock when done.
* Refactored the features.conf parking lot configuration code to eliminate
redundancy.
* Fixed feature reload to better protect parking lots.
* Fixed parking lot container reference leak in handle_parkedcalls().
* Fixed the total count in handle_parkedcalls().
Review: https://reviewboard.asterisk.org/r/1358/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@332100 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Add some reentrancy protection in pbx.c when creating the contexts_table
hash table.
* Fix inverted test in chan_sip.c conditional code.
* Fix uninitialized variable and use of the wrong variable in chan_iax2.c.
* Fix test of return value in app_parkandannounce.c. Explicitly testing
for -1 is bad if the function does not actually return that value when it
fails.
* Fixup some comments and add some curly braces in features.c.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@331248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This appears to be a leftover from when ast_channel was converted to ao2
objects.
Simply removed the extraneous unlock.
(closes issue ASTERISK-17772)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@329144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r323733 | twilson | 2011-06-15 13:13:00 -0500 (Wed, 15 Jun 2011) | 16 lines
Merged revisions 323732 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r323732 | twilson | 2011-06-15 13:06:24 -0500 (Wed, 15 Jun 2011) | 9 lines
Fix DYNAMIC_FEATURES
DYNAMIC_FEATURES were broken by a recent DTMF change. This patch makes
sure that dynamic features are also checked when deciding whether or not
to pass DTMF through or store it for interpreting.
(closes issue ASTERISK-17914)
Reported by: vrban
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@323754 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Deadlock is possible in ast_do_pickup() when holding the target channel
lock and trying to get the chan channel lock. Also, holding the target
lock when calling ast_channel_masquerade() is not a good idea because that
routine does deadlock avoidance.
* Removed the need to hold the target lock after marking the target with a
datastore and getting the connected line data off of the target channel.
* Moved can_pickup() to ast_can_pickup() in features.c. Now all the call
pickup methods use the same basic call pickup availability check.
Review: https://reviewboard.asterisk.org/r/1234/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@322749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
move playout from sip_pickup_thread to bridge using BRIDGE_PLAY_SOUND method,
This stop the clash of 2 threads trying to write audio to same channel.
In addition fixes choppy audio beep in issue 19177.
(issue #18654)
(issue #19177)
Reported by: Docent
Patches:
review1232-1.88888888 alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/1232/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@321211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The addition of connected line support in v1.8 changes the behavior of the
channel caller ID somewhat. The channel caller ID value no longer time
shares with the connected line ID on outgoing call legs. The timing of
some AMI events/responses output the connected line ID as caller ID.
These party ID's are now separate.
* The ConnectedLineNum and ConnectedLineName headers were added to many
AMI events/responses if the CallerIDNum/CallerIDName headers were also
present.
(closes issue #18252)
Reported by: gje
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1227/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@320823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Recent crashes from zombie channels suggests that they need a safe home to
goto. When a masquerade happens, the physical part of the zombie channel
is hungup. The hangup normally sets the channel private pointer to NULL.
If someone then blindly does a callback to the channel driver, a crash is
likely because the private pointer is NULL.
The masquerade now sets the channel technology of zombie channels to the
kill channel driver.
Related to the following issues:
(issue #19116)
(issue #19310)
Review: https://reviewboard.asterisk.org/r/1224/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@320796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a call is being attended transferred during the time between
AST_FRAME_DTMF_BEGIN and AST_FRAME_DTMF_END, the transferred channel
becomes a zombie (so tech data is not available), making ast_dtmf_stream()
segfault when it tries to send the DTMF digit (at least with SIP
channels).
Patch based on feature-end-zombie.patch uploaded by Irontec (license 1256)
* Check for zombies when ast_channel_bridge() returns.
* Guarantee that the fo parameter value is initialized in
ast_channel_bridge() before any returns.
(closes issue #19116)
Reported by: Irontec
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@320057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The directed pickup applications can cause a crash if the pickup was
successful because the dialplan keeps executing.
This patch does the following:
* Completes the channel masquerade on a successful pickup before the
application returns. The channel is now guaranteed a zombie and must not
continue executing the dialplan.
* Changes the return value of the directed pickup applications to return
zero if the pickup failed and nonzero(-1) if the pickup succeeded.
* Made some code optimizations that no longer require re-checking the
pickup channel to see if it is still available to pickup.
(closes issue #19310)
Reported by: remiq
Patches:
issue19310_v1.8_v2.patch uploaded by rmudgett (license 664)
Tested by: alecdavis, remiq, rmudgett
Review: https://reviewboard.asterisk.org/r/1221/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@319997 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CDR's are being written immediately on caller hangup. The dialplan is not
able to modify it in the h exten. The h exten in the initial context is
not run before closing CDR's when the bridge is unlinked if a macro is
active and does not have an h exten.
* Make ast_bridge_call() check for an h exten in the current context and
if a macro is active then the initial context. The first h exten found is
then run before closing the CDR.
(closes issue #18212)
Reported by: leearcher
Patches:
issue18212_v1.8.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1206/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@318868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@318671 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a user hangs up a call, in certain circumstances, the hangup
extension can end up being executed twice:
1) If a call is bridged and the 'h' extension executes the Hangup
application, then the 'h' extension will be executed twice.
2) If a call is bridged within a macro (Dial or Queue), it has its own 'h'
extension, the main context also has an 'h' extension, and the macro 'h'
extension executes the Hangup application, then both 'h' extensions will
be executed.
* Revert originally commited fix for #16106 and just set
AST_FLAG_BRIDGE_HANGUP_RUN unconditionally in ast_bridge_call(). The
bridge code just executed an 'h' extension so the main PBX loop does not
need to execute one as well.
(issue #16106)
Reported by: ajohnson
(issue #16548)
Reported by: hajekd
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@318282 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r315643 | twilson | 2011-04-26 14:27:44 -0700 (Tue, 26 Apr 2011) | 25 lines
Merged revisions 315596 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r315596 | twilson | 2011-04-26 14:16:10 -0700 (Tue, 26 Apr 2011) | 18 lines
Allow transfer loops without allowing forwarding loops
We try to avoid the situation where two phones may be forwarded to each other
causing an infinite loop by storing each dialed interface in a channel
datastore and checking the list before dialing out. This works, but currently
breaks situations like A calls B, A transfers B to C, B transfers C to A, and A
transfers C to B. Since human interaction is happening here and not an
automated forwarding loop, it should be allowed.
This patch removes the dialed_interfaces datastore when a call is bridged (a
suggestion from the brilliant mmichelson). If a call is being bridged, it
should be safe to assume that we aren't stuck in a loop.
Since we are now handling this is the bridge code, the previous attempts at
handling it in app_dial and app_queue are removed.
Review: https://reviewboard.asterisk.org/r/1195/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@315644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r310889 | twilson | 2011-03-16 12:03:27 -0500 (Wed, 16 Mar 2011) | 36 lines
Merged revisions 310888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r310888 | twilson | 2011-03-16 11:58:42 -0500 (Wed, 16 Mar 2011) | 29 lines
Don't delay DTMF in core bridge while listening for DTMF features
This patch is mostly the work of Olle Johansson. I did some cleanup and
added the silence generating code if transmit_silence is set.
When a channel listens for DTMF in the core bridge, the outbound DTMF is not
sent until we have received DTMF_END. For a long DTMF, this is a disaster. We
send 4 seconds of DTMF to Asterisk, which sends no audio for those 4 seconds.
Some products see this delay and the time skew on RTP packets that results and
start ignoring the audio that is sent afterward.
With this change, the DTMF_BEGIN frame is inspected and checked. If it matches
a feature code, we wait for DTMF_END and activate the feature as before. If
transmit_silence=yes in asterisk.conf, silence is sent if we paritally match a
multi-digit feature. If it doesn't match a feature, the frame is forwarded
along with the DTMF_END without delay. By doing it this way, DTMF is not delayed.
(closes issue #15642)
Reported by: jasonshugart
Patches:
issue_15652_dtmf_ast-1.4.patch.txt uploaded by twilson (license 396)
Tested by: globalnetinc, jde
(closes issue #16625)
Reported by: sharvanek
Review: https://reviewboard.asterisk.org/r/1092/
Review: https://reviewboard.asterisk.org/r/1125/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@310902 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r307227 | jpeeler | 2011-02-09 13:52:12 -0600 (Wed, 09 Feb 2011) | 11 lines
Make sure to set parking dial context for non-default parking lots.
Since parking_con_dial isn't settable, set all parking lots to "park-dial".
(closes issue #17946)
Reported by: bluecrow76
Patches:
asterisk-1.8.0-beta4-multipark-fixes-2010SEP02.diff uploaded by bluecrow76 (license 270)
modified by me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@307228 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r306673 | twilson | 2011-02-07 14:40:20 -0800 (Mon, 07 Feb 2011) | 17 lines
Merged revisions 306672 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r306672 | twilson | 2011-02-07 14:35:20 -0800 (Mon, 07 Feb 2011) | 10 lines
Don't try to pickup a call in the middle of a masquerade
If A calls B which doesn't answer and C & D both try to do a call pickup, it is
possible for ast_pickup_call to answer the call, then fail to masquerade one of
the calls because the other one is already in the process of masquerading. This
patch checks to see if the channel is in the process of masquerading before
call before selecting it for a pickup.
Review: https://reviewboard.asterisk.org/r/1094/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@306674 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r306123 | jpeeler | 2011-02-03 14:49:48 -0600 (Thu, 03 Feb 2011) | 10 lines
Set exception on channel in parking thread when POLLPRI event detected.
This is done just to make the code be equivalent to the old select code. As
noted in 303106 the same issue was already fixed in this branch, but the
exception was not set on the channel in the case of POLLPRI. The reason that
this did not cause a problem here is because in 122923 the check in __ast_read
to check the exception flag was removed.
(related to #18637)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@306124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r304006 | rmudgett | 2011-01-25 17:25:32 -0600 (Tue, 25 Jan 2011) | 15 lines
Merged revisions 304005 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r304005 | rmudgett | 2011-01-25 17:21:09 -0600 (Tue, 25 Jan 2011) | 8 lines
DTMF attended transfers sometimes fail for no apparent reason.
The loop in feature_request_and_dial() can exit when Party C has answered
without processing an AST_CONTROL_ANSWER. Also sometimes an
AST_CONTROL_ANSWER never happens even though Party C has answered.
Don't hangup Party C if he is up or we receive an AST_CONTROL_ANSWER.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@304007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r303548 | russell | 2011-01-24 14:49:53 -0600 (Mon, 24 Jan 2011) | 38 lines
Merged revisions 303546 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r303546 | russell | 2011-01-24 14:32:21 -0600 (Mon, 24 Jan 2011) | 31 lines
Fix channel redirect out of MeetMe() and other issues with channel softhangup.
Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped
working properly. This issue includes a patch that resolves the issue by
removing a call to ast_check_hangup() from app_meetme.c. I left that in my
patch, as it doesn't need to be there. However, the rest of the patch fixes
this problem with or without the change to app_meetme.
The key difference between what happens before and after this patch is the
effect of the END_OF_Q control frame. After END_OF_Q is hit in ast_read(),
ast_read() will return NULL. With the ast_check_hangup() removed, app_meetme
sees this which causes it to exit as intended. Checking ast_check_hangup()
caused app_meetme to exit earlier in the process, and the target of the
redirect saw the condition where ast_read() returned NULL.
Removing ast_check_hangup() works around the issue in app_meetme, but doesn't
solve the issue if another application did the same thing. There are also
other edge cases where if an application finishes at the same time that a
redirect happens, the target of the redirect will think that the channel hung
up. So, I made some changes in pbx.c to resolve it at a deeper level. There
are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to
abort the hangup process. My patch extends this to remove the END_OF_Q frame
from the channel's read queue, making the "abort hangup" more complete. This
same technique was used in every place where a softhangup flag was cleared.
(closes issue #18585)
Reported by: oej
Tested by: oej, wedhorn, russell
Review: https://reviewboard.asterisk.org/r/1082/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@303549 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r303106 | sruffell | 2011-01-20 13:56:34 -0600 (Thu, 20 Jan 2011) | 15 lines
main/features: Use POLLPRI when waiting for events on parked channels.
This change resolves a regression in the 1.6.2 when converting from
select to poll. The DAHDI timers use POLLPRI to indicate that the timer
fired, but features was not waiting for that flag. The result was no
audio for MOH when a call was parked and res_timing_dahdi was in use.
This patch is slightly modified from the one on the mantis issue. It does
not set an exception on the channel if the POLLPRI flag is set.
(closes issue #18262)
Reported by: francesco_r
Patches:
patch_park_moh-trunk-2.txt uploaded by cjacobsen (license 1029)
Tested by: francesco_r, rfrantik, one47
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@303107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r302693 | rmudgett | 2011-01-19 15:25:41 -0600 (Wed, 19 Jan 2011) | 22 lines
Merged revisions 302671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r302671 | rmudgett | 2011-01-19 15:21:56 -0600 (Wed, 19 Jan 2011) | 15 lines
DTMF transfer plays the wrong sounds for wrong number or other call failure.
* Set the default for features.conf.sample xferfailsound option to "beeperr"
as documented instead of "pbx-invalid" and corrected the use of it in DTMF
blind transfer (#1).
* Improved DTMF blind transfer handling of wrong numbers.
Most of the concerns in this issue were taken care of by the patch for
issue 17999: Issues with DTMF triggered attended transfers.
(closes issue #18379)
Reported by: gincantalupo
Tested by: rmudgett
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@302713 65c4cc65-6c06-0410-ace0-fbb531ad65f3
