........
r409129 | jrose | 2014-02-27 13:19:02 -0600 (Thu, 27 Feb 2014) | 15 lines
res_rtp_asterisk: Fix checklist creating problems in ICE sessions
Prior to this patch, local candidate lists including SRFLX would fail to start
properly when building ICE candidate check lists. This patch fixes that problem
by making sure that each SRFLX candidate is associated with the proper
base address so that the check list can create matches properly.
This patch was written by jcolp. The issue will be left open to await testing
by the issue participants.
(issue ASTERISK-23213)
Reported by: Andrea Suisani
Review: https://reviewboard.asterisk.org/r/3256/
........
r409130 | jrose | 2014-02-27 13:38:10 -0600 (Thu, 27 Feb 2014) | 8 lines
res_rtp_asterisk: correct build error from r409129
Accidentally placed a declaration below functional code
(issue ASTERISK-23213)
Reported by: Andrea Suisani
Review: https://reviewboard.asterisk.org/r/3256/
........
Merged revisions 409129-409130 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 409131 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ast_rtp_ice_start if the ice session create check list failed, start check
was never initiated and ice_started was never set to true. Upon re-entering
the function (for instance, [un]hold) it would try to create the check list
again with duplicate remote candidates.
Fixed so that if the create check list fails the necessary data structures
are properly re-initialized for any subsequent retries.
Note, it was decided to not stop ice support (by calling ast_rtp_ice_stop) on a
check list failure because it possible things might still work. However, a
debug message was added to help with any future troubleshooting.
(closes issue ASTERISK-22911)
Reported by: Vytis Valentinavičius
Patches:
works_on_my_machine.patch uploaded by xytis (license 6558)
........
Merged revisions 405234 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 405235 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405236 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RTCP's calculation of the number of lost packets in an RTP stream is based on
that stream's sequence number count, the number of received packets, and how
many packets we expect to receive. When the SSRC for an RTP stream changes,
there can - and almost always will be - a large jump in the next packet's
timestamp and sequence number. If we don't reset the number of received
packets, sequence number count, and other metrics used by RTCP, the next RR/SR
report will use the previous SSRC's values to calculate the lost packet count
for the new SSRC - resulting in a very large number of lost packets.
This patch modifies res_rtp_asterisk such that, if it detects a SSRC change, it
will reset the various values used by the RTCP calculations. From the
perspective of RTCP, this appears as a new media stream - which is what it is.
Review: https://reviewboard.asterisk.org/r/2886/
(closes issue AST-1174)
Reported by: Thomas Arimont
........
Merged revisions 400089 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400093 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 400108 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400117 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Moved rtcp_report RAII_VAR declaration into the loop so it is unref'ed
after every loop. Moved message_blob to loop and switched it to a regular
variable. The regular variable was used since message_blob is used in a
very contained way.
(closes issue ASTERISK-22565)
Reported by: Corey Farrell
Patches:
rtcp_report-leak.patch (license #5909) patch uploaded by Corey Farrell
Tested by: Corey Farrell
........
Merged revisions 399607 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch uses PJSIP's pj_log_set_log_func() to forward PJSIP's log
messages to Asterisk's logger. This is done in a new module:
res_pjsip_log_forwarder.so.
This patch sets defaultenabled on the existing res_pjsip_logger.so to
no, since logging every SIP packet seems a bit odd to do by default, and
is (hopefully) less necessary with regular PJSIP logging.
It also removes res_rtp_asterisk's disabling of PJSIP logging.
(closes issue ASTERISK-22360)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/2830/
........
Merged revisions 399049 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
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
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
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
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
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
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
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
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
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
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
Kinsey Moore
Matthew Jordan
Jonathan Rose
Corey Farrell
Kevin Harwell
Richard Mudgett
David M. Lee
Michael L. Young
Jason Parker
Joshua Colp
Olle Johansson
Walter Doekes
Brent Eagles
Mark Michelson
Russell Bryant