aboutsummaryrefslogtreecommitdiffstats
path: root/channels/chan_iax2.c
AgeCommit message (Collapse)AuthorFilesLines
2010-01-07fixes crash in "scheduled_destroy" in chan_iaxdvossel1-1/+1
A signed short was used to represent a callnumber. This is makes it possible to attempt to access the iaxs array with a negative index. (closes issue #16565) Reported by: jensvb git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@238411 f38db490-d61c-443f-a65b-d21fe96a405b
2009-11-15Correct mistaken option name in error message.kpfleming1-1/+1
The configuration option for allowing hosts to make non-token-based calls is 'calltokenoptional', not 'calltokenignore'. (reported on asterisk-users) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@230246 f38db490-d61c-443f-a65b-d21fe96a405b
2009-11-10don't crash on log message in solarisdvossel1-1/+1
AST-2009-006 (closes issue #16206) Reported by: bklang Tested by: bklang git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@229167 f38db490-d61c-443f-a65b-d21fe96a405b
2009-11-02fixes crash on iterator_destroy on uninitialized iteratordvossel1-1/+0
(closes issue #16162) Reported by: krn git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@226736 f38db490-d61c-443f-a65b-d21fe96a405b
2009-11-02changes calltoken debug messages from LOG_NOTICE to LOG_DEBUG like they are ↵dvossel1-6/+6
supposed to be (closes issue #16144) Reported by: aragon git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@226688 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-21IAX2: VNAK loop caused by signaling frames with no destination call numberdvossel1-10/+77
It is possible for the PBX thread to queue up signaling frames before a destination call number is received. This can result in signaling frames being sent out with no destination call number. Since recent versions of Asterisk require accurate destination callnumbers for all Full Frames, this can cause a VNAK loop to occur. To resolve this no signaling frames are sent until a destination callnumber is received, and destination call numbers are now only required for iax_pvt matching when the frame is an ACK. Review: https://reviewboard.asterisk.org/r/413/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@225243 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-21IAX/SIP shrinkcallerid optiondvossel1-2/+14
The shrinking of caller id removes '(', ' ', ')', non-trailing '.', and '-' from the string. This means values such as 555.5555 and test-test result in 555555 and testtest. There are instances, such as Skype integration, where a specific value is passed via caller id that must be preserved unmodified. This patch makes the shrinking of caller id optional in chan_sip and chan_iax in order to support such cases. By default this option is on to preserve previous expected behavior. (closes issue #15940) Reported by: dimas Patches: v2-15940.patch uploaded by dimas (license 88) 15940_shrinkcallerid_trunk.c uploaded by dvossel (license 671) Tested by: dvossel Review: https://reviewboard.asterisk.org/r/408/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@225032 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-06Fix ao2_iterator API to hold references to containers being iterated.kpfleming1-0/+12
See Mantis issue for details of what prompted this change. Additional notes: This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK has become an enum instead of a macro, with a name that fits our naming policy; also, it is now necessary to call ao2_iterator_destroy() on any iterator that has been created. Currently this only releases the reference to the container being iterated, but in the future this could also release other resources used by the iterator, if the iterator implementation changes to use additional resources. (closes issue #15987) Reported by: kpfleming Review: https://reviewboard.asterisk.org/r/383/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@222152 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-02Removes unnecessary unlock, clarifies a memcpy.dvossel1-2/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@222026 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-21Reverting merge 219520. This change was not necessary.dvossel1-0/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219720 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-19Make sure the iax_pvt exists before dereferencing it.russell1-1/+1
This fixes the latest crash posted on issue 15609. (issue #15609) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219586 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-18iax2 frame double freedvossel1-1/+0
The iax frame's retrans sched id was written over right before iax2_frame_free was called. In iax2_frame_free that retrans id is used to delete the sched item. By writing over the retrans field before the sched item could be deleted, it was possible for a retransmit to occur on a freed frame. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219519 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-10Backport realtime fix to 1.4tilghman1-3/+8
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@217917 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-10IAX2 encryption regressiondvossel1-5/+27
The IAX2 Call Token security patch inadvertently broke the use of encryption due to the reorganization of code in the socket_process() function. When encryption is used, an incoming full frame must first be decrypted before the information elements can be parsed. The security release mistakenly moved IE parsing before decryption in order to process the new Call Token IE. To resolve this, decryption of full frames is once again done before looking into the frame. This involves searching for an existing callno, checking the pvt to see if encryption is turned on, and decrypting the packet before the internal fields of the full frame are accessed. associated with AST-2009-006 (closes issue #15834) Reported by: karesmakro Patches: iax2_encryption_fix_1.4.diff uploaded by dvossel (license 671) Tested by: dvossel, karesmakro Review: https://reviewboard.asterisk.org/r/355/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@217806 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-03Merge code associated with AST-2009-006dvossel1-122/+1214
(closes issue #12912) Reported by: rathaus Tested by: tilghman, russell, dvossel, dbrooks git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216000 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-10AST-2009-005tilghman1-4/+4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@211528 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-27Fix logic errors from 208746jpeeler1-1/+1
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208923 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-25Fix compiling under dev-mode with gcc 4.4.0.jpeeler1-1/+1
Mostly trivial changes, but I did not know of any other way to fix the "dereferencing type-punned pointer will break strict-aliasing rules" error without creating a tmp variable in chan_skinny. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@208746 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-14Merged revisions 206384 via svnmerge from russell1-3/+5
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r206384 | russell | 2009-07-14 09:45:47 -0500 (Tue, 14 Jul 2009) | 6 lines Ensure apathetic replies are sent out on the proper socket. chan_iax2 supports multiple address bindings. The send_apathetic_reply() function did not attempt to send its response on the same socket that the incoming message came in on. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206385 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-08Fixes 8khz assumptionsdvossel1-7/+8
Many calculations assume 8khz is the codec rate. This is not always the case. This patch only addresses chan_iax.c and res_rtp_asterisk.c, but I am sure there are other areas that make this assumption as well. Review: https://reviewboard.asterisk.org/r/306/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@205471 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-29segfault after SPINLOCK schedule deletedvossel1-4/+14
Using the SPINLOCK schedule delete macro can result in the iax_pvt lock being given up. This makes it possible for the iax_pvt to dissappear when we thought we held the mutex the entire time. To resolve this, the iax_pvt's ref count is incremented. (closes issue #15377) Reported by: aragon Patches: iax_spin_issue_1.4.diff uploaded by dvossel (license 671) Tested by: aragon, dvossel git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@204067 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-19timestamp was being converted to host order as a short rather than a longdvossel1-1/+1
(closes issue #15361) Reported by: ffloimair Patches: ts_issue.diff uploaded by dvossel (license 671) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@201993 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-04Additional updates to AST-2009-001dvossel1-1/+17
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@199138 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-28'iax show peer blah' now outputs whether or not peer 'blah' is in trunk mode ↵dvossel1-0/+1
or not. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@197620 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-21Sign problem calculating timestamp for iax frame leads to no audio on the ↵dvossel1-0/+3
receiving peer. There are rare cases in which a frame's delivery timestamp is slightly less than the iax2_pvt's offset. This causes the pvt's timestamp to be a small negative number, but since the timestamp value is unsigned it looks like a huge positive number. This patch checks for this negative case and sets the ms to zero. A similar check is already done right below this one in the 'else' statement. (closes issue #15032) Reported by: guillecabeza Patches: chan_iax2.c.patch_timestamp uploaded by guillecabeza (license 380) Tested by: guillecabeza (closes issue #14216) Reported by: Andrey Sofronov git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@195991 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-15IAX2 REGAUTH loopdvossel1-22/+37
IAX was not sending REGREJ to terminate invalid registrations. Instead it sent another REGAUTH if the authentication challenge failed. This caused a loop of REGREQ and REGAUTH frames. (Related to Security fix AST-2009-001) (closes issue #14867) Reported by: aragon Tested by: dvossel (closes issue #14717) Reported by: mobeck Patches: regauth_loop_update_patch.diff uploaded by dvossel (license 671) Tested by: dvossel git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@194873 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-15Update to previous IAX2 "Ghost" Channels patch.dvossel1-11/+14
Fixed some comments made on reviewboard for the previous patch. (issue #14207) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@194685 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-14IAX2 "Ghost" Channelsdvossel1-21/+56
There is a bug tracker issue where people are reporting "Ghost" channels in their 'iax2 show channels' output. The confusion is caused by channels being listed as "(NONE)" with format "unknown". These are not channels of coarse. They are usually just pending registration or poke requests, but it is confusing output. To help make sense of this I have added two columns to 'iax2 show channels'. One shows the first message which started the transaction, and the second shows the last message sent by either side of the call. This helps diagnose why the entry exists and why it may not go away. (closes issue #14207) Reported by: clive18 Review: https://reviewboard.asterisk.org/r/246/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@194557 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-04global mohinterpret setting is ignoreddvossel1-0/+5
mohinterpret and mohsuggest global variables were not copied over during build_users and build_peers. (closes issue #14728) Reported by: dimas Patches: v1-14728.patch uploaded by dimas (license 88) Tested by: dimas, dvossel git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@192213 f38db490-d61c-443f-a65b-d21fe96a405b
2009-04-20Clean up problem with manager implementation of mmap where it was not ↵dbailey1-1/+1
testing against MAP_FAILED response. Got rid of shadowed variable used in processign the mmap results. Change test of mmap results to compare against MAP_FAILED git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@189391 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-20Fix a crash in IAX2 registration handling found during load testing with ↵russell1-5/+10
dvossel. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@183559 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-16Randomize IAX2 encryption paddingdvossel1-2/+18
The 16-32 byte random padding at the beginning of an encrypted IAX2 frame turns out to not be all that random at all. This patch calls ast_random to fill the padding buffer with random data. The padding is randomized at the beginning of every encrypted call and for every encrypted retransmit frame. Review: http://reviewboard.digium.com/r/193/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@182281 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-11encrypted IAX2 during packet loss causes decryption to fail on retransmitted ↵dvossel1-13/+45
frames If an iax channel is encrypted, and a retransmit frame is sent, that packet's iseqno is updated while it is encrypted. This causes the entire frame to be corrupted. When the corrupted frame is sent, the other side decrypts it and sends a VNAK back because the decrypted frame doesn't make any sense. When we get the VNAK, we look through the sent queue and send the same corrupted frame causing a loop. To fix this, encrypted frames requiring retransmission are decrypted, updated, then re-encrypted. Since key-rotation may change the key held by the pvt struct, the keys used for encryption/decryption are held within the iax_frame to guarantee they remain correct. (closes issue #14607) Reported by: stevenla Tested by: dvossel Review: http://reviewboard.digium.com/r/192/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@181340 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-11Fix malloc debug macros to work properly with h323.jpeeler1-1/+1
The main problem here was that cstdlib was undefining free thereby causing the proper debug macros to not be used. ast_h323.cxx has been changed to call ast_free instead to avoid the issue. Because using the ast prefix calls are a better choice, ast_free_ptr is the new wrapper for free to pass to functions. Also, a little bit of clean up was done to avoid the debug macros intentionally being redefined. (closes issue #13593) Reported by: pj git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@181133 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-26IAX2 prune realtime fixdvossel1-14/+44
Now prune_users() and prune_peers() are called instead of reload_config() to prune all users/peers that are realtime. These functions remove all users/peers with the rtfriend and delme flags set. iax2_prune_realtime() also lacked the code to properly delete a single friend. For example. if iax2 prune realtime <friend> was called, only the peer instance would be removed. The user would still remain. (closes issue #14479) Reported by: mousepad99 Review: http://reviewboard.digium.com/r/176/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178838 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-20Fixes issue with undefined audio codecs in chan_iax2dvossel1-1/+1
During iax2 call negotiation, supported codecs are passed in an Information Element containing a 2 byte field where each bit correlates to a specific codec. In 1.4 only audio codec bits 0-12 are defined, leaving bits 13-15 undefined. By default all bits are enabled unless specified otherwise. Since its a 2 byte field and 13-15 are not defined, these bits are never turned off. In trunk, bits 13-15 are defined, which means 1.4 is advertising support for codecs it does not have when talking to trunk. I fixed this by adding #define for undefined audio codec bits. These bits are then removed from iax2's full bandwidth capabilities. (closes issue #14283) Reported by: jcovert git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@177696 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-16Fixes issue with AST_CONTROL_SRCUPDATE not being relayed correctly during ↵dvossel1-4/+5
bridging This should have been committed with rev176247, but I missed it. srcupdate frames no longer break out of the native bridge, but are not being sent to the other call leg either. This fixs that. issue #13749 git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176354 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-16Fixes issue with AST_CONTROL_SRCUPDATE breaking out of native bridgedvossel1-1/+1
In iax2, when a AST_CONTROL_SRCUPDATE is received it breaks from the native bridge, but since there is no code path to handle srcupdate it just goes to be beginning of the loop. This was causing packet storms of srcupdate frames between servers. Now srcupdate frames do not break the native bridge for processing. (closes issue #13749) Reported by: adiemus git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@176247 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-03Fixes issue with IAX2 transfer not handing off calls. dvossel1-26/+93
Fixes issue with IAX2 transfers not taking place. As it was, a call that was being transfered would never be handed off correctly to the call ends because of how call numbers were stored in a hash table. The hash table, "iax_peercallno_pvt", storing all the current call numbers did not take into account the complications associated with transferring a call, so a separate hash table was required. This second hash table "iax_transfercallno_pvt" handles calls being transfered, once the call transfer is complete the call is removed from the transfer hash table and added to the peer hash table resuming normal operations. Addition functions were created to handle storing, removing, and comparing items in the iax_transfercallno_pvt table. (issue #13468) Review: http://reviewboard.digium.com/r/140/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@173248 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-26Resolve some synchronization issues in chan_iax2 scheduler handling.russell1-15/+25
The important changes here are related to the synchronization between threads adding items into the scheduler and the scheduler handling thread. By adjusting the lock and condition handling, we ensure that the scheduler thread sleeps no longer and no less than it is supposed to. We also ensure that it does not wake up more often than it has to. There is no bug report associated with this. It is just something that I found while putting scheduler thread handling into a reusable form (review 129). Review: http://reviewboard.digium.com/r/131/ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@171452 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-23Additions to AST-2009-001tilghman1-16/+17
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@170588 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-06Merged revisions 167259 via svnmerge from tilghman1-4/+16
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r167259 | tilghman | 2009-01-06 14:44:03 -0600 (Tue, 06 Jan 2009) | 2 lines Security fix AST-2009-001. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@167260 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-23Compile, even if both DAHDI and Zaptel are not installed.tilghman1-0/+2
(Closes issue #14120) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@166592 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-19(closes issue #13480)jpeeler1-12/+2
Reported by: tzafrir Replace a bunch of if defined checks for Zaptel/DAHDI through several new defines in dahdi_compat.h. This removes a lot of code duplication. Example from bug: #ifdef HAVE_ZAPTEL fd = open("/dev/zap/pseudo", O_RDWR); #else fd = open("/dev/dahdi/pseudo", O_RDWR); #endif is replaced with: fd = open(DAHDI_FILE_PSEUDO, O_RDRW); git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@165991 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-03During bridge code, the channel bridge may return a retry code, if a transfertilghman1-0/+4
was initiated but not yet completed. If the bridge is immediately retried, then we may send a storm of TXREQ packets, even though the first set is sent reliably (retransmitted). Fixes AST-137. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@160570 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-01Apply some logic used in iax2_indicate() to iax2_setoption(), as well, since ↵russell1-12/+42
they both have the potential to send control frames in the middle of call setup. We have to wait until we have received a message back from the remote end before we try to send any more frames. Otherwise, the remote end will consider it invalid, and we'll get stuck in an INVAL/VNAK storm. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@160003 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-29update dev-mode compiler flags to match the ones used by default on Ubuntu ↵kpfleming1-3/+3
Intrepid, so all developers will see the same warnings and errors since this branch already had some printf format attributes, enable checking for them and tag functions that didn't have them format attributes in a consistent way git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@159808 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-25(closes issue #12694)murf1-0/+7
Reported by: yraber Patches: 12694.2nd.diff uploaded by murf (license 17) Tested by: murf, laurav Thanks to file (Joshua Colp) for his IAX fix. the change to cdr.c allows no-answer to percolate up into CDR's, and feels like the right place to locate this fix; if BUSY is done here, no-answer should be, too. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@159316 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-25Don't try to send a response on a NULL pvt.tilghman1-1/+1
(closes issue #13919) Reported by: barthpbx Patches: chan_iax2.c.patch uploaded by eliel (license 64) Tested by: barthpbx git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@159269 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-25Merged revisions 159245 via svnmerge from tilghman1-2/+2
https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r159245 | tilghman | 2008-11-25 15:37:06 -0600 (Tue, 25 Nov 2008) | 7 lines Regression fix for last security fix. Set the iseqno correctly. (closes issue #13918) Reported by: ffloimair Patches: 20081119__bug13918.diff.txt uploaded by Corydon76 (license 14) Tested by: ffloimair ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@159246 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-26 09:38:27 +0000