| Age | Commit message (Collapse) | Author |
|---|
|
This patch adds pass through support for Opus and VP8. That includes:
* Format attribute negotiation for Opus. Note that unlike some other codecs,
the draft RFC specifies having spaces delimiting the attributes in addition
to ';', so you have "attra=X; attrb=Y". This broke the attribute parsing in
chan_sip, so a small tweak was also included in this patch for that.
* A format attribute negotiation module for Opus, res_format_attr_opus
* Fast picture update for VP8. Since VP8 uses a different RTCP packet number
than FIR, this really is specific to VP8 at this time.
Note that the format attribute negotiation in res_pjsip_sdp_rtp was written
by mjordan. The rest of this patch was written completely by Lorenzo Miniero.
Review: https://reviewboard.asterisk.org/r/2723/
(closes issue ASTERISK-21981)
Reported by: Tzafrir Cohen
patches:
asterisk_opus+vp8_passthrough_20130718.patch uploaded by lminiero (License 6518)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396857 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch does the following:
* It merges Jaco Kroon's patch from ASTERISK-20754, which provides channel
information in the RTCP events. Because Stasis provides a cache, Jaco's
patch was modified to pass the channel uniqueid to the RTP layer as
opposed to a pointer to the channel. This has the following benefits:
(1) It keeps the RTP engine 'clean' of references back to channels
(2) It prevents circular dependencies and other potential ref counting issues
* The RTP engine now allows any RTP implementation to raise RTCP messages.
Potentially, other implementations (such as res_rtp_multicast) could also
raise RTCP information. The engine provides structs to represent RTCP headers
and RTCP SR/RR reports.
* Some general refactoring in res_rtp_asterisk was done to try and tame the
RTCP code. It isn't perfect - that's *way* beyond the scope of this work -
but it does feel marginally better.
* A few random bugs were fixed in the RTCP statistics. (Example: performing an
assignment of a = a is probably not correct)
* We now raise RTCP events for each SR/RR sent/received. Previously we wouldn't
raise an event when we sent a RR report.
Note that this work will be of use to others who want to monitor call quality
or build modules that report call quality statistics. Since the events are now
moving across the Stasis message bus, this is far easier to accomplish. It is
also a first step (though by no means the last step) towards getting Olle's
pinefrog work incorporated.
Again: note that the patch by Jaco Kroon was modified slightly for this work;
however, he did all of the hard work in finding the right places to set the
channel in the RTP engine across the channel drivers. Much thanks goes to Jaco
for his hard work here.
Review: https://reviewboard.asterisk.org/r/2603/
(closes issue ASTERISK-20574)
Reported by: Jaco Kroon
patches:
asterisk-rtcp-channel.patch uploaded by jkroon (License 5671)
(closes issue ASTERISK-21471)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When we send out a CN packet (for instance, in the case of using rtpkeepalives),
we are not setting the payload code properly. Also, we are setting the marker
bit when we shouldn't be according to RFC 3389, section 4.
AST_RTP_CN is not defined by AST_FORMAT codes. Therefore, we should be using
ast_rtp_codecs_payload_code() rather than ast_rtp_codecs_payload_lookup().
11 and trunk already use the appropriate function.
* In 1.8, use ast_rtp_codecs_payload_code()
* Remove the setting of the marker bit
* Fix the debug message by incrementing the seqno after the debug message is set
in order to display the correct seqno that was sent out
(closes issue ASTERISK-21246)
Reported by: Peter Katzmann
Tested by: Peter Katzmann, Michael L. Young
Patches:
asterisk-21246-rtp-cng-payload-error_1.8_v2.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2500/
........
Merged revisions 388111 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 388112 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388113 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In certain situations, when the RTP engine goes to send a DTMF end digit
it may be in a situation where the remote address is no longer available,
or the digit that was supposed to be sent is invalid. In such cases, we
need to clear the RTP counters appropriately. Otherwise, when the RTP
source is set again, we'll continue to think that we're in the middle of
sending a DTMF digit, which can confuse the remote party (signficantly).
(closes issue ASTERISK-21522)
Reported by: Corey Farrell
patches:
rtp_dtmf_process_end.patch uploaded by Corey Farrell (License 5909)
........
Merged revisions 387213 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 387216 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387220 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When res_rtp_asterisk.c was altered to avoid attempting to apply
unprotect algorithms to non-audio RTP packets, the test used was
incorrect. This caused the audio packets to not be decrypted and
resulted in loud white noise on the other endpoint (or both endpoints
depending on the call legs involved). The test now properly checks the
version field in the RTP header to ensure that RTP and RTCP are
decrypted while other types of packets are not.
(closes issue ASTERISK-21323)
Reported by: andrea
Tested by: Kinsey Moore, andrea, John Bigelow
Patches:
whitenoise_fix.diff uploaded by Kinsey Moore
........
Merged revisions 384048 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 384049 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Not informing the RTP engine of the instance data creates shrapnel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383008 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
ICE/STUN/TURN support in res_rtp_asterisk is also now optional.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382900 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Often, Asterisk may realize that a change in the source of an RTP stream is
about to occur and ask that the RTP engine reset it's lock on the current RTP
source. In certain scenarios, it may take awhile for the new remote system to
send RTP packets, while the old remote system may continue providing RTP during
that time period. This causes Asterisk to re-lock onto the old source, thereby
rejecting the new source when the old source stops sending RTP and the new
source begins.
This patch prevents that by having a constant secondary, 'secret' probation
mode enabled when an RTP source has been chosen. RTP packets from other sources
are always considered, but never chosen unless the current RTP source stops
sending RTP.
Review: https://reviewboard.asterisk.org/r/2364
(closes issue AST-1124)
Reported by: John Bigelow
Tested by: John Bigelow
(closes issue AST-1125)
Reported by: John Bigelow
Tested by: John Bigelow
........
Merged revisions 382573 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
media can and will come from different places.
........
Merged revisions 382298 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If the end result of the ICE negotiation resulted in the path for media
changing it was possible for the strictrtp code to discard the RTP packets.
This change causes strictrtp to enter learning mode once again when the
ICE negotiation has completed successfully.
........
Merged revisions 382296 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This was causing build failures against external libraries that happened to use
them, unless silly hacks were added to the modules that used those headers.
Review: https://reviewboard.asterisk.org/r/2359/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382292 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In r370252 for ASTERISK-18404, Asterisk's handling of RTP was modified to
better account for out of order RTP packets. This was accomplished by using the
RTP timestamp and sequence number to check for out of order packets. However,
when a SSRC change occurs, the timestamp and sequence number will no longer
have any relation to the previously received packets. The variables tracking
the timestamp and sequence number therefore have to be reset.
(closes issue ASTERISK-20906)
Reported by: Eelco Brolman
patches:
dtmf_on_hold.patch uploaded by Eelco Brolman (license #6442)
........
Merged revisions 378967 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378984 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue AST-1036)
Reported by: jbigelow
........
Merged revisions 378553 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378555 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377035 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Found a large amount of missing {} in the code before patching in another branch
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
is disabled by default.
With ICE support enabled in chan_sip and a large number of interfaces on the system it was
possible for the produced SDP to be truncated due to some fixed size buffers. These buffers
have now been changed so they will dynamically grow as needed.
ICE support is now also enabled by default in res_rtp_asterisk to provide a smoother experience
for chan_motif users where it is required. To maintain the previous behavior in chan_sip it is
no longer enabled by default there.
(closes issue ASTERISK-20643)
Reported by: coopvr
........
Merged revisions 376130 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376131 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Remove the "RTP Read too short" warning for RTP keepalives. Remove the
the warning about the application delimiter switch from pipe to comma.
(You should've done this by now.) Make cdr_odbc report more when an
insert fails. Make chan_sip warn less when the peer wants SRTP (and we
don't) or sends a zero port to disable a media type.
Review: https://reviewboard.asterisk.org/r/2167
(closes issue ASTERISK-20538)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Since there are a number of legacy devices out there that fail to handle ICE
candidates properly (which is a nice way of saying something much uglier),
disable it by default.
Support for ICE candidates can be enabled in rtp.conf using the icesupport
setting.
........
Merged revisions 374676 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374677 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch removes the turnport configuration property and changes the
turnaddr property to be a combined host[:port] configuration string. The
patch also modifies the documentation in the example configuration to
reflect the property changes and adds some additional text indicating how
the STUN port is configured.
(closes issue ASTERISK-20344)
Reported by: beagles
Tested by: beagles
Review: https://reviewboard.asterisk.org/r/2111/
........
Merged revisions 373403 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373404 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
As mentioned on the review for this, WebRTC has moved towards choosing
DTLS-SRTP as the mechanism for key exchange for SRTP. This commit adds
support for this but makes it available for normal SIP clients as well.
Testing has been done to ensure that this introduces no regressions with
existing behavior and also that it functions as expected.
Review: https://reviewboard.asterisk.org/r/2113/
........
Merged revisions 373229 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373234 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Removes "res_rtp_asterisk.c:706: warning: dereferencing type-punned pointer
will break strict-aliasing rules" warning from the build on 32-bit platforms.
The problem is that 'size' was referenced aliased to both (pj_size_t *) and
(pj_ssize_t *). Now just make a copy of size that is the right type so there
isn't any pointer aliasing happening.
It also adds comments and asserts regarding what looks like an inappropriate
use of pj_sock_sendto, but is actually totally fine.
(closes issue ASTERISK-20368)
Reported by: Shaun Ruffell
Tested by: Michael L. Young
Patches:
0001-res_rtp_asterisk-Eliminate-type-punned-pointer-build.patch uploaded by Shaun Ruffell (license 5417)
slightly modified by David M. Lee.
........
Merged revisions 372777 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
r372327 | rmudgett | 2012-09-05 12:33:11 -0500 (Wed, 05 Sep 2012) | 15 lines
Fix RTP/RTCP read error message confusion.
The RTP/RTCP read error message can report "fail: success" when the
read failure is because of an ICE failure.
* Changed __rtp_recvfrom() to generate a PJ ICE message when ICE fails.
* Changed RTP/RTCP read error message to indicate an unspecified error
when errno is zero.
(closes issue ASTERISK-20288)
Reported by: Joern Krebs
Patches:
jira_asterisk_20288_err_msg.patch (license #5621) patch uploaded by rmudgett (modified)
........
r372328 | rmudgett | 2012-09-05 12:35:20 -0500 (Wed, 05 Sep 2012) | 1 line
Fix coding guidelines issue with a recent commit.
........
Merged revisions 372327-372328 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The previous fix still would look in the static_RTP_PT table, which
is inappropriate since we specifically want to find a codec that has
been negotiated.
(closes issue ASTERISK-20296)
reported by NITESH BANSAL
Patches:
codec_negotiation.patch Uploaded by NITESH BANSAL (License #6418)
........
Merged revisions 372311 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372319 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 372266 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372267 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In Asterisk 1.4+, a fix was put in place to increment the sequence number for
retransmitted DTMF end packets. With the introduction of the RTP engine API in
1.8, the sequence number was no longer being incremented. This patch fixes this
regression as well as cleans up a few lines that were not doing anything.
(closes issue ASTERISK-20295)
Reported by: Nitesh Bansal
Tested by: Michael L. Young
Patches:
01_rtp_event_seq_num.patch uploaded by Nitesh Bansal (license 6418)
asterisk-20295-dtmf-fix-cleanup.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2083/
........
Merged revisions 372185 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 372198 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 372199 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
A change for Asterisk 11 caused a check for failure to incorrectly check the return
value. This resulted in the possibility of transmitting media that a party had not
negotiated. If this media happened to be G.729, then this could potentially result
in one-way audio if no G.729 translators are installed.
(closes issue ASTERISK-20296)
reported by NITESH BANSAL
........
Merged revisions 372118 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
pj_thread_register() takes a parameter of type pj_thread_desc.
It was assumed that pj_thread_register either used this item
temporarily or made a copy of it. Unfortunately, all it does is
keep a pointer to the structure in thread-local storage. This
means that if our pj_thread_desc goes out of scope, then pjlib
will be referencing bogus data quite often, most commonly on
operations involving a pj_mutex_t.
In our case, our pj_thread_desc was on the stack and went out
of scope very shortly after registering our thread with pjlib.
With this change, the pj_thread_desc is stored in thread-local
storage so the pointer that pjlib keeps in thread-local storage
will reference legitimate memory.
(closes issue ASTERISK-20237)
reported by Jeremy Pepper
Patches:
ASTERISK-20237.patch uploaded by Mark Michelson (license #5049)
Tested by Jeremy Pepper
........
Merged revisions 371571 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371572 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
While building up a new install to test chan_motif, I ran into a failure
due to icesupport being disabled. This was due to me not having an
rtp.conf. It was intended in the code for it to be enabled by default,
but it was only applied if rtp.conf existed.
This patch updates res_rtp_asterisk to be consistent in how it handles
defaults. A few options didn't have their default values set globally,
including icesupport. They are now set and icesupport is enabled by
default, even if you do not have an rtp.conf.
........
Merged revisions 371425 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371428 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
storing only the payloads present and in use instead of every possible one.
Review: https://reviewboard.asterisk.org/r/2052/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370832 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370420 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
by build slave.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370419 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
and add support for disabling ICE on a per-peer basis.
(closes issue ASTERISK-20088)
Reported by: wimpy
Review: https://reviewboard.asterisk.org/r/2044/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The current implementation of RFC 2833 DTMF handling in res_rtp_asterisk will,
if a packet arrives out of order, drop the packet. This is to prevent
duplicate ton generation in the Asterisk core. Since the RTP layer does not
buffer data itself, this is the only option the RTP layer currently has for
handling packets that arrive out of order.
For the most part, this doesn't matter. For a particular digit, so long as a
BEGIN packet arrives before the first END packet, the digit will be produced.
If subsequent BEGIN packets arrive interleaved with the ENDs, they will be
dropped; likewise, if the BEGIN or END packets themselves are out of order,
those packets are dropped but sufficient information is conveyed to the
Asterisk core to produce the appropriate digit.
For certain sequences of DTMF packets - most notably when, for a particular
digit, an END packet arrives before any BEGIN packet for that digit - this
is a real problem. When an END arrives before any BEGINs, the END packet is
dropped - but at the same time, it causes subsequent BEGIN packets for that
digit to be ignored. When the next in order END packet arrives, it too is
dropped - Asterisk believes that there was no initial BEGIN.
The solution this patch provides is to trust the END packet to convey the
information needed for the Asterisk core to produce the DTMF digit. If we
receive an END packet, and it:
* Has a timestamp greater then the last timestamp received from an END
packet
* Does not have the same sequence number as the last received sequence
number (and is thus not an END packet retransmission)
Then we send the END frame up to the Asterisk core. It contains enough
DTMF information for Asterisk to produce the digit.
On the other hand, if we receive a BEGIN or continuation packet that occurs
with a timestamp equal to or less then the last END timestamp, then we've
received something out of order - but we already have received enough
information to produce the digit. These packets are dropped.
Much thanks goes to Olle Johansson (oej) for providing the idea for this
solution.
Review: https://reviewboard.asterisk.org/r/2033/
(closes issue ASTERISK-18404)
Reported by: Stephane Chazelas
Tested by: Matt Jordan
........
Merged revisions 370252 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 370271 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370272 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
immediately destroying the ICE session.
The initial ICE connectivity check is scheduled as a timer item that is to be executed immediately. It is possible for this timer item to start executing while the ICE session it is working on is destroyed. To reduce the chance of this any timer items that need to be immediately executed will be executed within the thread that has started the initial ICE connectivity check.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370177 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This adds legacy STUN support for RTCP sockets, adds RTCP candidates to the Google transport information, and adds required codec parameters.
(closes issue ASTERISK-20106)
Reported by: Malcolm Davenport
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369864 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
code is in use.
The STUN packets should *not* be blocked by strict RTP.
(closes issue ASTERISK-20102)
Reported by: Malcolm Davenport
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369817 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
and don't do multiple ICE connectivity checks at once.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369520 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Review: https://reviewboard.asterisk.org/r/1891/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369517 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch addresses a number of memory leaks in a variety of modules that were
found by a static analysis tool. A brief summary of the changes:
* app_minivm: free ast_str objects on off nominal paths
* app_page: free the ast_dial object if the requested channel technology
cannot be appended to the dialing structure
* app_queue: if a penalty rule failed to match any existing rule list
names, the created rule would not be inserted and its memory
would be leaked
* app_read: dispose of the created silence detector in the presence of
off nominal circumstances
* app_voicemail: dispose of an allocated unique ID field for MWI event
un-subscribe requests in off nominal paths; dispose of
configuration objects when using the secret.conf option
* chan_dahdi: dispose of the allocated frame produced by ast_dsp_process
* chan_iax2: properly unref peer in CLI command "iax2 unregister"
* chan_sip: dispose of the allocated frame produced by sip_rtp_read's
call of ast_dsp_process; free memory in parse unit tests
* func_dialgroup: properly deref ao2 object grhead in nominal path of
dialgroup_read
* func_odbc: free resultset in off nominal paths of odbc_read
* cli: free match_list in off nominal paths of CLI match completion
* config: free comment_buffer/list_buffer when configuration file load
is unchanged; free the same buffers any time they were
created and config files were processed
* data: free XML nodes in various places
* enum: free context buffer in off nominal paths
* features: free ast_call_feature in off nominal paths of applicationmap
config processing
* netsock2: users of ast_sockaddr_resolve pass in an ast_sockaddr struct
that is allocated by the method. Failures in
ast_sockaddr_resolve could result in the users of the method
not knowing whether or not the buffer was allocated. The
method will now not allocate the ast_sockaddr struct if it
will return failure.
* pbx: cleanup hash table traversals in off nominal paths; free
ignore pattern buffer if it already exists for the specified
context
* xmldoc: cleanup various nodes when we no longer need them
* main/editline: various cleanup of pointers not being freed before being
assigned to other memory, cleanup along off nominal paths
* menuselect/mxml: cleanup of value buffer for an attribute when that attribute
did not specify a value
* res_calendar*: responses are allocated via the various *_request method
returns and should not be allocated in the various
write_event methods; ensure attendee buffer is freed if no
data exists in the parsed node; ensure that calendar objects
are de-ref'd appropriately
* res_jabber: free buffer in off nominal path
* res_musiconhold: close the DIR* object in off nominal paths
* res_rtp_asterisk: if we run out of ports, close the rtp socket object and free
the rtp object
* res_srtp: if we fail to create the session in libsrtp, destroy the
temporary ast_srtp object
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922
........
Merged revisions 366880 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366881 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
CONSTANT_EXPRESSION_RESULT report.
These three all are in RTP code that attempts to print the number of sequence number cycles
in an RTCP RR report. The code was masking out the upper 16 bits and then shifting the number
right by 16 bits. This led to an all zero result in all cases. The fix is to do the shift without
the bit masking.
(issue ASTERISK-19649)
........
Merged revisions 365298 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365299 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365300 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch addresses a number of modules in resources that did not handle the
negative return value from function calls adequately. This includes:
* res_agi.c: if the result of the read function is a negative number,
indicating some failure, the result would instead be treated as the number
of bytes read. This patch now treats negative results in the same manner
as an end of file condition, with the exception that it also logs the
error code indicated by the return.
* res_musiconhold.c: if spawn_mp3 fails to assign a file descriptor to srcfd,
and instead assigns a negative value, that file descriptor could later be
passed to functions that require a valid file descriptor. If spawn_mp3 fails,
we now immediately retry instead of continuing in the logic.
* res_rtp_asterisk.c: if no codec can be matched between two RTP instances
in a peer to peer bridge, we immediately return instead of attempting to
use the codec payload type as an index to determine the appropriate negotiated
codec.
(issue ASTERISK-19655)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1863/
........
Merged revisions 362362 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362364 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362365 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Review: https://reviewboard.asterisk.org/r/1753/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Change the RTCP RR and SR generation code to convert Asterisk's internal jitter
statistics to be represented in RTP timestamp units based on the rate of the
codec in use instead of in seconds.
(closes issue ASTERISK-14530)
........
Merged revisions 351611 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 351612 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 351306 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 351308 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In order to better handle RTP sources with strictrtp enabled (which is now default in 10)
using the learning mode to figure out new sources when they change is handled by checking
for a number of consecutive (by sequence number) packets received to an rtp struct
based on a new configurable value called 'probation'. Also, during learning mode instead
of liberally accepting all packets received, we now reject packets until a clear source
has been determined.
Review: https://reviewboard.asterisk.org/r/1663/
........
Merged revisions 351287 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 351289 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
specified.
(closes issue ASTERISK-18693)
Reported by: Davide Dal Fra
Review: https://reviewboard.asterisk.org/r/1600/
Reviewed by: Walter Doekes
........
Merged revisions 346292 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 346293 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@346294 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Patch by: jkonieczny (modified)
ASTERISK-18490
........
Merged revisions 344330 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 344334 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@344335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
https://origsvn.digium.com/svn/asterisk/branches/10
................
r340971 | kmoore | 2011-10-14 15:50:37 -0500 (Fri, 14 Oct 2011) | 15 lines
Merged revisions 340970 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r340970 | kmoore | 2011-10-14 15:49:39 -0500 (Fri, 14 Oct 2011) | 8 lines
Quiet RTCP Receiver Reports during fax transmission
RTCP is now disabled for "inactive" RTP audio streams during SIP T.38 sessions.
The ability to disable RTCP streams in res_rtp_asterisk was missing, so this
code was added to support the bug fix.
(closes issue ASTERISK-18400)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@340972 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
