aboutsummaryrefslogtreecommitdiffstats
path: root/main/rtp.c
AgeCommit message (Collapse)AuthorFilesLines
2009-05-28Allow for media to arrive from an alternate source when responding to a ↵mmichelson1-5/+21
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.4@197588 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-18Fix a bug where the codecs of the called party leg were not properly sent ↵file1-1/+2
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.4@195095 f38db490-d61c-443f-a65b-d21fe96a405b
2009-05-13Fix RFC2833 issues with DTMF getting duplicated and with duration wrapping over.file1-23/+58
(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.4@194208 f38db490-d61c-443f-a65b-d21fe96a405b
2009-03-05Fix problems when RTP packet frame size is changedkpfleming1-7/+41
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.4@180372 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-24Only set dtmfcount on BEGIN, and ensure it gets reset to 0 properly.russell1-3/+3
(issue #14460) Reported by: moliveras Tested by: russell git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178373 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-23Fix infinite DTMF when a BEGIN is received without an END.russell1-10/+3
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.4@178141 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-12Don't send DTMF for infinite time if we do not receive an END event.russell1-0/+15
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.4@175124 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-12Revert RTP changes for continuation of DTMF. Proxy commit by russell via SMS.file1-15/+0
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@174997 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-12Clear out the current event after forcing the end of a digitrussell1-1/+4
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@174986 f38db490-d61c-443f-a65b-d21fe96a405b
2009-02-11Fixify infinite DTMF in the case that no RFC2833 END event is ever receivedrussell1-0/+12
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@174985 f38db490-d61c-443f-a65b-d21fe96a405b
2009-01-22Don't crash if RTCP is not enabled on an RTP structure but statistics are ↵file1-6/+6
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.4@170239 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-18Only care about a compatible codec for early bridging if we are actually ↵file1-3/+2
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.4@165591 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-10Increment the sequence number on the end packets for RFC2833. After reading ↵file1-3/+3
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.4@162653 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09Make sure that the timestamp for DTMF is not the same as the previous voice ↵file1-2/+6
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.4@162204 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-09Take video into account when early bridging RTP.file1-4/+4
(closes issue #13535) Reported by: davidw git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@162188 f38db490-d61c-443f-a65b-d21fe96a405b
2008-12-04(closes issue #13835)jpeeler1-1/+3
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.4@161013 f38db490-d61c-443f-a65b-d21fe96a405b
2008-11-03Remove the potential for a division by zero error.tilghman1-1/+1
(Closes issue #13810) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@154060 f38db490-d61c-443f-a65b-d21fe96a405b
2008-09-17Allow for "G.729" if offered in an SDP even thoughmmichelson1-0/+1
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: http://svn.digium.com/svn/asterisk/branches/1.4@143337 f38db490-d61c-443f-a65b-d21fe96a405b
2008-08-06Since adding the AST_CONTROL_SRCUPDATE frame type,mmichelson1-1/+3
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.4@136062 f38db490-d61c-443f-a65b-d21fe96a405b
2008-07-09Fix a problem where inbound rfc2833 audio would be sent to the mmichelson1-4/+5
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.4@129436 f38db490-d61c-443f-a65b-d21fe96a405b
2008-06-26Check for rtcp structure before trying to delete schedule.tilghman1-1/+3
(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.4@125276 f38db490-d61c-443f-a65b-d21fe96a405b
2008-05-14Add ast_assert(), which can be used to handle fatal errors. It is only compiledrussell1-4/+2
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.4@116463 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-22I thought I was going to be able to leave 1.4 alone, but that was not the case.russell1-4/+15
I ran into some problems with G.722 in 1.4, so I have merged in all of the fixes in this area that I have made in trunk/1.6.0, and things are happy again. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@114550 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-14Don't change the SSRC when a new source comes into play, this might happen ↵file1-1/+0
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.4@114100 f38db490-d61c-443f-a65b-d21fe96a405b
2008-04-01Disable Packet2Packet bridging when we need to feed DTMF frames into the ↵file1-3/+3
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.4@112209 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-19Make sure that the mark bit does not incorrectly cause video frame ↵file1-2/+2
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.4@110019 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-18Put a maximum limit on the number of payloads accepted, and also make sure a ↵file1-0/+3
given payload does not exceed our maximum value. (AST-2008-002) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@109386 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-07Properly initialize rtp->schedidtilghman1-0/+1
(Closes issue #12154) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@106606 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-05Add a control frame to indicate the source of media has changed. Depending ↵file1-2/+4
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.4@106235 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-05Fix a bug that I just noticed in the RTP code. The calculation for setting therussell1-1/+1
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.4@105932 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-04In addition to setting the marker bit let's change our ssrc so they know for ↵file1-0/+1
sure it is a different source. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@105676 f38db490-d61c-443f-a65b-d21fe96a405b
2008-03-04When a new source of audio comes in (such as music on hold) make sure the ↵file1-0/+14
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.4@105674 f38db490-d61c-443f-a65b-d21fe96a405b
2008-02-18When a SIP channel is being auto-destroyed, it's possible for it to still betilghman1-0/+8
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/branches/1.4@103780 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-27When deleting a task from the scheduler, ignoring the return value couldtilghman1-18/+6
possibly cause memory to be accessed after it is freed, which causes all sorts of random memory corruption. Instead, if a deletion fails, wait a bit and try again (noting that another thread could change our taskid value). (closes issue #11386) Reported by: flujan Patches: 20080124__bug11386.diff.txt uploaded by Corydon76 (license 14) Tested by: Corydon76, flujan, stuarth` git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@100465 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-16Replace current spy architecture with backport of audiohooks. This should ↵file1-2/+2
take care of current known spy issues. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98972 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-16Add two more SDP names for ulaw and alaw.file1-0/+2
(closes issue #11777) Reported by: tootai git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98958 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-15Commit a fix for some memory access errors pointed out by the valgrind2.txtrussell1-2/+2
output on issue #11698. The issue here is that it is possible for an instance of a translator to get destroyed while the frame allocated as a part of the translator is still being processed. Specifically, this is possible anywhere between a call to ast_read() and ast_frame_free(), which is _a lot_ of places in the code. The reason this happens is that the channel might get masqueraded during this time. During a masquerade, existing translation paths get destroyed. So, this patch fixes the issue in an API and ABI compatible way. (This one is for you, paravoid!) It changes an int in ast_frame to be used as flag bits. The 1 bit is still used to indicate that the frame contains timing information. Also, a second flag has been added to indicate that the frame came from a translator. When a frame with this flag gets released and has this flag, a function is called in translate.c to let it know that this frame is doing being processed. At this point, the flag gets cleared. Also, if the translator was requested to be destroyed while its internal frame still had this flag set, its destruction has been deffered until it finds out that the frame is no longer being processed. Admittedly, this feels like a hack. But, it does fix the issue, and I was not able to think of a better solution ... git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98943 f38db490-d61c-443f-a65b-d21fe96a405b
2008-01-11If the incoming RTP stream changes codec force the bridge to break if the ↵file1-0/+10
other side does not support it. (closes issue #11729) Reported by: tsearle Patches: new_codec_patch_udiff.patch uploaded by tsearle (license 373) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@98325 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-10Add G729A as another possible payload name for G729. Some devices use this ↵file1-0/+1
instead of G729, which is perfectly normal since the payload number itself is defined and can't be used by anything else so the name doesn't matter that much. (closes issue #11483) Reported by: revolution Patches: rtp.diff uploaded by revolution (license 346) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@92204 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-07At the end of a call, when we're reporting, RTCP may already be partially ↵tilghman1-8/+22
torn down, so check for NULL dereference Reported by: blitzrage Patch by: tilghman (Closes issue #11450) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@91637 f38db490-d61c-443f-a65b-d21fe96a405b
2007-12-03Do not create a smoother for G723.1 frames, they need to be left alone to ↵file1-1/+1
their native 20/24 byte size. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@90588 f38db490-d61c-443f-a65b-d21fe96a405b
2007-11-27If we get a codec offer using a well-known payload type, but using it for ↵oej1-3/+16
another codec that we don't know, Asterisk did not remove that codec from the list. With this patch, we remove the codec from audio and video rtp objects and deny it ever existed. Thanks to lasse for testing. (closes issue #11376) Reported by: lasse Patches: bug11376.txt uploaded by oej (license 306) Tested by: lasse git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@89630 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-15Bring both DTMF begin and end frames up through to the core for DTMF feature ↵file1-4/+4
handling. (closes issue #10826) Reported by: dimas git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85559 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-15If Monitor or a spy was added to a P2P or native bridged channel bring the ↵file1-2/+4
channel back to the generic bridging core so the monitor or spy operations work. (closes issue #10943) Reported by: julianjm git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85552 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-08Only update codec information if the channel has a technology private structure.file1-2/+2
(issue #10915) Reported by: ramonpeek git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85057 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-08Update codec information as well as address when doing hold reinvites.file1-0/+5
(issue #10868) Reported by: mavince git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@85023 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-05Update the remembered RTP peer information when putting an endpoint on hold ↵file1-0/+5
or taking it off hold so that the RTP stack does not initiate a needless reinvite. (closes issue #10868) Reported by: mavince git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84818 f38db490-d61c-443f-a65b-d21fe96a405b
2007-10-03When an RFC 2833 event is sent that we don't recognize, ignore it, don't ↵tilghman1-0/+4
queue a NULL digit (closes issue #10877) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@84581 f38db490-d61c-443f-a65b-d21fe96a405b
2007-09-21gcc 4.2 has a new set of warnings dealing with cosnt pointers. This set ofrussell1-9/+9
changes gets all of Asterisk (minus chan_alsa for now) to compile with gcc 4.2. (closes issue #10774, patch from qwell) git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@83432 f38db490-d61c-443f-a65b-d21fe96a405b
2007-08-27(closes issue #10562)file1-1/+1
Reported by: idkpmiller Correct jitter value output in the CLI to be as expected. git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@80974 f38db490-d61c-443f-a65b-d21fe96a405b
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-09 11:42:30 +0000