231 Commits (cef5e9d4340f94de8801aaecfb004a080df8a68f)

Author	SHA1	Message	Date
Jeff Peeler	697b634b47	Merged revisions 289797 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r289797 | jpeeler | 2010-10-01 17:58:38 -0500 (Fri, 01 Oct 2010) | 15 lines Change RFC2833 DTMF event duration on end to report actual elapsed time. The scenario here is with a non P2P early media session. The reported time length of DTMF presses are coming up short when sending to the remote side. Currently the event duration is a running total that is incremented when sending continuation packets. These continuation packets are only triggered upon incoming media from the remote side, which means that the running total probably is not going to end up matching the actual length of time Asterisk received DTMF. This patch changes the end event duration to be lengthened if it is detected that the end event is going to come up short. Review: https://reviewboard.asterisk.org/r/957/ ABE-2476 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@289798 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Tilghman Lesher	59f700a9b2	Merged revisions 284478 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r284478 | tilghman | 2010-09-01 13:49:11 -0500 (Wed, 01 Sep 2010) | 11 lines Ensure that all areas that previously used select(2) now use poll(2), with implementations that need poll(2) implemented with select(2) safe against 1024-bit overflows. This is a followup to the fix for the pthread timer in 1.6.2 and beyond, fixing a potential crash bug in all supported releases. (closes issue #17678) Reported by: russell Branch: https://origsvn.digium.com/svn/asterisk/team/tilghman/ast_select Review: https://reviewboard.asterisk.org/r/824/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@284593 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	b04d0eba19	Merged revisions 274164 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r274164 | mmichelson | 2010-07-06 09:31:13 -0500 (Tue, 06 Jul 2010) | 22 lines Merged revisions 274157 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r274157 | mmichelson | 2010-07-06 09:29:23 -0500 (Tue, 06 Jul 2010) | 16 lines Fix problem with RFC 2833 DTMF not being accepted. A recent check was added to ensure that we did not erroneously detect duplicate DTMF when we received packets out of order. The problem was that the check did not account for the fact that the seqno of an RTP stream will roll over back to 0 after hitting 65535. Now, we have a secondary check that will ensure that the seqno rolling over will not cause us to stop accepting DTMF. (closes issue #17571) Reported by: mdeneen Patches: rtp_seqno_rollover.patch uploaded by mmichelson (license 60) Tested by: richardf, maxochoa, JJCinAZ ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@274168 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Paul Belanger	c0684e9148	Merged revisions 273233 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r273233 | pabelanger | 2010-06-30 13:28:04 -0400 (Wed, 30 Jun 2010) | 11 lines Fix rt(c)p set debug ip taking wrong argument Also clean up some coding errors. (closes issue #17469) Reported by: wdoekes Patches: astsvn-rtp-set-debug-ip.patch uploaded by wdoekes (license 717) Tested by: wdoekes, pabelanger ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@273234 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
David Vossel	a1f66d06e0	Merged revisions 264114 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r264114 | dvossel | 2010-05-19 09:38:02 -0500 (Wed, 19 May 2010) | 13 lines fixes crash during dtmf During the processing of Cisco dtmf the dtmf samples were not being calculated correctly. In an attempt to determine what sample rate was being used, a NULL frame was processed which caused a crash. This patch resolves this. (closes issue #17248) Reported by: falves11 Patches: issue_17248.diff uploaded by dvossel (license 671) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264115 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Mark Michelson	4dd02e2d2f	Recorded merge of revisions 254454 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r254454 | mmichelson | 2010-03-25 11:04:48 -0500 (Thu, 25 Mar 2010) | 50 lines Recorded merge of revisions 254452 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r254452 | mmichelson | 2010-03-25 10:59:56 -0500 (Thu, 25 Mar 2010) | 44 lines Several fixes regarding RFC2833 DTMF detection. Here is a copy and paste of the details from my request on reviewboard that dealt with these changes: Fix 1. The first change in place is to fix Mantis issue 15811, which deals with a situation where Asterisk will incorrectly interpret out of order RFC2833 frames as duplicate DTMF digits. For instance, we would receive a sequence like: seqno 1: DTMF 1 seqno 2: DTMF 1 seqno 3: DTMF 1 seqno 4: DTMF 1 seqno 6: DTMF 1 (end) seqno 5: DTMF 1 seqno 7: DTMF 1 (end) seqno 8: DTMF 1 (end) Prior to this patch when we received the frame with seqno 5, we would interpret this as a new DTMF 1. With this patch, we will check the seqno of the incoming digit and not process the frame if the seqno is lower than the last recorded seqno. Note that we do not record the seqno of the dropped DTMF frame for future processing. While the above situation is what was designed to be fixed, the patch is written in such a way that the following would also be fixed too: seqno 9: DTMF 1 seqno 10: DTMF 1 (end) seqno 11: DTMF 1 (end) seqno 13: DTMF 2 seqno 12: DTMF 1 (end) seqno 14: DTMF 2 seqno 15: DTMF 2 (end) seqno 16: DTMF 2 (end) seqno 17: DTMF 2 (end) In this second situation, the beginning of the DTMF 2 arrives before the final end frame of the DTMF 1. With the patch, seqno 12 is no processed and thus we properly interpret the DTMF. Fix 2. The second change in place is to fix an issue like the following: seqno 1: DTMF 1 seqno 2: DTMF 1 seqno 3: DTMF 1 (end) *packet lost* seqno 4: DTMF 1 (end) *packet lost* seqno 5: DTMF 1 (end) *packet lost* seqno 6: DTMF 2 When we receive seqno 6, we had code in place that was supposed to properly end the previously unended DTMF 1. The problem was that the code was essentially a no-op. The code would set up an end frame for the DTMF 1 but would immediately overwrite the frame with the begin for DTMF 2. I changed process_dtmf_rfc2833() so that instead of returning a single frame, it is given as an output parameter a list of frames. Each frame that needs to be returned is appended to this list. Fix 3. The final change is a minor one where an AST_CONTROL_SRCCHANGE frame could get lost. If we process a cisco DTMF or an RFC 3389 frame and no frame was returned, then we would return &ast_null_frame. The problem is that earlier in the function, we may have generated an AST_CONTROL_SRCCHANGE frame and put it in the list of frames we wish to return. This frame would be lost in such a case. The patch fixes this problem ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@254482 65c4cc65-6c06-0410-ace0-fbb531ad65f3	16 years ago
Terry Wilson	dbf0243679	Revert API change in release branches ... This re-renames ast_rtp_update_source to ast_rtp_new_source git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@253158 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	97ec5026ea	Remove unusued field ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@252178 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	6bfb1fca95	Merged revisions 252089 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r252089 | twilson | 2010-03-12 16:04:51 -0600 (Fri, 12 Mar 2010) | 20 lines Only change the RTP ssrc when we see that it has changed This change basically reverts the change reviewed in https://reviewboard.asterisk.org/r/374/ and instead limits the updating of the RTP synchronization source to only those times when we detect that the other side of the conversation has changed the ssrc. The problem is that SRCUPDATE control frames are sent many times where we don't want a new ssrc, including whenever Asterisk has to send DTMF in a normal bridge. This is also not the first time that this mistake has been made. The initial implementation of the ast_rtp_new_source function also changed the ssrc--and then it was removed because of this same issue. Then, we put it back in again to fix a different issue. This patch attempts to only change the ssrc when we see that the other side of the conversation has changed the ssrc. It also renames some functions to make their purpose more clear. Review: https://reviewboard.asterisk.org/r/540/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@252137 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	c78e04979f	Merged revisions 241714 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r241714 | dvossel | 2010-01-20 15:14:47 -0600 (Wed, 20 Jan 2010) | 10 lines rtp timestamp to timeval calculation fix The rtp timestamp to timeval calculation was only accurate for 8kHz audio. This patch corrects this. Review: https://reviewboard.asterisk.org/r/468/ SWP-648 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@241721 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	eb2c2f544f	Merged revisions 231491 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r231491 | dvossel | 2009-11-30 11:28:28 -0600 (Mon, 30 Nov 2009) | 17 lines Merged revisions 231441 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r231441 | dvossel | 2009-11-30 11:14:08 -0600 (Mon, 30 Nov 2009) | 11 lines fixes crash caused by RTP comfort noise payload greater than 24 bytes AST-2009-010 (closes issue #16242) Reported by: amorsen Patches: issue16242.diff uploaded by oej (license 306) Tested by: amorsen, oej, dvossel ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@231505 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	bac1e12c9e	Merged revisions 224671 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r224671 | kpfleming | 2009-10-19 18:47:39 -0500 (Mon, 19 Oct 2009) | 14 lines Merged revisions 224670 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r224670 | kpfleming | 2009-10-19 18:44:07 -0500 (Mon, 19 Oct 2009) | 7 lines Correct timestamp calculations when RTP sample rates over 8kHz are used. While testing some endpoints that support 16kHz and 32kHz sample rates, some log messages were generated due to calc_rxstamp() computing timestamps in a way that produced odd results, so this patch sanitizes the result of the computations. ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@224674 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	a1458fef36	Merged revisions 221777 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r221777 | tilghman | 2009-10-01 18:59:15 -0500 (Thu, 01 Oct 2009) | 9 lines Merged revisions 221776 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r221776 | tilghman | 2009-10-01 18:53:12 -0500 (Thu, 01 Oct 2009) | 2 lines Fix a bunch of off-by-one errors ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@221780 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	9a61ba3e28	Merged revisions 221266 via svnmerge from ... 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@221304 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Olle Johansson	c73b17515c	Fix bad reports in "sip show channelstats". ... Not directly mergeable in svn trunk, needs more tests, therefore committed directly to 1.6.2. (closes issue #15819) Reported by: klaus3000 Patches: asterisk-1.6.2-beta4-sipshowchannelstats-patch-0.2.txt uploaded by klaus3000 (license 65) Tested by: klaus3000, oej git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@215887 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	bbf4a08fe7	Merged revisions 210190 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r210190 | kpfleming | 2009-08-03 15:48:48 -0500 (Mon, 03 Aug 2009) | 11 lines Rename 'canreinvite' option to 'directmedia', with backwards compatibility. It is clear from multiple mailing list, forum, wiki and other sorts of posts that users don't really understand the effects that the 'canreinvite' config option actually has, and that in some cases they think that setting it to 'no' will actually cause various other features (T.38, MOH, etc.) to not work properly, when in fact this is not the case. This patch changes the proper name of the option to what it should have been from the beginning ('directmedia'), but preserves backwards compatibility for existing configurations. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@210191 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	aa536b984a	Merged revisions 209235 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r209235 | mmichelson | 2009-07-27 15:54:54 -0500 (Mon, 27 Jul 2009) | 5 lines Gracefully handle malformed RTP text packets. AST-2009-004 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@209238 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	03d73280b3	Merged revisions 208464 via svnmerge from ... 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@208501 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	4088c54d14	Merged revisions 205479 via svnmerge from ... 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@205595 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	45d9ad47ca	Merged revisions 203699 via svnmerge from ... 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@203705 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	cb75242f9f	Don't access rtp->rtcp->* if rtp->rtcp is null ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@200172 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	ee9fded518	Merged revisions 197606 via svnmerge from ... 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: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@197619 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	3078814e20	Merged revisions 195096 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r195096 | file | 2009-05-18 10:56:16 -0300 (Mon, 18 May 2009) | 12 lines Merged revisions 195095 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r195095 | file | 2009-05-18 10:53:39 -0300 (Mon, 18 May 2009) | 5 lines Fix a bug where the codecs of the called party leg were not properly sent back to the caller call leg when reinvited. (closes issue #13569) Reported by: bkw918 ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@195099 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	eebe545917	Merged revisions 194209 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ................ r194209 | file | 2009-05-13 10:39:10 -0300 (Wed, 13 May 2009) | 18 lines Merged revisions 194208 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r194208 | file | 2009-05-13 10:38:01 -0300 (Wed, 13 May 2009) | 11 lines Fix RFC2833 issues with DTMF getting duplicated and with duration wrapping over. (closes issue #14815) Reported by: geoff2010 Patches: v1-14815.patch uploaded by dimas (license 88) Tested by: geoff2010, file, dimas, ZX81, moliveras (closes issue #14460) Reported by: moliveras Tested by: moliveras ........ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@194213 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Joshua Colp	8fff8ab669	Merged revisions 188413 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/trunk ........ r188413 | file | 2009-04-14 14:40:50 -0300 (Tue, 14 Apr 2009) | 5 lines Fix an incorrect clock rate when sending T140 text. (closes issue #14029) Reported by: epicac ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@188416 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	2f24689b49	Merged revisions 180372 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r180372 | kpfleming | 2009-03-05 12:22:16 -0600 (Thu, 05 Mar 2009) | 9 lines Fix problems when RTP packet frame size is changed During some code analysis, I found that calling ast_rtp_codec_setpref() on an ast_rtp session does not work as expected; it does not adjust the smoother that may on the RTP session, in fact it summarily drops it, even if it has data in it, even if the current format's framing size has not changed. This is not good. This patch changes this behavior, so that if the packetization size for the current format changes, any existing smoother is safely updated to use the new size, and if no smoother was present, one is created. A new API call for smoothers, ast_smoother_reconfigure(), was required to implement these changes. Review: http://reviewboard.digium.com/r/184/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180373 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	d2fb14e26c	Merged revisions 178373 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178373 | russell | 2009-02-24 14:36:19 -0600 (Tue, 24 Feb 2009) | 6 lines Only set dtmfcount on BEGIN, and ensure it gets reset to 0 properly. (issue #14460) Reported by: moliveras Tested by: russell ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@178374 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	5c178fb42b	Merged revisions 178141 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r178141 | russell | 2009-02-23 17:09:01 -0600 (Mon, 23 Feb 2009) | 14 lines Fix infinite DTMF when a BEGIN is received without an END. This commit is related to rev 175124 of 1.4 where a previous attempt was made to fix this problem. The problem with the previous patch was that the inserted code needed to go _before_ setting the lastrxts to the current timestamp. Because those were the same, the dtmfcount variable was never decremented, and so the END was never sent. In passing, I removed the dtmfsamples variable which was completed unused. I also removed a redundant setting of the lastrxts variable. (closes issue #14460) Reported by: moliveras ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@178142 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Kevin P. Fleming	3dcdaa5d05	suppress smoothers for Siren codecs as well as Speex and G.723.1 ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176841 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Kevin P. Fleming	2a53f2ec98	Add basic (passthrough, playback, record) support for ITU G.722.1 and G.722.1C (also known as Siren7 and Siren14) ... This patch adds passthrough, file recording and file playback support for the codecs listed above, with negotiation over SIP/SDP supported. Due to Asterisk's current limitation of treating a codec/bitrate combination as a unique codec, only G.722.1 at 32 kbps and G.722.1C at 48 kbps are supported. Along the way, some related work was done: 1) The rtpPayloadType structure definition, used as a return result for an API call in rtp.h, was moved from rtp.c to rtp.h so that the API call was actually usable. The only previous used of the API all was chan_h323.c, which had a duplicate of the structure definition instead of doing it the right way. 2) The hardcoded SDP sample rates for various codecs in chan_sip.c were removed, in favor of storing these sample rates in rtp.c along with the codec definitions there. A new API call was added to allow retrieval of the sample rate for a given codec. 3) Some basic 'a=fmtp' parsing for SDP was added to chan_sip, because chan_sip *must* decline any media streams offered for these codecs that are not at the bitrates that we support (otherwise Bad Things (TM) would result). Review: http://reviewboard.digium.com/r/158/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175508 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Russell Bryant	12f02a8c11	Merged revisions 175124 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r175124 | russell | 2009-02-12 10:51:13 -0600 (Thu, 12 Feb 2009) | 27 lines Don't send DTMF for infinite time if we do not receive an END event. I thought that this was going to end up being a pretty gnarly fix, but it turns out that there was actually already a configuration option in rtp.conf, dtmftimeout, that was intended to handle this situation. However, in between Asterisk 1.2 and Asterisk 1.4, the code that processed the option got lost. So, this commit brings it back to life. The default timeout is 3 seconds. However, it is worth noting that having this be configurable at all is not really the recommended behavior in RFC 2833. From Section 3.5 of RFC 2833: Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". Regardless of the algorithm used, the tone SHOULD NOT be extended by more than three packet interarrival times. A slight extension of tone durations and shortening of pauses is generally harmless. Three seconds will pretty much _always_ be far more than three packet interarrival times. However, that behavior is not required, so I'm going to leave it with our legacy behavior for now. Code from svn/asterisk/team/russell/issue_14460 (closes issue #14460) Reported by: moliveras ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175125 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Joshua Colp	2bf6d8955d	Merged revisions 170239 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r170239 | file | 2009-01-22 16:02:35 -0400 (Thu, 22 Jan 2009) | 7 lines Don't crash if RTCP is not enabled on an RTP structure but statistics are output. (closes issue #14234) Reported by: jcovert Patches: rtp.c.patch-1.6.0.3 uploaded by jcovert (license 551) rtp.c.patch-svn-165599 uploaded by jcovert (license 551) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@170240 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Joshua Colp	549fcd78a1	Merged revisions 165591 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r165591 | file | 2008-12-18 13:11:42 -0400 (Thu, 18 Dec 2008) | 4 lines Only care about a compatible codec for early bridging if we are actually bridging to another channel. If we are not we actually want to bring the audio back to us. (closes issue #13545) Reported by: davidw ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@165599 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Joshua Colp	402bd762c0	Merged revisions 162653 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r162653 | file | 2008-12-10 12:05:29 -0400 (Wed, 10 Dec 2008) | 6 lines Increment the sequence number on the end packets for RFC2833. After reading the RFC some more and doing some testing I agree with this change. (closes issue #12983) Reported by: vt Patches: dtmf_inc_seqnum_on_end_pkts.diff uploaded by vt (license 520) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162656 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Joshua Colp	90f6a8eeee	Merged revisions 162204 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r162204 | file | 2008-12-09 15:47:07 -0400 (Tue, 09 Dec 2008) | 7 lines Make sure that the timestamp for DTMF is not the same as the previous voice frame and do not send audio when transmitting DTMF as this confuses some equipment. (closes issue #13209) Reported by: ip-rob Patches: 13209.diff uploaded by file (license 11) Tested by: ip-rob, bujones ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162205 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Joshua Colp	f02e8e9ea9	Merged revisions 162188 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r162188 | file | 2008-12-09 15:06:14 -0400 (Tue, 09 Dec 2008) | 4 lines Take video into account when early bridging RTP. (closes issue #13535) Reported by: davidw ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@162197 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Jeff Peeler	8dd432ec5e	Merged revisions 161013 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r161013 | jpeeler | 2008-12-04 12:30:41 -0600 (Thu, 04 Dec 2008) | 9 lines (closes issue #13835) Reported by: matt_b Tested by: jpeeler This mirrors a check that was present in ast_rtp_read to also be in ast_rtp_raw_write to not schedule sending the receiver report if the remote RTCP endpoint address isn't present in the RTCP structure. Closes AST-142. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@161014 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Michiel van Baak	86f900b201	This commit does two things: ... - Add CLI aliases module to asterisk. - Remove all deprecated CLI commands from the code Initial work done by file. Junk-Y and lmadsen did a lot of work and testing to get the list of deprecated commands into the configuration file. Deprecated CLI commands are now handled by this new module, see cli_aliases.conf for more info about that. ok russellb@ via reviewboard (closes issue #13735) Reported by: mvanbaak git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@156120 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	fd6ee6e1f2	Merged revisions 154060 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r154060 | tilghman | 2008-11-03 15:48:21 -0600 (Mon, 03 Nov 2008) | 3 lines Remove the potential for a division by zero error. (Closes issue #13810) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@154061 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Steve Murphy	e235a07376	(closes issue #13557) ... Reported by: nickpeirson Patches: pbx.c.patch uploaded by nickpeirson (license 579) replace_bzero+bcopy.patch uploaded by nickpeirson (license 579) Tested by: nickpeirson, murf 1. replaced all refs to bzero and bcopy to memset and memmove instead. 2. added a note to the CODING-GUIDELINES 3. add two macros to asterisk.h to prevent bzero, bcopy from creeping back into the source 4. removed bzero from configure, configure.ac, autoconfig.h.in git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@147807 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	224980b07b	Merged revisions 143337 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r143337 | mmichelson | 2008-09-17 13:24:15 -0500 (Wed, 17 Sep 2008) | 6 lines Allow for "G.729" if offered in an SDP even though it is not RFC 3551 compliant. Some Cisco switches will send this in an SDP, and it doesn't hurt to be able to accept this. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@143340 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Tilghman Lesher	08af5bb312	Create a new config file status, CONFIG_STATUS_FILEINVALID for differentiating ... when a file is invalid from when a file is missing. This is most important when we have two configuration files. Consider the following example: Old system: sip.conf users.conf Old result New result ======== ========== ========== ========== Missing Missing SIP doesn't load SIP doesn't load Missing OK SIP doesn't load SIP doesn't load Missing Invalid SIP doesn't load SIP doesn't load OK Missing SIP loads SIP loads OK OK SIP loads SIP loads OK Invalid SIP loads incompletely SIP doesn't load Invalid Missing SIP doesn't load SIP doesn't load Invalid OK SIP doesn't load SIP doesn't load Invalid Invalid SIP doesn't load SIP doesn't load So in the case when users.conf doesn't load because there's a typo that disrupts the syntax, we may only partially load users, instead of failing with an error, which may cause some calls not to get processed. Worse yet, the old system would do this with no indication that anything was even wrong. (closes issue #10690) Reported by: dtyoo Patches: 20080716__bug10690.diff.txt uploaded by Corydon76 (license 14) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@142992 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Sean Bright	9ff1434641	Add missing colons to RTCPReceived and RTCPSent manager events. ... (closes issue #13319) Reported by: srt Patches: 13319_rtcp_manager_event_headers.diff uploaded by srt (license 378) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@138476 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Sean Bright	790fde68d9	Another batch of files from RSW. The remaining apps and a few more ... files from main/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@137089 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Sean Bright	b69c8e6ab5	Another big chunk of changes from the RSW branch. Bunch of stuff from main/ ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@137082 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	b3970abc30	Merged revisions 136062 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r136062 | mmichelson | 2008-08-06 10:58:40 -0500 (Wed, 06 Aug 2008) | 16 lines Since adding the AST_CONTROL_SRCUPDATE frame type, there are places where ast_rtp_new_source may be called where the tech_pvt of a channel may not yet have an rtp structure allocated. This caused a crash in chan_skinny, which was fixed earlier, but now the same crash has been reported against chan_h323 as well. It seems that the best solution is to modify ast_rtp_new_source to not attempt to set the marker bit if the rtp structure passed in is NULL. This change to ast_rtp_new_source also allows the removal of what is now a redundant pointer check from chan_skinny. (closes issue #13247) Reported by: pj ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@136063 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Mark Michelson	cd16dca459	Merged revisions 129436 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r129436 | mmichelson | 2008-07-09 14:32:20 -0500 (Wed, 09 Jul 2008) | 13 lines Fix a problem where inbound rfc2833 audio would be sent to the core instead of being P2P bridged. When the core regenerated the rfc2833 packet for the outbound leg, the SSRC would be different than the RTP audio on the call leg causing DTMF detection issues on the far end. (closes issue #12955) Reported by: tonyredstone Patches: dynamic_rtp.patch uploaded by tsearle (license 373) Tested by: tonyredstone ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@129437 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Brett Bryant	d185405755	Janitor project to convert sizeof to ARRAY_LEN macro. ... (closes issue #13002) Reported by: caio1982 Patches: janitor_arraylen5.diff uploaded by caio1982 (license 22) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@129045 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Joshua Colp	945d7022c2	Make this actually evaluate how it was intended to be. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@128198 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago
Olle Johansson	0a52297cf0	Add new SIP cli command "sip show channelstats" that displays some QoS data (if we have RTCP reports ... and not use the p2p rtp bridge). I could not find a way to detect us using the p2p bridge, which would be nice. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@128197 65c4cc65-6c06-0410-ace0-fbb531ad65f3	18 years ago