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/branches/1.4@161013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@136062 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.4@129436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@114550 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@105932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@103780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@100465 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@98943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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: https://origsvn.digium.com/svn/asterisk/branches/1.4@89630 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: wdecarne
Now that we pass through RTP timestamp information we need to make the allowed timestamp skew considerably less. There are situations where a source may change and due to the timestamp difference the receiver will experience an audio gap since we did not indicate by setting the marker bit that the source changed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@78172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
