aboutsummaryrefslogtreecommitdiffstats
path: root/main/rtp.c
AgeCommit message (Collapse)AuthorFilesLines
2010-03-25Recorded merge of revisions 254454 via svnmerge from mmichelson1-14/+36
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@254455 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-17Revert API change in release branchestwilson1-1/+1
This re-renames ast_rtp_update_source to ast_rtp_new_source git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@253158 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-13Remove unused fieldtwilson1-1/+0
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@252176 f38db490-d61c-443f-a65b-d21fe96a405b
2010-03-12Merged revisions 252089 via svnmerge from twilson1-14/+38
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@252134 f38db490-d61c-443f-a65b-d21fe96a405b
2010-01-20Merged revisions 241714 via svnmerge from dvossel1-18/+6
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@241758 f38db490-d61c-443f-a65b-d21fe96a405b
2009-11-30Merged revisions 231491 via svnmerge from dvossel1-1/+0
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@231517 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-19Merged revisions 224671 via svnmerge from kpfleming1-9/+14
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@224672 f38db490-d61c-443f-a65b-d21fe96a405b
2009-10-02Merged revisions 221777 via svnmerge from tilghman1-5/+5
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@221778 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-30Merged revisions 221266 via svnmerge from twilson1-1/+9
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.0@221301 f38db490-d61c-443f-a65b-d21fe96a405b
2009-09-12Use the ip for the new 'rtp set debug ip <foo>'.mvanbaak1-4/+8
Since 1.6.X still has the deprecated 'rtp debug ip <foo>' this patch is different from the fix that went into trunk (closes issue #15711) Reported by: davidw Patches: 2009082800-rtpdebug.diff.txt uploaded by mvanbaak (license 7) Tested by: davidw git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@218108 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-23Merged revisions 208464 via svnmerge from kpfleming1-2/+0
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.0@208468 f38db490-d61c-443f-a65b-d21fe96a405b
2009-07-09Merged revisions 205479 via svnmerge from dvossel1-19/+25
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.0@205597 f38db490-d61c-443f-a65b-d21fe96a405b
2009-06-26Merged revisions 203699 via svnmerge from file1-2/+4
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.0@203701 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-28Merged revisions 197606 via svnmerge from mmichelson1-4/+20
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.0@197615 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-18Merged revisions 195096 via svnmerge from file1-1/+2
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@195097 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-13Merged revisions 194209 via svnmerge from file1-23/+58
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@194211 f38db490-d61c-443f-a65b-d21fe96a405b
2009-04-14Merged revisions 188413 via svnmerge from file1-2/+2
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@188414 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-05Merged revisions 180373 via svnmerge from kpfleming1-7/+41
https://origsvn.digium.com/svn/asterisk/trunk ................ r180373 | kpfleming | 2009-03-05 12:29:38 -0600 (Thu, 05 Mar 2009) | 15 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@180377 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-24Merged revisions 178374 via svnmerge from russell1-2/+4
https://origsvn.digium.com/svn/asterisk/trunk ................ r178374 | russell | 2009-02-24 14:39:57 -0600 (Tue, 24 Feb 2009) | 14 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@178378 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-23Merged revisions 178142 via svnmerge from russell1-6/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r178142 | russell | 2009-02-23 17:11:37 -0600 (Mon, 23 Feb 2009) | 22 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@178145 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-12Merged revisions 175125 via svnmerge from russell1-0/+15
https://origsvn.digium.com/svn/asterisk/trunk ................ r175125 | russell | 2009-02-12 10:57:25 -0600 (Thu, 12 Feb 2009) | 35 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@175126 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-22Merged revisions 170240 via svnmerge from file1-12/+12
https://origsvn.digium.com/svn/asterisk/trunk ................ r170240 | file | 2009-01-22 16:04:39 -0400 (Thu, 22 Jan 2009) | 14 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@170241 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-18Merged revisions 165599 via svnmerge from file1-3/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r165599 | file | 2008-12-18 13:13:32 -0400 (Thu, 18 Dec 2008) | 11 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@165603 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-10Merged revisions 162656 via svnmerge from file1-3/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r162656 | file | 2008-12-10 12:06:59 -0400 (Wed, 10 Dec 2008) | 13 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@162657 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09Merged revisions 162205 via svnmerge from file1-2/+6
https://origsvn.digium.com/svn/asterisk/trunk ................ r162205 | file | 2008-12-09 15:48:35 -0400 (Tue, 09 Dec 2008) | 14 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@162206 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09Merged revisions 162197 via svnmerge from file1-4/+4
https://origsvn.digium.com/svn/asterisk/trunk ................ r162197 | file | 2008-12-09 15:08:39 -0400 (Tue, 09 Dec 2008) | 11 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@162201 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-04Merged revisions 161014 via svnmerge from jpeeler1-1/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r161014 | jpeeler | 2008-12-04 12:32:20 -0600 (Thu, 04 Dec 2008) | 17 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@161015 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-03Merged revisions 154060 via svnmerge from tilghman1-3/+3
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: http://svn.digium.com/svn/asterisk/branches/1.6.0@154062 f38db490-d61c-443f-a65b-d21fe96a405b
2008-10-09Merged revisions 147807 via svnmerge from murf1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r147807 | murf | 2008-10-09 08:17:33 -0600 (Thu, 09 Oct 2008) | 15 lines (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: http://svn.digium.com/svn/asterisk/branches/1.6.0@147809 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-17Merged revisions 138476 via svnmerge from seanbright1-3/+3
https://origsvn.digium.com/svn/asterisk/trunk ........ r138476 | seanbright | 2008-08-17 09:40:36 -0400 (Sun, 17 Aug 2008) | 7 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@138477 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-06Merged revisions 136063 via svnmerge from mmichelson1-1/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r136063 | mmichelson | 2008-08-06 10:59:29 -0500 (Wed, 06 Aug 2008) | 24 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@136064 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-09Merged revisions 129437 via svnmerge from mmichelson1-4/+5
https://origsvn.digium.com/svn/asterisk/trunk ................ r129437 | mmichelson | 2008-07-09 14:40:30 -0500 (Wed, 09 Jul 2008) | 21 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@129438 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-08Merged revisions 129045 via svnmerge from bbryant1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ........ r129045 | bbryant | 2008-07-08 11:40:28 -0500 (Tue, 08 Jul 2008) | 7 lines 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: http://svn.digium.com/svn/asterisk/branches/1.6.0@129046 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-26Merged revisions 125277 via svnmerge from tilghman1-1/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r125277 | tilghman | 2008-06-26 06:02:11 -0500 (Thu, 26 Jun 2008) | 15 lines Merged revisions 125276 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r125276 | tilghman | 2008-06-26 06:01:21 -0500 (Thu, 26 Jun 2008) | 7 lines Check for rtcp structure before trying to delete schedule. (closes issue #12872) Reported by: destiny6628 Patches: 20080621__bug12872.diff.txt uploaded by Corydon76 (license 14) Tested by: destiny6628 ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@125278 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-14Merged revisions 116469 via svnmerge from russell1-4/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r116469 | russell | 2008-05-14 16:40:43 -0500 (Wed, 14 May 2008) | 12 lines Merged revisions 116463 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r116463 | russell | 2008-05-14 16:32:00 -0500 (Wed, 14 May 2008) | 4 lines Add ast_assert(), which can be used to handle fatal errors. It is only compiled in if dev-mode is enabled, and only aborts if DO_CRASH is defined. (inspired by issue #12650) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@116470 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-14Merged revisions 114101 via svnmerge from file1-1/+0
https://origsvn.digium.com/svn/asterisk/trunk ................ r114101 | file | 2008-04-14 10:53:33 -0300 (Mon, 14 Apr 2008) | 12 lines Merged revisions 114100 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r114100 | file | 2008-04-14 10:52:49 -0300 (Mon, 14 Apr 2008) | 4 lines Don't change the SSRC when a new source comes into play, this might happen quite often and depending on the remote side... they might not like this. (closes issue #12353) Reported by: dimas ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@114102 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-10Merged revisions 114024 via svnmerge from file1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ........ r114024 | file | 2008-04-10 10:45:45 -0300 (Thu, 10 Apr 2008) | 4 lines Fix spelling of existent in a few places. (closes issue #12409) Reported by: candlerb ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@114025 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-01Merged revisions 112210 via svnmerge from file1-3/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r112210 | file | 2008-04-01 15:06:13 -0300 (Tue, 01 Apr 2008) | 12 lines Merged revisions 112209 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r112209 | file | 2008-04-01 15:02:43 -0300 (Tue, 01 Apr 2008) | 4 lines Disable Packet2Packet bridging when we need to feed DTMF frames into the core. Some implementations do not like how we switch between things. (closes issue #12212) Reported by: bamby ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@112211 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-19Merged revisions 110020 via svnmerge from file1-2/+2
https://origsvn.digium.com/svn/asterisk/trunk ................ r110020 | file | 2008-03-19 15:25:33 -0300 (Wed, 19 Mar 2008) | 14 lines Merged revisions 110019 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r110019 | file | 2008-03-19 15:20:28 -0300 (Wed, 19 Mar 2008) | 6 lines Make sure that the mark bit does not incorrectly cause video frame timestamps to be calculated as if they are audio frames. (closes issue #11429) Reported by: sperreault Patches: 11429-frametype.diff uploaded by qwell (license 4) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@110021 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-18Merged revisions 109390 via svnmerge from file1-0/+3
https://origsvn.digium.com/svn/asterisk/trunk ................ r109390 | file | 2008-03-18 12:08:09 -0300 (Tue, 18 Mar 2008) | 11 lines Merged revisions 109386 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r109386 | file | 2008-03-18 11:58:39 -0300 (Tue, 18 Mar 2008) | 3 lines Put a maximum limit on the number of payloads accepted, and also make sure a given payload does not exceed our maximum value. (AST-2008-002) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@109392 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-07Merged revisions 106607 via svnmerge from tilghman1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r106607 | tilghman | 2008-03-07 09:22:34 -0600 (Fri, 07 Mar 2008) | 11 lines Merged revisions 106606 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r106606 | tilghman | 2008-03-07 09:20:52 -0600 (Fri, 07 Mar 2008) | 3 lines Properly initialize rtp->schedid (Closes issue #12154) ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@106608 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-07Merged revisions 106501 via svnmerge from russell1-1/+7
https://origsvn.digium.com/svn/asterisk/trunk ........ r106501 | russell | 2008-03-06 18:24:58 -0600 (Thu, 06 Mar 2008) | 28 lines Merge changes from team/russell/g722-sillyness ... Fix a number of other places where the number of samples in a G722 frame was not properly handled because of various reasons. main/rtp.c: - When a G722 frame is read from the smoother, the number of samples in the frame must be divided by 2 before being sent out over the network. Even though G722 is 16 kHz, an error in some previous spec has made it so that we have to list the number of samples such as if it was 8 kHz. main/file.c: - When scheduling the next time to expect a frame, take into account that the format of the file we're reading from may not be 8 kHz. codecs/codec_g722.c: - When converting from G722 to slinear, g722_decode() expects its samples parameter to be in the silly (real samples / 2) format. Make it so. - When converting from slinear to G722, properly set the number of samples in the frame to be the number of bytes of output * 2. formats/format_pcm.c: - This format module handles G722, among a number of other formats. However, the read() and seek() functions did not account for the fact that G722 has 2 samples per byte. (closes issue #12130, reported by rickross, patched by me) ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@106502 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-06Merged revisions 106239 via svnmerge from russell1-2/+4
https://origsvn.digium.com/svn/asterisk/trunk ................ r106239 | file | 2008-03-05 16:43:22 -0600 (Wed, 05 Mar 2008) | 12 lines Merged revisions 106235 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r106235 | file | 2008-03-05 18:32:10 -0400 (Wed, 05 Mar 2008) | 4 lines Add a control frame to indicate the source of media has changed. Depending on the underlying technology it may need to change some things. (closes issue #12148) Reported by: jcomellas ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@106318 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-06Merged revisions 105933 via svnmerge from russell1-1/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r105933 | russell | 2008-03-04 19:54:16 -0600 (Tue, 04 Mar 2008) | 13 lines Merged revisions 105932 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105932 | russell | 2008-03-04 19:52:18 -0600 (Tue, 04 Mar 2008) | 5 lines Fix a bug that I just noticed in the RTP code. The calculation for setting the len field in an ast_frame of audio was wrong when G.722 is in use. The len field represents the number of ms of audio that the frame contains. It would have set the value to be twice what it should be. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@106310 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-06Merged revisions 105840 via svnmerge from russell1-5/+5
https://origsvn.digium.com/svn/asterisk/trunk ........ r105840 | tilghman | 2008-03-04 17:04:29 -0600 (Tue, 04 Mar 2008) | 2 lines Whitespace changes only ........ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@106306 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-06Merged revisions 105677 via svnmerge from russell1-0/+1
https://origsvn.digium.com/svn/asterisk/trunk ................ r105677 | file | 2008-03-04 12:11:38 -0600 (Tue, 04 Mar 2008) | 10 lines Merged revisions 105676 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105676 | file | 2008-03-04 14:10:34 -0400 (Tue, 04 Mar 2008) | 2 lines In addition to setting the marker bit let's change our ssrc so they know for sure it is a different source. ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@106300 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-06Merged revisions 105675 via svnmerge from russell1-0/+15
https://origsvn.digium.com/svn/asterisk/trunk ................ r105675 | file | 2008-03-04 12:08:42 -0600 (Tue, 04 Mar 2008) | 16 lines Merged revisions 105674 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r105674 | file | 2008-03-04 14:05:28 -0400 (Tue, 04 Mar 2008) | 8 lines When a new source of audio comes in (such as music on hold) make sure the marker bit gets set. (closes issue #10355) Reported by: wdecarne Patches: 10355.diff uploaded by file (license 11) (closes issue #11491) Reported by: kanderson ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@106299 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-27Fix T38 passthrough regression introduced by state changes.file1-2/+4
(closes issue #12078) Reported by: dimas Patches: v1-12078.patch uploaded by dimas (license 88) (closes issue #12074) Reported by: Ivan git-svn-id: http://svn.digium.com/svn/asterisk/trunk@104533 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-18Merged revisions 103780 via svnmerge from tilghman1-0/+8
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r103780 | tilghman | 2008-02-18 11:31:52 -0600 (Mon, 18 Feb 2008) | 9 lines When a SIP channel is being auto-destroyed, it's possible for it to still be in bridge code. When that happens, we crash. Delay the RTP destruction until the bridge is ended. (closes issue #11960) Reported by: norman Patches: 20080215__bug11960__2.diff.txt uploaded by Corydon76 (license 14) Tested by: norman ........ git-svn-id: http://svn.digium.com/svn/asterisk/trunk@103781 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-11Just some minor coding style cleanup...file1-2/+2
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@103318 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-20 05:59:47 +0000