probably others, too. I don't really have time to work on it at the moment,
so I am just going to revert it for now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@59693 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r59341 | russell | 2007-03-29 11:55:39 -0500 (Thu, 29 Mar 2007) | 8 lines
When the IAX2 read callback gets called, return NULL instead of a "null frame".
This will cause Asterisk to hangup the call instead of keep trying whatever it
was doing. Under normal conditions, this function would *never* be called.
However, the author of this patch says an error will occur that will cause it
to get called every 100 thousand calls or so. When this does happen, it puts
the channel in a loop that eventually brings down the system. So, hangup up
the call is certainly a better alternative. (issue #8286, john)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@59343 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r58705 | russell | 2007-03-10 12:11:11 -0600 (Sat, 10 Mar 2007) | 6 lines
Fix a few more places in chan_iax2 where the ast_frame used for receiving a
frame was not properly initialized.
- Interpolating a frame when the jitterbuffer is in use
- decrypting a frame when IAX2 encryption is on
- frames in an IAX2 trunk
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@58706 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r58243 | russell | 2007-03-07 12:19:19 -0600 (Wed, 07 Mar 2007) | 17 lines
(This bug was reported to me by Kinsey Moore)
Merged revisions 58242 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r58242 | russell | 2007-03-07 12:17:07 -0600 (Wed, 07 Mar 2007) | 7 lines
Fix a problem where the Asterisk channel name could be that of the wrong IAX2
user for a call. This is because the first step of choosing this name is to
look for an IAX2 peer that happens to have the same IP/port number that this
call is coming from and assuming that is it. However, this is not always
correct. So, I have made it change this name after authentication happens
since at that point, we have an exact match.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@58244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is not a large amount of code here and the changes are not very invasive.
However, they should significantly improve performance of chan_iax2 under load.
IAX2 media frames only carry the *source* call number. So, when one arrives,
the correct session that it is a part of has to be matched on IP address, port
number, and call number, instead of just a call number. Had these frames
carried the *destination* call number, this would not be an issue, because that
would be a unique identifier that would make it easy to immediately identify
the correct session.
The way that chan_iax2 did this matching was extremely inefficient. It starts
at the first available call number and traverses each call number sequentially,
locking and unlocking a mutex for each one, to try to match against it. It
would do this regardless of whether the call number was in use or not. So,
for a call with a local call number of 25000, every single incoming media
frame would require a traversal that required 25000 mutex lock and unlock
operations. (Note that the max call number is about 32k).
I have introduced a hash table of active IAX2 calls to improve this lookup
process. The hash is done on the IP address, port number, and call number.
So, for the previous example, a few lock/unlock operations may be done versus
25000 for each frame.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@56447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r56407 | russell | 2007-02-23 14:20:00 -0600 (Fri, 23 Feb 2007) | 12 lines
Merged revisions 56406 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r56406 | russell | 2007-02-23 14:17:56 -0600 (Fri, 23 Feb 2007) | 4 lines
Don't destroy mutexes before unregistering all of the entry points from the core.
Also, fix a potential memory leak from not destroying the locks for all of the
possible call numbers (about 32k of them).
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@56408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r55397 | dbailey | 2007-02-19 08:52:59 -0600 (Mon, 19 Feb 2007) | 3 lines
Changed iax2 process thread to detached to correct memory leak due to left over thread context on thread exit.
Modified module unload process to avoid deadlocks on pthread cancels
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@55409 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r51311 | russell | 2007-01-19 11:49:38 -0600 (Fri, 19 Jan 2007) | 23 lines
Merge the changes from the /team/group/vldtmf_fixup branch.
The main bug being addressed here is a problem introduced when two SIP
channels using SIP INFO dtmf have their media directly bridged. So, when a
DTMF END frame comes into Asterisk from an incoming INFO message, Asterisk
would try to emulate a digit of some length by first sending a DTMF BEGIN
frame and sending a DTMF END later timed off of incoming audio. However,
since there was no audio coming in, the DTMF_END was never generated. This
caused DTMF based features to no longer work.
To fix this, the core now knows when a channel doesn't care about DTMF BEGIN
frames (such as a SIP channel sending INFO dtmf). If this is the case, then
Asterisk will not emulate a digit of some length, and will instead just pass
through the single DTMF END event.
Channel drivers also now get passed the length of the digit to their digit_end
callback. This improves SIP INFO support even further by enabling us to put
the real digit duration in the INFO message instead of a hard coded 250ms.
Also, for an incoming INFO message, the duration is read from the frame and
passed into the core instead of just getting ignored.
(issue #8597, maybe others...)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@51314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r49581 | kpfleming | 2007-01-04 17:50:15 -0600 (Thu, 04 Jan 2007) | 3 lines
create the IAX2 processing threads as background threads so they will use smaller stacks
when we create a dynamic thread, put it on the dynamic_list right away so we don't lose track of it
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@49584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r49259 | file | 2007-01-02 20:19:53 -0500 (Tue, 02 Jan 2007) | 2 lines
Check pvt structure presence before passing to send_command. This gets rid of the irritating message about a packet without pvt structure. This happens because the scheduled item is getting cancelled at almost the exact moment it is getting executed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@49260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r48564 | file | 2006-12-18 12:15:49 -0500 (Mon, 18 Dec 2006) | 2 lines
Put thread into proper list if we abort handling due to an error, and also hold the lock while putting it back into the proper idle list so we don't prematurely get a signal. (issue #8604 reported by arkadia)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@48565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
