aboutsummaryrefslogtreecommitdiffstats
path: root/channels/chan_iax2.c
AgeCommit message (Collapse)AuthorFilesLines
2008-09-02Make sure to use the correct length of the mohinterpret and mohsuggestseanbright1-2/+2
buffers when copying configuration values. (closes issue #13336) Reported by: decryptus_proformatique Patches: chan_iax2_mohinterpret_mohsuggest_general_settings.patch uploaded by decryptus (license 555) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140605 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-29After working on the ao2_containers branch, I noticedmmichelson1-3/+3
something a bit strange. In all cases where we provide a callback function to ao2_container_alloc, the callback function would only return 0 or CMP_MATCH. After inspecting the ao2_callback() code carefully, I found that if you're only looking for one specific item, then you should return CMP_MATCH | CMP_STOP. Otherwise, astobj2 will continue traversing the current bucket until the end searching for more matches. In cases like chan_iax2 where in 1.4, all the peers are shoved into a single bucket, this makes for potentially terrible performance since the entire bucket will be traversed even if the peer is one of the first ones come across in the bucket. All the changes I have made were for cases where the callback function defined was passed to ao2_container_alloc so that calls to ao2_find could find a unique instance of whatever object was being stored in the container. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140488 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-26Fix a race condition with the IAX scheduler thread. A lock and condition arerussell1-3/+2
used here to allow newly scheduled tasks to wake up the scheduler just in case the new task needs to run sooner than the current wakeup time when the thread is sleeping. However, there was a race condition such that a newly scheduled task would not properly wake up the scheduler or affect the wake up period. The order of execution would have been: 1) Scheduler thread determines wake up time of N ms. 2) Another thread schedules a task and signals the condition, with an execution time of < N ms. 3) Scheduler thread locks and goes to sleep for N ms. By moving the sleep time determination to inside the critical section, this possibility is avoided. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@140051 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-22Fix the build. Thanks, mvanbaak!mmichelson1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139466 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-22Prevent a deadlock in chan_iax2 resulting frommmichelson1-1/+4
incorrect locking order between iax2_pvt and ast_channel structures. AST-13 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@139456 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-05In a conversion to use ast_strlen_zero, the meaning of the flag IAX_HASCALLERIDtilghman1-19/+6
was perverted. This change reverts IAX2 to the original meaning, which was, that the callerid set on the client should be overridden on the server, even if that means the resulting callerid is blank. In other words, if you set "callerid=" in the IAX config, then the callerid should be overridden to blank, even if set on the client. Note that there's a distinction, even on realtime, between the field not existing (NULL in databases) and the field existing, but set to blank (override callerid to blank). git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@135747 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-22Merged revisions 132711 via svnmerge from tilghman1-2/+29
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r132711 | tilghman | 2008-07-22 16:14:10 -0500 (Tue, 22 Jul 2008) | 2 lines Fixes for AST-2008-010 and AST-2008-011 ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@132713 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-21Fix a bug in 1.4 branch with iax2 channels not being removed when a call was ↵bbryant1-4/+2
rejected (from the calling box, not the box that denied the registration). Related to revisions 132466 in trunk, and 132467 in 1.6.0. Earlier I had accidently tested 1.4 with a backport from those revisions, so I didn't see this problem (oops). git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@132506 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-18Spinlock within the destroy, to allow a scheduled job to continue, if it'stilghman1-2/+2
waiting on the mutex which the destroy thread has. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@132042 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-18Make the ast_assert call within ast_sched_del report something useful.tilghman1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@131970 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-16Fix a bug in iax2 registration that allowed peers to register with bbryant1-2/+2
case-insensitive names (user_cmp_cb and peer_cmp_cb are now both case-sensitive). (closes issue #13091) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@131491 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-16Apparently, in certain cases, a callno is already destroyed when ↵tilghman1-1/+1
iax2_destroy is called. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@131480 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-16Always ensure that the channel's tech_pvt reference is NULL after calling therussell1-0/+6
destroy callback. (closes issue #13060) Reported by: jpgrayson Patches: chan_iax2_tech_pvt_crash.patch uploaded by jpgrayson (license 492) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@131421 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-14Override the callerid in all cases when the callerid is set in the user, nottilghman1-13/+10
just when a remote callerid is set. Also, if not set in the user, allow the remote CallerID to pass through. (closes issue #12875) Reported by: dimas Patches: 20080714__bug12875.diff.txt uploaded by Corydon76 (license 14) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@130889 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-13Reverting 2 changesets, as it breaks incoming IAX2 callstilghman1-53/+44
(Related to issue #12963) Reported by: mvanbaak git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@130514 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-11a whole pile of Zaptel/DAHDI compatibility work, with lots more to come... ↵kpfleming1-3/+3
this tree is not yet ready for users to be easily upgrading or switching, but it needs to be :-) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@130298 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-11Ensure that a destination callno of 0 will not match for frames that do nottilghman1-6/+15
start a dialog (new, lagrq, and ping). (closes issue #12963) Reported by: russellb Patches: chan_iax2_dup_new_fix4.patch uploaded by jpgrayson (license 492) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@130169 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-10Correctly deal with duplicate NEW frames (due to retransmission). Also, fixuptilghman1-45/+45
the destination call number matching to be more strict and reliable. (closes issue #12963) Reported by: jpgrayson Patches: chan_iax2_dup_new_fix3.patch uploaded by jpgrayson (license 492) Tested by: jpgrayson, Corydon76 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@129803 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-08Timestamp decoding for video mini-frames is bogus, because the timestamp onlytilghman1-10/+16
includes 15 bits, unlike voice frames, which contain a 16-bit timestamp. (closes issue #13013) Reported by: jpgrayson Patches: chan_iax2_unwrap_ts.patch uploaded by jpgrayson (license 492) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@129047 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-07Fix handling of when a pvt disappears. Properly return the pvt lockedrussell1-2/+4
and don't hold the pvt lock while destroying the ast_channel. (closes issue #13014) Reported by: jpgrayson Patches: chan_iax2_ast_iax2_new2.patch uploaded by jpgrayson (license 492) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@128795 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-07Remove spurious trailing whitespace from log messages and fix a spelling errorseanbright1-3/+3
in a log message. (closes issue #13017) Reported by: jpgrayson Patches: chan_iax2_space_after_newline.patch uploaded by jpgrayson (license 492) chan_iax2_spelling.patch uploaded by jpgrayson (license 492) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@128737 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-07By using the iaxdynamicthreadcount to identify a thread, it was possiblemmichelson1-1/+2
for thread identifiers to be duplicated. By using a globally-unique monotonically- increasing integer, this is now avoided. (closes issue #13009) Reported by: jpgrayson Patches: chan_iax2_dyn_threadnum.patch uploaded by jpgrayson (license 492) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@128639 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-01Disable the old, slow search for matching callno in chan_iax2 (but allow it ↵tilghman1-0/+2
to be reenabled for debugging) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@127133 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-01Oopstilghman1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@127069 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-01Change around how we schedule pings and lagrqs, and fix a reason why thetilghman1-25/+23
jobs were not getting properly cancelled. (closes issue #12903) Reported by: stevedavies Patches: 20080620__bug12903__2.diff.txt uploaded by Corydon76 (license 14) Tested by: stevedavies git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@127068 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-01Suppress annoying warning by finding the remaining cases where the callno is ↵tilghman1-0/+9
not in the hash. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@126999 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-23emit a warning if the old IAX2 call searching code finds a call when the new ↵kpfleming1-1/+16
code did not... so that we can get rid of the old code in 2-3 months git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@124743 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-17Fix 3 more places where not locking the structure could cause the wrong lock ↵tilghman1-12/+15
to be unlocked. (Closes issue #12795) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@123391 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-16Port "hasvoicemail" change from SIP to other channel driverstilghman1-0/+4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@123113 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-12Adds DAHDI support alongside Zaptel. DAHDI usage favored, but all Zap stuff ↵jpeeler1-12/+20
should continue working. Release announcement to follow. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@122314 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-12Fix some race conditions that cause ast_assert() to report that chan_iax2 triedrussell1-0/+18
to remove an entry that wasn't in the scheduler git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@122259 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-03Fix another place where peer->callno could change at a very bad time, and alsorussell1-9/+11
fix a place where a peer was used after the reference was released. (inspired by rev 120001) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@120168 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-03Save the callno when we're poking, because our peer structure could changetilghman1-4/+7
during destruction (and thus we unlock the wrong callno, causing a cascade failure). (closes issue #12717) Reported by: gewfie Patches: 20080525__bug12717.diff.txt uploaded by Corydon76 (license 14) Tested by: gewfie git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@120001 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-02Revert a change made for issue #12479. This change caused a regression such ↵russell1-4/+1
that a dial string such as (IAX2/foo) did not automatically fall back to dialing the 's' extension anymore. (closes issue #12770) Reported by: dagmoller git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119838 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-02Even of the first PING or LAGRQ doesn't get sent because it comes up too soon,russell1-6/+4
make sure to reschedule so it gets sent later. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119687 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-02Change a debug message to an actual debug messagerussell1-1/+2
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119533 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-30Merged revisions 119237 via svnmerge from russell1-7/+37
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r119237 | russell | 2008-05-30 07:49:39 -0500 (Fri, 30 May 2008) | 7 lines - Instead of only enforcing destination call number checking on an ACK, check all full frames except for PING and LAGRQ, which may be sent by older versions too quickly to contain the destination call number. (As suggested by Tim Panton on the asterisk-dev list) - Merge changes from team/russell/iax2-frame-race, which prevents PING and LAGRQ from being sent before the destination call number is known. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119238 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29Merged revisions 119008 via svnmerge from russell1-8/+10
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r119008 | russell | 2008-05-29 13:45:21 -0500 (Thu, 29 May 2008) | 7 lines Merge changes from team/russell/iax2-another-fix-to-the-fix As described in the following post to the asterisk-dev mailing list, only enforce destination call numbers when processing an ACK. http://lists.digium.com/pipermail/asterisk-dev/2008-May/033217.html (closes issue #12631) ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@119009 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-29Add some debugging code that ensures that when we do deadlock avoidance, wetilghman1-24/+8
don't lose the information about how a lock was originally acquired. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118953 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-28merge revision 118702 from trunk to 1.4 -- Fixes a bug in chan_iax that uses ↵bbryant1-1/+5
send_command to poke a peer while a channel is unlocked in some cases, and because it can cause seemingly random failures could be related to some bugs in the tracker... git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@118716 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-19Avoid access of uninitialized memory. This caused a bunch of crashes for merussell1-1/+1
while doing load testing of development branch where I'm working on some performance improvements. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@116978 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-08Remove debug output.russell1-4/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115568 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-08Merged revisions 115564 via svnmerge from russell1-0/+18
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r115564 | russell | 2008-05-08 14:14:04 -0500 (Thu, 08 May 2008) | 25 lines Fix a race condition that bbryant just found while doing some IAX2 testing. He was running Asterisk trunk running IAX2 calls through a few Asterisk boxes, however, the audio was extremely choppy. We looked at a packet trace and saw a storm of INVAL and VNAK frames being sent from one box to another. It turned out that what had happened was that one box tried to send a CONTROL frame before the 3 way handshake had completed. So, that frame did not include the destination call number, because it didn't have it yet. Part of our recent work for security issues included an additional check to ensure that frames that are supposed to include the destination call number have the correct one. This caused the frame to be rejected with an INVAL. The frame would get retransmitted for forever, rejected every time ... This race condition exists in all versions that got the security changes, in theory. However, it is really only likely that this would cause a problem in Asterisk trunk. There was a control frame being sent (SRCUPDATE) at the _very_ beginning of the call, which does not exist in 1.2 or 1.4. However, I am fixing all versions that could potentially be affected by the introduced race condition. These changes are what bbryant and I came up with to fix the issue. Instead of simply dropping control frames that get sent before the handshake is complete, the code attempts to wait a little while, since in most cases, the handshake will complete very quickly. If it doesn't complete after yielding for a little while, then the frame gets dropped. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115565 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-07Merged revisions 115511 via svnmerge from russell1-3/+0
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r115511 | russell | 2008-05-07 11:22:49 -0500 (Wed, 07 May 2008) | 3 lines Remove remnants of dlinkedlists. I didn't actually use them in the final version of my IAX2 improvements. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@115512 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-30Merge changes from team/russell/iax2_find_callno and iax2_find_callno_1.4russell1-123/+248
These changes address a critical performance issue introduced in the latest release. The fix for the latest security issue included a change that made Asterisk randomly choose call numbers to make them more difficult to guess by attackers. However, due to some inefficient (this is by far, an understatement) code, when Asterisk chose high call numbers, chan_iax2 became unusable after just a small number of calls. On a small embedded platform, it would not be able to handle a single call. On my Intel Core 2 Duo @ 2.33 GHz, I couldn't run more than about 16 IAX2 channels. Ouch. These changes address some performance issues of the find_callno() function that have bothered me for a very long time. On every incoming media frame, it iterated through every possible call number trying to find a matching active call. This involved a mutex lock and unlock for each call number checked. So, if the random call number chosen was 20000, then every media frame would cause 20000 locks and unlocks. Previously, this problem was not as obvious since Asterisk always chose the lowest call number it could. A second container for IAX2 pvt structs has been added. It is an astobj2 hash table. When we know the remote side's call number, the pvt goes into the hash table with a hash value of the remote side's call number. Then, lookups for incoming media frames are a very fast hash lookup instead of an absolutely insane array traversal. In a quick test, I was able to get more than 3600% more IAX2 channels on my machine with these changes. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114891 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-30use the ARRAY_LEN macro for indexing through the iaxs/iaxsl arrays so that ↵kpfleming1-18/+27
the size of the arrays can be adjusted in one place, and change the size of the arrays from 32768 calls to 2048 calls when LOW_MEMORY is defined git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114880 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-25Use consistent logic for checking to see if a call number has been chosen yet.russell1-5/+5
Also, remove some redundant logic I recently added in a fix. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114673 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-24Fix a silly mistake in a change I made yesterday that caused chan_iax2 to blowrussell1-2/+2
up very quickly. (issue #12515) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114608 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-23Fix find_callno_locked() to actually return the callno locked in some more ↵russell1-2/+4
cases. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114587 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-22When we receive a full frame that is supposed to contain our call number,russell1-22/+38
ensure that it has the correct one. (closes issue #10078) (AST-2008-006) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114558 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 13:22:56 +0000