The check if an ISDN call is bridged before it could be placed on hold is
not necessary and is overly restrictive. The check was originally done to
prevent problems with call transfers in case a user tried to transfer a
call connected to an application to another call connected to an
application. The ISDN transfer code has not required this restriction for
quite some time because ECT could transfer any two active calls to each
other.
* Remove ISDN hold restriction for calls connected to applications.
* Made ast_waitfordigit_full() ignore AST_CONTROL_HOLD and
AST_CONTROL_UNHOLD instead of generating a warning message.
(closes issue ASTERISK-19388)
Reported by: Birger Harzenetter
Tested by: rmudgett
........
Merged revisions 357894 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 357895 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@357896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This takes two actions.
1. Move the reading of the alertpipe in __ast_read() to immediately before the
removal of frames from the readq. This means we won't do something silly like
read from the alertpipe, then ignore the fact that there's a frame to get from
the readq since channel's fdno is the AST_TIMING_FD.
2. When ast_settimeout() sets the rate to 0 and the timingfunc to NULL, if the
channel's fdno is the AST_TIMING_FD, then set the fdno to -1. This is because
if the rate is 0 and the timingfunc is NULL, it means that the channel's timing
fd is being invalidated, so any pending reads should not occur.
This may actually solve more issues than the referenced one below, but it's not
known at this time for sure.
(closes issue ASTERISK-19223)
reported by Frank-Michael Wittig
Review: https://reviewboard.asterisk.org/r/1779
........
Merged revisions 357761 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 357762 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@357775 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix opaquification conversion error.
(closes issue ASTERISK-19424)
Reported by: Jeremy Pepper
Patches:
asterisk-19424-initialize_priority_regression.diff (license #5026) patch uploaded by Michael L. Young
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@357101 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit adds GoSub alternatives to connected line, redirecting, and CCSS
macro hooks so that macro can finally be deprecated. This also adds
deprecation warnings for those features when used and in documentation.
Review: https://reviewboard.asterisk.org/r/1760/
(closes issue SWP-4256)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@357013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The accessors names for the "emulate_dtmf_digit" field on the ast_channel
are misleading. Change them to ast_channel_dtmf_digit_to_emulate*.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356183 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch removes some unnecessary locking of the channels container in
ast_hangup(). The reason this came up is that this lock can very quickly block
the entire system. If any of the channel cleanup code decides to block, it
causes a problem for the whole system. For example, when audiohooks get
destroyed, if that blocks for a while waiting on the mixmonitor thread to exit
because it's busy blocking on some I/O, it causes a problem for many other
threads in the meantime.
Review: https://reviewboard.asterisk.org/r/1712/
........
Merged revisions 354492 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 354493 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@354494 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When ast_channel name was opaquified, the channel search functions did not
get converted correctly. As a result ExtenSpy which uses a channel
iterator search by exten@context could never find anything.
* Updated the doxygen documentation for the search functions in channel.h.
Review: https://reviewboard.asterisk.org/r/1702/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@353647 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Continue channel opaque-ification by wrapping all of the stringfields.
Eventually, we will restrict what can actually set these variables, but
the purpose for now is to hide the implementation and keep people from
adding code that directly accesses the channel structure. Semantic
changes will follow afterward.
Review: https://reviewboard.asterisk.org/r/1661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Initially, support was left in for the old style of searching, even
though it wasn't actually used. In the case of name_len != 0, the
OBJ_KEY flag isn't passed because we aren't matching on a full key
and therefor can't use the hash function to optimize. The code left
in to support the old way of searching unfortunately treated a prefix
search like this as though an ast_channel struct was passed as an arg
and caused a crash.
This patch also adds needed parentheses around some matching conditions.
(closes issue ASTERISK-19182)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are many benefits to making the ast_channel an opaque handle, from
increasing maintainability to presenting ways to kill masquerades. This patch
kicks things off by taking things a field at a time, renaming the field to
'__do_not_use_${fieldname}' and then writing setters/getters and converting the
existing code to using them. When all fields are done, we can move ast_channel
to a C file from channel.h and lop off the '__do_not_use_'.
This patch sets up main/channel_interal_api.c to be the only file that actually
accesses the ast_channel's fields directly. The intent would be for any API
functions in channel.c to use the accessor functions. No more monkeying around
with channel internals. We should use our own APIs.
The interesting changes in this patch are the addition of
channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to
channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to
use accessor functions when ast_channel is really opaque), and some re-working
of the way channel iterators/callbacks are handled so as to avoid creating fake
ast_channels on the stack to pass in matching data by directly accessing fields
(since "name" is a stringfield and the fake channel doesn't init the
stringfields, you can't use the ast_channel_name_set() function). I went with
ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a
setter.
The majority of the grunt-work for this change was done by writing a semantic
patch using Coccinelle ( http://coccinelle.lip6.fr/ ).
Review: https://reviewboard.asterisk.org/r/1655/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 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.
........
Merged revisions 348464 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 348465 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@348466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
int blah = 1;
...
write(chan->alertpipe[1], &blah, new_frames * sizeof(blah)) !=
(new_frames * sizeof(blah)))
is only valid when new_frames == 1. Otherwise we start reading into adjacent
variables declared on the stack. The read end discards what is read, so the
values don't matter but it's not a good idea to read past where we want even
though new_frames is almost always 1 and should never be large. This patch is
basically taken out of kpfleming's eventfd branch, as he mentioned that he
remembered fixing it there when I talked to him about this issue.
Review: https://reviewboard.asterisk.org/r/1583/
........
Merged revisions 345163 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 345164 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@345165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r337431 | irroot | 2011-09-22 08:29:09 +0200 (Thu, 22 Sep 2011) | 25 lines
Merged revisions 337430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r337430 | irroot | 2011-09-22 08:18:33 +0200 (Thu, 22 Sep 2011) | 19 lines
Its possible to loose audio on ast_write when the channel is not transcoded correctly.
in the case of DAHDI the channel is hungup.
This patch tries to "fix" the problem and make the channel compatiable and warn the user of
this problem.
Please note there is a underlying problem with codec negotion this does not fix the problem
it does try to rectify it and prevent loss of service.
Review: https://reviewboard.asterisk.org/r/1442/
(closes issue ASTERISK-17541)
(closes issue ASTERISK-18063)
(issue ASTERISK-14384)
(issue ASTERISK-17502)
(issue ASTERISK-18325)
(issue ASTERISK-18422)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@337432 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r336307 | jrose | 2011-09-16 16:09:20 -0500 (Fri, 16 Sep 2011) | 20 lines
Merged revisions 336294 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r336294 | jrose | 2011-09-16 14:53:40 -0500 (Fri, 16 Sep 2011) | 13 lines
Fix bad RTP media bridges in directmedia calls on peers separated by multiple Asterisk nodes.
In a situation involving devices on separate Asterisk trunks, the remote RTP bridge would
break when starting a call with directmedia. This patch queues a new type of control frame
so that our RTP bridge loop can properly detect when these situations occur and check to see
if peers need to be updated in order to send their media to the proper location.
(Closes issue ASTERISK-18340)
Reported by: Thomas Arimont
(Closes issue ASTERISK-17725)
Reported by: kwk
Tested by: twilson, jrose
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@336311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r335078 | mjordan | 2011-09-09 11:27:01 -0500 (Fri, 09 Sep 2011) | 29 lines
Merged revisions 335064 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r335064 | mjordan | 2011-09-09 11:09:09 -0500 (Fri, 09 Sep 2011) | 23 lines
Updated SIP 484 handling; added Incomplete control frame
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/trunk@335079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r334010 | rmudgett | 2011-08-31 10:23:11 -0500 (Wed, 31 Aug 2011) | 50 lines
Merged revisions 334009 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r334009 | rmudgett | 2011-08-31 10:20:31 -0500 (Wed, 31 Aug 2011) | 43 lines
Call pickup race leaves orphaned channels or crashes.
Multiple users attempting to pickup a call that has been forked to
multiple extensions either crashes or fails a masquerade with a "bad
things may happen" message.
This is the scenario that is causing all the grief:
1) Pickup target is selected
2) target is marked as being picked up in ast_do_pickup()
3) target is unlocked by ast_do_pickup()
4) app dial or queue gets a chance to hang up losing calls and calls
ast_hangup() on target
5) SINCE A MASQUERADE HAS NOT BEEN SETUP YET BY ast_do_pickup() with
ast_channel_masquerade(), ast_hangup() completes successfully and the
channel is no longer in the channels container.
6) ast_do_pickup() then calls ast_channel_masquerade() to schedule the
masquerade on the dead channel.
7) ast_do_pickup() then calls ast_do_masquerade() on the dead channel
8) bad things happen while doing the masquerade and in the process
ast_do_masquerade() puts the dead channel back into the channels container
9) The "orphaned" channel is visible in the channels list if a crash does
not happen.
This patch does the following:
* Made ast_hangup() set AST_FLAG_ZOMBIE on a successfully hung-up channel
and not release the channel lock until that has happened.
* Made __ast_channel_masquerade() not setup a masquerade if either channel
has AST_FLAG_ZOMBIE set.
* Fix chan_agent misuse of AST_FLAG_ZOMBIE since it would no longer work.
(closes issue ASTERISK-18222)
Reported by: Alec Davis
Tested by: rmudgett, Alec Davis, irroot, Karsten Wemheuer
(closes issue ASTERISK-18273)
Reported by: Karsten Wemheuer
Tested by: rmudgett, Alec Davis, irroot, Karsten Wemheuer
Review: https://reviewboard.asterisk.org/r/1400/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@334011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
........
r331041 | twilson | 2011-08-08 16:12:51 -0500 (Mon, 08 Aug 2011) | 6 lines
Replace AMI Unlink events with Bridge events
A previous update converted some of the Link and Unlink events to
Bridge events, but a couple of Unlink events were missed. This patch
rectifies the situation.
(closes issues ASTERISK-17455)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@331042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds pass-through support for CELT. CELT
formats are defined in codecs.conf and can be configured
to any sample rate a CELT endpoint supports. This patch also
addresses a crash in channel.c resulting from a frame list being
freed incorrectly. This crash was discovered while testing a CELT
translator which had to split encoded audio into multiple frames.
The codec translator is not a part of this patch, but may be
contributed in the future.
Review: https://reviewboard.asterisk.org/r/1294/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@326855 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk now has protocol independent support for processing text messages
outside of a call. Messages are routed through the Asterisk dialplan.
SIP MESSAGE and XMPP are currently supported. There are options in sip.conf
and jabber.conf that enable these features.
There is a new application, MessageSend(). There are two new functions,
MESSAGE() and MESSAGE_DATA(). Documentation will be available on
the project wiki, wiki.asterisk.org.
Thanks to Terry Wilson for the assistance with development and to David Vossel
for helping with some additional testing.
Review: https://reviewboard.asterisk.org/r/1042/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@321546 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_string_field_build_va functions were written to take to separate
va_lists to work around FreeBSD 4 not having va_copy defined.
In the end, we don't support anything using gcc < 3 anyway because we use
va_copy all over the place anyway. This patch just simplifies things by
removing the second va_list function arguments in favor of va_copy.
Review: https://reviewboard.asterisk.org/r/1233/
--This line, and those below, will be ignored--
M include/asterisk/stringfields.h
M main/utils.c
M main/channel.c
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@320946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r320823 | rmudgett | 2011-05-25 12:06:38 -0500 (Wed, 25 May 2011) | 18 lines
The AMI Newstate event contains different information between v1.4 and v1.8.
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/trunk@320825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r320796 | rmudgett | 2011-05-25 11:23:11 -0500 (Wed, 25 May 2011) | 17 lines
Give zombies a safe channel driver to use.
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/trunk@320820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r320057 | rmudgett | 2011-05-20 11:43:02 -0500 (Fri, 20 May 2011) | 19 lines
Crash while transferring a call during DTMF feature timeout.
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/trunk@320058 65c4cc65-6c06-0410-ace0-fbb531ad65f3
