aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2009-11-09Merged revisions 228858 via svnmerge from mnicholson1-14/+15
https://origsvn.digium.com/svn/asterisk/trunk ................ r228858 | mnicholson | 2009-11-09 08:37:07 -0600 (Mon, 09 Nov 2009) | 15 lines Merged revisions 228827 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r228827 | mnicholson | 2009-11-09 08:16:03 -0600 (Mon, 09 Nov 2009) | 8 lines Perform limited bounds checking when destroying ast_mutex_t structures to make sure we don't try to use negative indices. (closes issue #15588) Reported by: zerohalo Patches: 20090820__issue15588.diff.txt uploaded by tilghman (license 14) Tested by: zerohalo ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@228860 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-28Merged revisions 226305 via svnmerge from tilghman1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r226305 | tilghman | 2009-10-28 13:04:05 -0500 (Wed, 28 Oct 2009) | 9 lines Merged revisions 226304 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r226304 | tilghman | 2009-10-28 13:02:25 -0500 (Wed, 28 Oct 2009) | 2 lines Fix documentation (pointed out by TheDavidFactor on #-dev) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@226307 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-22Merged revisions 225445 via svnmerge from dvossel1-6/+8
https://origsvn.digium.com/svn/asterisk/trunk ........ r225445 | dvossel | 2009-10-22 14:55:51 -0500 (Thu, 22 Oct 2009) | 50 lines SIP TCP/TLS: move client connection setup/write into tcp helper thread, various related locking/memory fixes. What this patch fixes 1.Moves sip TCP/TLS connection setup into the TCP helper thread: Connection setup takes awhile and before this it was being done while holding the monitor lock. 2.Moves TCP/TLS writing to the TCP helper thread: Through the use of a packet queue and an alert pipe, the TCP helper thread can now be woken up to write data as well as read data. 3.Locking error: sip_xmit returned an XMIT_ERROR without giving up the tcptls_session lock. This lock has been completely removed from sip_xmit and placed in the new sip_tcptls_write() function. 4.Memory leak: When creating a tcptls_client the tls_cfg was alloced but never freed unless the tcptls_session failed to start. Now the session_args for a sip client are an ao2 object which frees the tls_cfg on destruction. 5.Pointer to stack variable: During sip_prepare_socket the creation of a client's ast_tcptls_session_args was done on the stack and stored as a pointer in the newly created tcptls_session. Depending on the events that followed, there was a slight possibility that pointer could have been accessed after the stack returned. Given the new changes, it is always accessed after the stack returns which is why I found it. Notable code changes 1.I broke tcptls.c's ast_tcptls_client_start() function into two functions. One for creating and allocating the new tcptls_session, and a separate one for starting and handling the new connection. This allowed me to create the tcptls_session, launch the helper thread, and then establish the connection within the helper thread. 2.Writes to a tcptls_session are now done within the helper thread. This is done by using an alert pipe to wake up the thread if new data needs to be sent. The thread's sip_threadinfo object contains the alert pipe as well as the packet queue. 3.Since the threadinfo object contains the alert pipe, it must now be accessed outside of the helper thread for every write (queuing of a packet). For easy lookup, I moved the threadinfo objects from a linked list to an ao2_container. (closes issue #13136) Reported by: pabelanger Tested by: dvossel, whys (closes issue #15894) Reported by: dvossel Tested by: dvossel Review: https://reviewboard.asterisk.org/r/380/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@225490 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-22Merged revisions 225360 via svnmerge from tilghman1-4/+5
https://origsvn.digium.com/svn/asterisk/trunk ................ r225360 | tilghman | 2009-10-22 12:11:23 -0500 (Thu, 22 Oct 2009) | 11 lines Merged revisions 225105 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r225105 | tilghman | 2009-10-21 11:02:12 -0500 (Wed, 21 Oct 2009) | 4 lines Fix documentation for ast_softhangup() and correct the misuse thereof. (closes issue #16103) Reported by: majorbloodnok ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@225362 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-21Merged revisions 224932 via svnmerge from russell3-35/+0
https://origsvn.digium.com/svn/asterisk/trunk ................ r224932 | russell | 2009-10-20 22:09:04 -0500 (Tue, 20 Oct 2009) | 12 lines Merged revisions 224931 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r224931 | russell | 2009-10-20 21:59:54 -0500 (Tue, 20 Oct 2009) | 5 lines Isolate frames returned from a DSP instance or codec translator. The reasoning for these changes are the same as what I wrote in the commit message for rev 222878. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@224935 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-08Merged revisions 222880 via svnmerge from russell2-19/+0
https://origsvn.digium.com/svn/asterisk/trunk ................ r222880 | russell | 2009-10-08 14:52:03 -0500 (Thu, 08 Oct 2009) | 51 lines Merged revisions 222878 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r222878 | russell | 2009-10-08 14:45:47 -0500 (Thu, 08 Oct 2009) | 44 lines Make filestream frame handling safer by isolating frames before returning them. This patch is related to a number of issues on the bug tracker that show crashes related to freeing frames that came from a filestream. A number of fixes have been made over time while trying to figure out these problems, but there re still people seeing the crash. (Note that some of these bug reports include information about other problems. I am specifically addressing the filestream frame crash here.) I'm still not clear on what the exact problem is. However, what is _very_ clear is that we have seen quite a few problems over time related to unexpected behavior when we try to use embedded frames as an optimization. In some cases, this optimization doesn't really provide much due to improvements made in other areas. In this case, the patch modifies filestream handling such that the embedded frame will not be returned. ast_frisolate() is used to ensure that we end up with a completely mallocd frame. In reality, though, we will not actually have to malloc every time. For filestreams, the frame will almost always be allocated and freed in the same thread. That means that the thread local frame cache will be used. So, going this route doesn't hurt. With this patch in place, some people have reported success in not seeing the crash anymore. (SWP-150) (AST-208) (ABE-1834) (issue #15609) Reported by: aragon Patches: filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2) Tested by: aragon, russell (closes issue #15817) Reported by: zerohalo Tested by: zerohalo (closes issue #15845) Reported by: marhbere Review: https://reviewboard.asterisk.org/r/386/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@222882 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-08Merged revisions 222873 via svnmerge from dvossel1-2/+0
https://origsvn.digium.com/svn/asterisk/trunk ........ r222873 | dvossel | 2009-10-08 14:35:30 -0500 (Thu, 08 Oct 2009) | 6 lines fixes an ast_netsock_list memory leak. ABE-1998 Review: https://reviewboard.asterisk.org/r/395/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@222875 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-06Merged revisions 222176 via svnmerge from kpfleming1-13/+55
https://origsvn.digium.com/svn/asterisk/trunk ................ r222176 | kpfleming | 2009-10-05 20:24:24 -0500 (Mon, 05 Oct 2009) | 27 lines Recorded merge of revisions 222152 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r222152 | kpfleming | 2009-10-05 20:16:36 -0500 (Mon, 05 Oct 2009) | 20 lines Fix ao2_iterator API to hold references to containers being iterated. 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.6.1@222186 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-30Merged revisions 221266 via svnmerge from twilson1-0/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r221266 | twilson | 2009-09-30 12:52:30 -0500 (Wed, 30 Sep 2009) | 32 lines Merged revisions 221086 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r221086 | twilson | 2009-09-30 09:49:11 -0500 (Wed, 30 Sep 2009) | 25 lines Change the SSRC by default when our media stream changes Be default, change SSRC when doing an audio stream changes Asterisk doesn't honor marker bit when reinvited to already-bridged RTP streams,resulting in far-end stack discarding packets with "old" timestamps that areactually part of a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a reinvite, unless the 'constantssrc' is set to true in sip.conf. The original issue reported to Digium support detailed the following situation: ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in fromITSP, Asterisk dials the app server which sends a re-invite back toAsterisk--not to negotiate to send media directly to the ITSP, but to indicatethat it's changing the stream it's sending to Asterisk. The app servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker bit on the new stream. Asterisk passes through the teimstamp of the new stream, butdoes not reset the SSRC, sequence numbers, or set the marker bit. When the timestamp on the new stream is older than the timestamp on the originalstream, the ITSP (which doesn't know there has been any change) discards the newframes because it thinks they are too old. This patch addresses this by changing the SSRC on a stream update unless constantssrc=true is set in sip.conf. Review: https://reviewboard.asterisk.org/r/374/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@221302 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-26Merged revisions 220586 via svnmerge from tilghman1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r220586 | tilghman | 2009-09-26 10:10:28 -0500 (Sat, 26 Sep 2009) | 2 lines Allow AES to compile, when OpenSSL is not present. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@220588 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-17Merged revisions 219139 via svnmerge from mnicholson2-0/+8
https://origsvn.digium.com/svn/asterisk/trunk ................ r219139 | mnicholson | 2009-09-17 10:18:01 -0500 (Thu, 17 Sep 2009) | 17 lines Merged revisions 219136 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down. This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list. This fix makes the channel unavabile at the time when the CDR backend is invoked. This has been documented in include/asterisk/cdr.h. (closes issue #15316) Reported by: vmarrone Tested by: mnicholson Review: https://reviewboard.asterisk.org/r/362/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@219199 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-10Merged revisions 217638 via svnmerge from tilghman1-17/+32
https://origsvn.digium.com/svn/asterisk/trunk ........ r217638 | tilghman | 2009-09-10 13:17:14 -0500 (Thu, 10 Sep 2009) | 4 lines Verify support for wide ODBC character types before using them. (closes issue #15870) Reported by: nic_bellamy ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@217642 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-08Merged revisions 217074 via svnmerge from kpfleming1-29/+17
https://origsvn.digium.com/svn/asterisk/trunk ........ r217074 | kpfleming | 2009-09-08 11:37:28 -0500 (Tue, 08 Sep 2009) | 9 lines Ensure that the default autoconf CFLAGS are not used. A recent change to the configure script that allows the user to specify CFLAGS and/or LDFLAGS to the script had the unfortunate side effect of letting autoconf's default CFLAGS (-g -O2) feed in to the rest of the build system, thereby overriding the DONT_OPTIMIZE setting in menuselect. That problem is now corrected. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@217076 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-04Merged revisions 216551 via svnmerge from tilghman1-6/+4
https://origsvn.digium.com/svn/asterisk/trunk ........ r216551 | tilghman | 2009-09-04 12:50:21 -0500 (Fri, 04 Sep 2009) | 2 lines Fix trunk breakage. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@216552 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-04Merged revisions 216437 via svnmerge from mvanbaak1-0/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r216437 | mvanbaak | 2009-09-04 16:00:38 +0200 (Fri, 04 Sep 2009) | 2 lines make sure canlog is set so we can compile with DEBUG_THREADS enabled on OpenBSD ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@216440 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-03Merged revisions 215955 via svnmerge from dvossel2-0/+12
https://origsvn.digium.com/svn/asterisk/trunk ........ r215955 | dvossel | 2009-09-03 11:31:54 -0500 (Thu, 03 Sep 2009) | 6 lines Merge code associated with AST-2009-006 (closes issue #12912) Reported by: rathaus Tested by: tilghman, russell, dvossel, dbrooks ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@216004 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-30Merged revisions 214819 via svnmerge from tilghman1-17/+32
https://origsvn.digium.com/svn/asterisk/trunk ........ r214819 | tilghman | 2009-08-30 01:43:04 -0500 (Sun, 30 Aug 2009) | 4 lines If lua is detected with the lua5.1 prefix (or not), adjust the include path accordingly. Based upon feedback to a release announcement on the -users list. See http://lists.digium.com/pipermail/asterisk-users/2009-August/236954.html ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@214821 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-28Merged revisions 214696 via svnmerge from kpfleming1-29/+17
https://origsvn.digium.com/svn/asterisk/trunk ........ r214696 | kpfleming | 2009-08-28 15:01:21 -0500 (Fri, 28 Aug 2009) | 9 lines Ensure that CFLAGS and/or LDFLAGS provided to configure script are preserved. Cross-compilation environments want to provide 'defaults' for compiler and linker options, and frequently do this by specifying CFLAGS and LDFLAGS in the environment or as command-line arguments to the configure script. This patch modifies the configure script and Makefile to preserve these settings and ensure they are used in the build process. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@214699 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-27Merged revisions 214518 via svnmerge from tilghman1-1/+55
https://origsvn.digium.com/svn/asterisk/trunk ................ r214518 | tilghman | 2009-08-27 16:46:46 -0500 (Thu, 27 Aug 2009) | 14 lines Merged revisions 214517 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r214517 | tilghman | 2009-08-27 16:45:34 -0500 (Thu, 27 Aug 2009) | 7 lines Use autoconf to detect libcurl, as this enables cross-compilation checks, something we didn't allow before. (closes issue #15714) Reported by: pprindeville Patches: 20090813__issue15714.diff.txt uploaded by tilghman (license 14) Tested by: pprindeville ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@214520 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-27Merged revisions 214466 via svnmerge from tilghman1-280/+180
https://origsvn.digium.com/svn/asterisk/trunk ................ r214466 | tilghman | 2009-08-27 12:28:01 -0500 (Thu, 27 Aug 2009) | 9 lines Merged revisions 214436 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r214436 | tilghman | 2009-08-27 11:53:58 -0500 (Thu, 27 Aug 2009) | 2 lines One more build system change, to make the descriptions look better, if we have better information. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@214496 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-27Merged revisions 214360 via svnmerge from tilghman1-184/+184
https://origsvn.digium.com/svn/asterisk/trunk ................ r214360 | tilghman | 2009-08-27 11:12:03 -0500 (Thu, 27 Aug 2009) | 10 lines Merged revisions 214357 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r214357 | tilghman | 2009-08-27 11:03:50 -0500 (Thu, 27 Aug 2009) | 3 lines Make autoheader descriptions render correctly in our autoconfig.h file. (Figured out while working with issue #14906) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@214365 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-25Merged revisions 214152 via svnmerge from tilghman1-17/+29
https://origsvn.digium.com/svn/asterisk/trunk ........ r214152 | tilghman | 2009-08-25 17:39:51 -0500 (Tue, 25 Aug 2009) | 4 lines Not all versions of gnu-linux use glibc, which contains iconv. Some (especially embedded systems) don't have iconv at all. (closes issue #15169) Reported by: pprindeville ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@214154 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-21Merged revisions 213560 via svnmerge from tilghman1-0/+6
https://origsvn.digium.com/svn/asterisk/trunk ................ r213560 | tilghman | 2009-08-21 11:53:52 -0500 (Fri, 21 Aug 2009) | 14 lines Merged revisions 213559 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r213559 | tilghman | 2009-08-21 11:52:53 -0500 (Fri, 21 Aug 2009) | 7 lines Permit DEBUG_FD_LEAKS to be used with C++ source files. (closes issue #15698) Reported by: slavon Patches: 20090817__issue15698.diff.txt uploaded by tilghman (license 14) Tested by: slavon, tilghman ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@213562 f38db490-d61c-443f-a65b-d21fe96a405b
2009-08-06Merged revisions 210908 via svnmerge from tilghman1-3/+9
https://origsvn.digium.com/svn/asterisk/trunk ........ r210908 | tilghman | 2009-08-06 16:29:26 -0500 (Thu, 06 Aug 2009) | 9 lines Allow Gosub to recognize quote delimiters without consuming them. (closes issue #15557) Reported by: rain Patches: 20090723__issue15557.diff.txt uploaded by tilghman (license 14) Tested by: rain Review: https://reviewboard.asterisk.org/r/316/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@210910 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-30Merged revisions 209554 via svnmerge from dbrooks1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r209554 | dbrooks | 2009-07-30 11:07:05 -0500 (Thu, 30 Jul 2009) | 6 lines Fixes numerous spelling errors. Patch submitted by alecdavis. (closes issue #15595) Reported by: alecdavis ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@209593 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-27Merged revisions 209098 via svnmerge from dbrooks1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r209098 | dbrooks | 2009-07-27 11:33:50 -0500 (Mon, 27 Jul 2009) | 6 lines Fixing typos. Replaces "recieved" with "received" and "initilize" with "initialize" (closes issue #15571) Reported by: alecdavis ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@209233 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-24Merged revisions 208548 via svnmerge from kpfleming1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r208548 | kpfleming | 2009-07-24 10:02:53 -0500 (Fri, 24 Jul 2009) | 8 lines Resolve a T.38 negotiation issue left over from the udptl-updates merge. The udptl-updates branch that was merged yesterday failed to properly send back T.38 SDP responses with the correct error correction mode, if the incoming SDP from the other end caused us to change error correction modes. This patch corrects that situation. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@208550 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-23Merged revisions 208464 via svnmerge from kpfleming2-31/+27
https://origsvn.digium.com/svn/asterisk/trunk ........ r208464 | kpfleming | 2009-07-23 16:57:24 -0500 (Thu, 23 Jul 2009) | 46 lines Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@208484 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-09Merged revisions 205696 via svnmerge from kpfleming1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r205696 | kpfleming | 2009-07-09 16:20:23 -0500 (Thu, 09 Jul 2009) | 16 lines Repair ability of SendFAX/ReceiveFAX to respond to T.38 switchover. Recent changes in T.38 negotiation in Asterisk caused these applications to not respond when the other endpoint initiated a switchover to T.38; this resulted in the T.38 switchover failing, and the FAX attempt to be made using an audio connection, instead of T.38 (which would usually cause the FAX to fail completely). This patch corrects this problem, and the applications will now correctly respond to the T.38 switchover request. In addition, the response will include the appopriate T.38 session parameters based on what the other end offered and what our end is capable of. (closes issue #14849) Reported by: afosorio ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@205698 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-09Merged revisions 205600 via svnmerge from dvossel1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r205600 | dvossel | 2009-07-09 11:19:09 -0500 (Thu, 09 Jul 2009) | 9 lines Merged revisions 205599 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r205599 | dvossel | 2009-07-09 11:18:09 -0500 (Thu, 09 Jul 2009) | 2 lines Changing ast_samp2tv to not use floating point. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@205605 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-09Merged revisions 205479 via svnmerge from dvossel1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r205479 | dvossel | 2009-07-08 18:19:09 -0500 (Wed, 08 Jul 2009) | 16 lines Merged revisions 205471 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r205471 | dvossel | 2009-07-08 18:15:54 -0500 (Wed, 08 Jul 2009) | 10 lines Fixes 8khz assumptions 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.6.1@205596 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-08Merged revisions 205412 via svnmerge from dvossel2-9/+9
https://origsvn.digium.com/svn/asterisk/trunk ................ r205412 | dvossel | 2009-07-08 17:15:06 -0500 (Wed, 08 Jul 2009) | 12 lines Merged revisions 205409 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r205409 | dvossel | 2009-07-08 16:35:12 -0500 (Wed, 08 Jul 2009) | 6 lines moving ast_devstate_to_extenstate to pbx.c from devicestate.c ast_devstate_to_extenstate belongs in pbx.c. This change fixes a compile time error with chan_vpb as well. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@205414 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-08Merged revisions 205216 via svnmerge from dvossel1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r205216 | dvossel | 2009-07-08 11:54:24 -0500 (Wed, 08 Jul 2009) | 17 lines Merged revisions 205215 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r205215 | dvossel | 2009-07-08 11:53:40 -0500 (Wed, 08 Jul 2009) | 10 lines ast_samp2tv needs floating point for 16khz audio In ast_samp2tv(), (1000000 / _rate) = 62.5 when _rate is 16000. The .5 is currently stripped off because we don't calculate using floating points. This causes madness with 16khz audio. (issue ABE-1899) Review: https://reviewboard.asterisk.org/r/305/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@205218 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-08Merged revisions 205120 via svnmerge from russell1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r205120 | russell | 2009-07-08 10:17:19 -0500 (Wed, 08 Jul 2009) | 16 lines Move OpenSSL initialization to a single place, make library usage thread-safe. While doing some reading about OpenSSL, I noticed a couple of things that needed to be improved with our usage of OpenSSL. 1) We had initialization of the library done in multiple modules. This has now been moved to a core function that gets executed during Asterisk startup. We already link OpenSSL into the core for TCP/TLS functionality, so this was the most logical place to do it. 2) OpenSSL is not thread-safe by default. However, making it thread safe is very easy. We just have to provide a couple of callbacks. One callback returns a thread ID. The other handles locking. For more information, start with the "Is OpenSSL thread-safe?" question on the FAQ page of openssl.org. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@205147 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-02Merged revisions 204710 via svnmerge from dvossel1-0/+10
https://origsvn.digium.com/svn/asterisk/trunk ................ r204710 | dvossel | 2009-07-02 11:03:44 -0500 (Thu, 02 Jul 2009) | 21 lines Merged revisions 204681 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r204681 | dvossel | 2009-07-02 10:05:57 -0500 (Thu, 02 Jul 2009) | 14 lines Improved mapping of extension states from combined device states. This fixes a few issues with incorrect extension states and adds a cli command, core show device2extenstate, to display all possible state mappings. (closes issue #15413) Reported by: legart Patches: exten_helper.diff uploaded by dvossel (license 671) Tested by: dvossel, legart, amilcar Review: https://reviewboard.asterisk.org/r/301/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@204736 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-26Merged revisions 203702 via svnmerge from russell1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r203702 | russell | 2009-06-26 14:31:14 -0500 (Fri, 26 Jun 2009) | 5 lines Make invalid hints report Unavailable instead of Idle. (closes issue #14413) Reported by: pj ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@203704 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-26Merged revisions 203699 via svnmerge from file1-0/+26
https://origsvn.digium.com/svn/asterisk/trunk ........ r203699 | file | 2009-06-26 16:27:24 -0300 (Fri, 26 Jun 2009) | 2 lines Improve T.38 negotiation by exchanging session parameters between application and channel. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@203703 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-22Merged revisions 202410 via svnmerge from dvossel1-4/+5
https://origsvn.digium.com/svn/asterisk/trunk ........ r202410 | dvossel | 2009-06-22 10:33:35 -0500 (Mon, 22 Jun 2009) | 5 lines attempting to load running modules Modules placed in the priority heap for loading were not properly removed from the linked list. This resulted in some modules attempting to load twice. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@202412 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-17Merged revisions 201262 via svnmerge from kpfleming1-5/+8
https://origsvn.digium.com/svn/asterisk/trunk ................ r201262 | kpfleming | 2009-06-17 07:04:17 -0500 (Wed, 17 Jun 2009) | 15 lines Merged revisions 201261 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r201261 | kpfleming | 2009-06-17 07:03:25 -0500 (Wed, 17 Jun 2009) | 9 lines Correct AST_LIST_APPEND_LIST behavior when list to be appended is empty. When the list to be appended is empty, and the list to be appended to is *not*, AST_LIST_APPEND_LIST would actually cause the target list to become broken, and no longer have a pointer to its last entry. This patch fixes the problem. (reported by Stanislaw Pitucha on the asterisk-dev mailing list) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@201264 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-16Merged revisions 201056 via svnmerge from kpfleming3-9/+45
https://origsvn.digium.com/svn/asterisk/trunk ................ r201056 | kpfleming | 2009-06-16 13:54:30 -0500 (Tue, 16 Jun 2009) | 18 lines Merged revisions 200991 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r200991 | kpfleming | 2009-06-16 12:05:38 -0500 (Tue, 16 Jun 2009) | 11 lines Improve support for media paths that can generate multiple frames at once. There are various media paths in Asterisk (codec translators and UDPTL, primarily) that can generate more than one frame to be generated when the application calling them expects only a single frame. This patch addresses a number of those cases, at least the primary ones to solve the known problems. In addition it removes the broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API functions, and cleans up various code paths affected by these changes. https://reviewboard.asterisk.org/r/175/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@201096 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-16Merged revisions 200764 via svnmerge from kpfleming1-29/+17
https://origsvn.digium.com/svn/asterisk/trunk ........ r200764 | kpfleming | 2009-06-15 20:28:08 -0500 (Mon, 15 Jun 2009) | 11 lines Ensure that configure-script testing for compiler attributes actually works. The configure script tests for compiler attributes didn't actually enable enough warnings or provide a proper test harness to determine whether the compiler supports the attribute in question or not; this caused gcc 4.1 to report that it supports 'weakref', but it doesn't actually support it in the way that is needed for our optional API mechanism. The new configure script test will properly distinguish between full support and partial support for this attribute, among others. ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@200766 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-10Merged revisions 199857 via svnmerge from seanbright1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r199857 | seanbright | 2009-06-10 12:10:23 -0400 (Wed, 10 Jun 2009) | 9 lines Merged revisions 199856 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r199856 | seanbright | 2009-06-10 12:08:35 -0400 (Wed, 10 Jun 2009) | 2 lines __WORDSIZE is not available on all platforms, so use sizeof(void *) instead. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@199859 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-09Merged revisions 199743 via svnmerge from dvossel1-0/+8
https://origsvn.digium.com/svn/asterisk/trunk ........ r199743 | dvossel | 2009-06-09 11:22:04 -0500 (Tue, 09 Jun 2009) | 11 lines module load priority This patch adds the option to give a module a load priority. The value represents the order in which a module's load() function is initialized. The lower the value, the higher the priority. The value is only checked if the AST_MODFLAG_LOAD_ORDER flag is set. If the AST_MODFLAG_LOAD_ORDER flag is not set, the value will never be read and the module will be given the lowest possible priority on load. Since some modules are reliant on a timing interface, the timing modules have been given a high load priorty. (closes issue #15191) Reported by: alecdavis Tested by: dvossel Review: https://reviewboard.asterisk.org/r/262/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@199745 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-08Merged revisions 199630 via svnmerge from seanbright1-4/+4
https://origsvn.digium.com/svn/asterisk/trunk ................ r199630 | seanbright | 2009-06-08 15:33:09 -0400 (Mon, 08 Jun 2009) | 32 lines Merged revisions 199626,199628 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r199626 | seanbright | 2009-06-08 15:24:32 -0400 (Mon, 08 Jun 2009) | 21 lines Increase the size of our thread stack on 64 bit processors. We were setting the stack size for each thread to 240KB regardless of architecture, which meant that in some scenarios we actually had less available stack space on 64 bit processors (pointers use 8 bytes instead of 4). So now we calculate the stack size we reserve based on the platform's __WORDSIZE, which gives us: 32 bit -> 240KB 64 bit -> 496KB 128 bit -> 1008KB (that's right, we're ready for 128 bit processors) Patch typed by me but written by several members of #asterisk-dev, including Kevin, Tilghman, and Qwell. (closes issue #14932) Reported by: jpiszcz Patches: 06052009_issue14932.patch uploaded by seanbright (license 71) Tested by: seanbright ........ r199628 | seanbright | 2009-06-08 15:28:33 -0400 (Mon, 08 Jun 2009) | 2 lines Fix a typo in the stack size calculation just introduced. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@199633 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-05Merged revisions 199298 via svnmerge from dvossel1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r199298 | dvossel | 2009-06-05 16:21:22 -0500 (Fri, 05 Jun 2009) | 21 lines Merged revisions 199297 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r199297 | dvossel | 2009-06-05 16:19:56 -0500 (Fri, 05 Jun 2009) | 14 lines Fixes issue with hints giving unexpected results. Hints with two or more devices that include ONHOLD gave unexpected results. (closes issue #15057) Reported by: p_lindheimer Patches: onhold_trunk.diff uploaded by dvossel (license 671) pbx.c.1.4.patch uploaded by p (license 558) devicestate.c.trunk.patch uploaded by p (license 671) Tested by: p_lindheimer, dvossel Review: https://reviewboard.asterisk.org/r/254/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@199300 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-04Merged revisions 199051 via svnmerge from seanbright1-0/+12
https://origsvn.digium.com/svn/asterisk/trunk ................ r199051 | seanbright | 2009-06-04 10:31:24 -0400 (Thu, 04 Jun 2009) | 47 lines Merged revisions 199022 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r199022 | seanbright | 2009-06-04 10:14:57 -0400 (Thu, 04 Jun 2009) | 40 lines Safely handle AMI connections/reload requests that occur during startup. During asterisk startup, a lock on the list of modules is obtained by the primary thread while each module is initialized. Issue 13778 pointed out a problem with this approach, however. Because the AMI is loaded before other modules, it is possible for a module reload to be issued by a connected client (via Action: Command), causing a deadlock. The resolution for 13778 was to move initialization of the manager to happen after the other modules had already been lodaded. While this fixed this particular issue, it caused a problem for users (like FreePBX) who call AMI scripts via an #exec in a configuration file (See issue 15189). The solution I have come up with is to defer any reload requests that come in until after the server is fully booted. When a call comes in to ast_module_reload (from wherever) before we are fully booted, the request is added to a queue of pending requests. Once we are done booting up, we then execute these deferred requests in turn. Note that I have tried to make this a bit more intelligent in that it will not queue up more than 1 request for the same module to be reloaded, and if a general reload request comes in ('module reload') the queue is flushed and we only issue a single deferred reload for the entire system. As for how this will impact existing installations - Before 13778, a reload issued before module initialization was completed would result in a deadlock. After 13778, you simply couldn't connect to the manager during startup (which causes problems with #exec-that-calls-AMI configuration files). I believe this is a good general purpose solution that won't negatively impact existing installations. (closes issue #15189) (closes issue #13778) Reported by: p_lindheimer Patches: 06032009_15189_deferred_reloads.diff uploaded by seanbright (license 71) Tested by: p_lindheimer, seanbright Review: https://reviewboard.asterisk.org/r/272/ ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@199053 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-03Merged revisions 198856 via svnmerge from dvossel1-0/+11
https://origsvn.digium.com/svn/asterisk/trunk ........ r198856 | dvossel | 2009-06-02 16:17:49 -0500 (Tue, 02 Jun 2009) | 10 lines Generic call forward api, ast_call_forward() The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options. (closes issue #13630) Reported by: festr Review: https://reviewboard.asterisk.org/r/271/ ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@198887 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-29Merged revisions 198072 via svnmerge from mnicholson1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r198072 | mnicholson | 2009-05-29 14:04:24 -0500 (Fri, 29 May 2009) | 21 lines Merged revisions 198068 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r198068 | mnicholson | 2009-05-29 13:53:01 -0500 (Fri, 29 May 2009) | 15 lines Use AST_CDR_NOANSWER instead of AST_CDR_NULL as the default CDR disposition. This change also involves the addition of an AST_CDR_FLAG_ORIGINATED flag that is used on originated channels to distinguish: them from dialed channels. (closes issue #12946) Reported by: meral Patches: null-cdr2.diff uploaded by mnicholson (license 96) Tested by: mnicholson, dbrooks (closes issue #15122) Reported by: sum Tested by: sum ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@198074 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-28Merged revisions 197606 via svnmerge from mmichelson1-0/+17
https://origsvn.digium.com/svn/asterisk/trunk ................ r197606 | mmichelson | 2009-05-28 10:32:19 -0500 (Thu, 28 May 2009) | 22 lines Recorded merge of revisions 197588 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r197588 | mmichelson | 2009-05-28 10:27:49 -0500 (Thu, 28 May 2009) | 16 lines Allow for media to arrive from an alternate source when responding to a reinvite with 491. When we receive a SIP reinvite, it is possible that we may not be able to process the reinvite immediately since we have also sent a reinvite out ourselves. The problem is that whoever sent us the reinvite may have also sent a reinvite out to another party, and that reinvite may have succeeded. As a result, even though we are not going to accept the reinvite we just received, it is important for us to not have problems if we suddenly start receiving RTP from a new source. The fix for this is to grab the media source information from the SDP of the reinvite that we receive. This information is passed to the RTP layer so that it will know about the alternate source for media. Review: https://reviewboard.asterisk.org/r/252 ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@197618 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-28Merged revisions 197543 via svnmerge from mmichelson1-0/+4
https://origsvn.digium.com/svn/asterisk/trunk ................ r197543 | mmichelson | 2009-05-28 09:58:06 -0500 (Thu, 28 May 2009) | 27 lines Merged revisions 197537 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r197537 | mmichelson | 2009-05-28 09:49:13 -0500 (Thu, 28 May 2009) | 21 lines Add flags to chanspy audiohook so that audio stays in sync. There are two flags being added to the chanspy audiohook here. One is the pre-existing AST_AUDIOHOOK_TRIGGER_SYNC flag. With this set, we ensure that the read and write slinfactories on the audiohook do not skew beyond a certain tolerance. In addition, there is a new audiohook flag added here, AST_AUDIOHOOK_SMALL_QUEUE. With this flag set, we do not allow for a slinfactory to build up a substantial amount of audio before flushing it. For this particular issue, this means that the person spying on the call will hear the conversations in real time with very little delay in the audio. (closes issue #13745) Reported by: geoffs Patches: 13745.patch uploaded by mmichelson (license 60) Tested by: snblitz ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.1@197545 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-25 05:52:55 +0000