When we reload Asterisk or chan_sip, the flags force_rport and comedia that are
turned on and off when using the auto_force_rport and auto_comedia nat settings
go back to the default setting off. These flags are turned on when needed or
off when not needed at the time that a peer registers, re-registers or initiates
a call. This would apply even when only the default global setting
"nat=auto_force_rport" is being used, which in this case would only affect the
force_rport flag.
Everything is good except for the following: The nat setting is set to
auto_force_rport and auto_comedia. We reload Asterisk and the peer's
registration has not expired. We load in the settings for the peer which turns
force_rport and comedia back to off. Since the peer has not re-registered or
placed a call yet, those flags remain off. We then initiate a call to the peer
from the PBX. The force_rport and comedia flags stay off. If NAT is involved,
we end up with one-way audio since we never checked to see if the peer is behind
NAT or not.
This patch does the following:
* Moves the checking of whether a peer is behind NAT into its own function
* Create a function to set the peer's NAT flags if they are using the auto_* NAT
settings
* Adds calls in sip_request_call() to these new functions in order to setup the
dialog according to the peer's settings
(closes issue ASTERISK-21374)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
asterisk-21374-auto-nat-outgoing-fix_v2.diff Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2421/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@385473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On startup, it's possible for a frame to arrive before the processing threads were ready.
In iax2_process_thread() the first pass through falls into ast_cond_wait, should a frame arrive
before we are at ast_cond_wait, the signal will be ignored.
The result iax2_process_thread stays at ast_cond_wait forever, with deferred frames being queued.
Fix: When creating initial idle iax2_process_threads, wait for init_cond to be signalled
after each thread is started.
(issue ASTERISK-18827)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2427/
........
Merged revisions 385402 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@385403 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pjproject is what actually requires libuuid.
(closes issue ASTERISK-21125)
reported by Private Name
(Ed. note: Really? Private Name? I am rolling my eyes so hard right now.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@385356 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When MALLOC_DEBUG is enabled with res_config_ldap, issues (munmap_chunk:
invalid pointer errors) can occur as the memory is being allocated with
Asterisk's wrappers around malloc/calloc/free/strdup, as opposed to the
LDAP library's wrappers.
This patch uses the LDAP library's wrappers where appropriate, so that
compiling with MALLOC_DEBUG doesn't cause more problems than it solves.
Note that the patch listed below was modified slightly for this commit
to account for some additional memory allocation/deallocations.
(closes issue ASTERISK-17386)
Reported by: John Covert
Tested by: Andrew Latham
patches:
issue18789-1.8-r316873.patch uploaded by seanbright (License 5060)
........
Merged revisions 385190 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@385199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a BYE request is processed in chan_sip, the current SIP dialog is detached
from its associated Asterisk channel structure. The tech_pvt pointer in the
channel object is set to NULL, and the dialog persists for an RFC mandated
period of time to handle re-transmits.
While this process occurs, the channel is locked (which is good).
Unfortunately, operations that are initiated externally have no way of knowing
that the channel they've just obtained (which is still valid) and that they are
attempting to lock is about to have its tech_pvt pointer removed. By the time
they obtain the channel lock and call the channel technology callback, the
tech_pvt is NULL.
This patch adds a few checks to some channel callbacks that make sure the
tech_pvt isn't NULL before using it. Prime offenders were the DTMF digit
callbacks, which would crash if AMI initiated a DTMF on the channel at the
same time as a BYE was received from the UA. This patch also adds checks on
sip_transfer (as AMI can also cause a callback into this function), as well
as sip_indicate (as lots of things can queue an indication onto a channel).
Review: https://reviewboard.asterisk.org/r/2434/
(closes issue ASTERISK-20225)
Reported by: Jeff Hoppe
........
Merged revisions 385170 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@385173 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added a line showing the mapping of "mysql" to res_config_mysql available in add-ons. We used "mysql" as an example driver key in the sample, but didn't show what module it mapped too. Also added a subtitle above the list of keys for driver backends.
........
Merged revisions 385047 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@385048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
Fix For Not Overriding The Default Settings In chan_sip
The initial report was that the "nat" setting in the [general] section was not
having any effect in overriding the default setting. Upon confirming that this
was happening and looking into what was causing this, it was discovered that
other default settings would not be overriden as well.
This patch works similar to what occurs in build_peer(). We create a temporary
ast_flags structure and using a mask, we override the default settings with
whatever is set in the [general] section.
In the bug report, the reporter who helped to test this patch noted that the
directmedia settings were being overriden properly as well as the nat settings.
(closes issue ASTERISK-21225)
Reported by: Alexandre Vezina
Tested by: Alexandre Vezina, Michael L. Young
Patches:
asterisk-21225-handle-options-default-prob_1.8_v4.diff.diff
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2386/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@385009 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The initial report was that the "nat" setting in the [general] section was not
having any effect in overriding the default setting. Upon confirming that this
was happening and looking into what was causing this, it was discovered that
other default settings would not be overriden as well.
This patch works similar to what occurs in build_peer(). We create a temporary
ast_flags structure and using a mask, we override the default settings with
whatever is set in the [general] section.
In the bug report, the reporter who helped to test this patch noted that the
directmedia settings were being overriden properly as well as the nat settings.
This issue is also present in Asterisk 1.8 and a separate patch will be applied
to it.
(issue ASTERISK-21225)
Reported by: Alexandre Vezina
Tested by: Alexandre Vezina, Michael L. Young
Patches:
asterisk-21225-handle-options-default-prob_v4.diff
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2385/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@384827 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
Backport Appropiate NAT Setting Cleanup
In ASTERISK-20904, the focus was around the changes to NAT that took place in
Asterisk 11. Since the report stated that 1.8 was fine, we didn't take a look
at 1.8 at the time.
While working on ASTERISK-21225, I could see that 1.8 would benefit from having
some of those changes applied to it.
This patch does the following:
* The important part of this patch is that it sets the peer's flags earlier in
build_peer so that the code properly uses the peer's flags based on the peer's
configuration.
* constify req parameter in check_via()
* update realtime schemas under the contrib directory to handle properly the NAT
settings available in 1.8 as well as to handle the changes made in 11 to make
upgrading easier when installing newer versions of Asterisk
(closes issue ASTERISK-21243)
Reported by: Michael L. Young
Patches:
asterisk-20904-changes_for_1.8.diff Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2422/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@384780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new inband_on_proceeding option causes Asterisk to assume inband audio
may be present when a PROCEEDING message is received.
Q.931 Section 5.1.2 says the network cannot assume that the CPE side has
attached to the B channel at this time without explicitly sending the
progress indicator ie informing the CPE side to attach to the B channel
for audio. However, some non-compliant ISDN switches send a PROCEEDING
without the progress indicator ie indicating inband audio is available and
assume that the CPE device has connected the media path for listening to
ringback and other messages.
ASTERISK-17834 which causes this issue was dealing with a non-compliant
network switch.
(closes issue ASTERISK-21151)
Reported by: Gianluca Merlo
Tested by: rmudgett
........
Merged revisions 384685 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@384689 65c4cc65-6c06-0410-ace0-fbb531ad65f3
func_version.so was being rebuilt every time, because build.h was
changing every build, because of the cleantest dependency that was
added in r384410 to fix parallel make bugs.
Now build.h will only be created if it does not exist, which was the
original behavior of the Makefile.
........
Merged revisions 384544 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@384545 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Occasionally, make -j would fail due to missing includes, or other
unusual errors.
This was due to the 'cleantest' target, which was designed to force a
make clean when some change in the code would cause the typical
depedency checking to fail. Several targets in the main Makefile did
not depend upon cleantest, hence would run in parallel to it. By
adding the dependency, make -j runs happily now.
Review: https://reviewboard.asterisk.org/r/2418/
........
Merged revisions 384410 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@384411 65c4cc65-6c06-0410-ace0-fbb531ad65f3
At least one call to run_externnotify provides a NULL context parameter and
because the snprintf statement doesn't account for a NULL context parameter,
it simply writes '(null)' to the arguments string instead. This patch makes
it write two quotes back to back for that argument instead in the event of
a NULL context.
(closes issue ASTERISK-18207)
Reported by: Barry L. Kline
Patches:
modified from patch-20130306 uploaded by Karsten Wemheuer (License 5930)
........
Merged revisions 384325 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@384326 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While looking at the security vulnerability in ASTERISK-20967, Walter noticed
a file descriptor leak and some other issues in off nominal code paths. This
patch corrects them.
Note that this patch is not related to the vulnerability in ASTERISK-20967,
but the patch was placed on that issue.
(closes issue ASTERISK-20967)
Reported by: wdoekes
patches:
issueA20967_file_leak_and_unused_wkspace.patch uploaded by wdoekes (License 5674)
........
Merged revisions 384118 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@384119 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@384049 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When authenticating a SIP request with alwaysauthreject enabled, allowguest
disabled, and autocreatepeer disabled, Asterisk discloses whether a user
exists for INVITE, SUBSCRIBE, and REGISTER transactions in multiple ways. The
information is disclosed when:
* A "407 Proxy Authentication Required" response is sent instead of a
"401 Unauthorized" response
* The presence or absence of additional tags occurs at the end of "403
Forbidden" (such as "(Bad Auth)")
* A "401 Unauthorized" response is sent instead of "403 Forbidden" response
after a retransmission
* Retransmission are sent when a matching peer did not exist, but not when a
matching peer did exist.
This patch resolves these various vectors by ensuring that the responses sent
in all scenarios is the same, regardless of the presence of a matching peer.
This issue was reported by Walter Doekes, OSSO B.V. A substantial portion of
the testing and the solution to this problem was done by Walter as well - a
huge thanks to his tireless efforts in finding all the ways in which this
setting didn't work, providing automated tests, and working with Kinsey on
getting this fixed.
(closes issue ASTERISK-21013)
Reported by: wdoekes
Tested by: wdoekes, kmoore
patches:
AST-2013-003-1.8 uploaded by kmoore, wdoekes (License 6273, 5674)
AST-2013-003-10 uploaded by kmoore, wdoekes (License 6273, 5674)
AST-2013-003-11 uploaded by kmoore, wdoekes (License 6273, 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@384003 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AST-2012-014, fixed in January of this year, contained a fix for Asterisk's
HTTP server for a remotely-triggered crash. While the fix put in place fixed
the possibility for the crash to be triggered, a denial of service vector still
exists with that solution if an attacker sends one or more HTTP POST requests
with very large Content-Length values. This patch resolves this by capping
the Content-Length at 1024 bytes. Any attempt to send an HTTP POST with
Content-Length greater than this cap will not result in any memory allocation.
The POST will be responded to with an HTTP 413 "Request Entity Too Large"
response.
This issue was reported by Christoph Hebeisen of TELUS Security Labs
(closes issue ASTERISK-20967)
Reported by: Christoph Hebeisen
patches:
AST-2013-002-1.8.diff uploaded by mmichelson (License 5049)
AST-2013-002-10.diff uploaded by mmichelson (License 5049)
AST-2013-002-11.diff uploaded by mmichelson (License 5049)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The format attribute resource for H.264 video performs an unsafe read against a
media attribute when parsing the SDP. The value passed in with the format
attribute is not checked for its length when parsed into a fixed length buffer.
This patch resolves the vulnerability by only reading as many characters from
the SDP value as will fit into the buffer.
(closes issue ASTERISK-20901)
Reported by: Ulf Harnhammar
patches:
h264_overflow_security_patch.diff uploaded by jrose (License 6182)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383973 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r373424, several reentrancy problems in chan_sip were addressed. As a
result, the SIP channel driver is now properly locking the channel driver
private information in certain operations that it wasn't previously. This
exposed two latent problems either in register_verify or by functions called
by register_verify. This includes:
* Holding the private lock while calling sip_send_mwi_to_peer. This can create
a new sip_pvt via sip_alloc, which will obtain the channel container lock.
This is a locking inversion, as any channel related lock must be obtained
prior to obtaining the SIP channel technology private lock.
Note that this issue was already fixed in Asterisk 11.
* Holding the private lock while calling sip_poke_peer. In the same vein as
sip_send_mwi_to_peer, sip_poke_peer can create a new SIP private, causing
the same locking inversion.
Note that this locking inversion typically occured when CLI commands were run
while a SIP REGISTER request was being processed, as many CLI commands (such
as 'sip show channels', 'core show channels', etc.) have to obtain the channel
container lock.
(issue ASTERISK-21068)
Reported by: Nicolas Bouliane
(issue ASTERISK-20550)
Reported by: David Brillert
(issue ASTERISK-21314)
Reported by: Badalian Vyacheslav
(issue ASTERISK-21296)
Reported by: Gabriel Birke
........
Merged revisions 383863 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383878 65c4cc65-6c06-0410-ace0-fbb531ad65f3
r375757 attempted to resolve a race condition between multiple submissions of
CDRs while in batch mode from attempting to destroy the scheduled batch
submission by extending the batch CDR lock. Unfortunately, this causes a
deadlock between the pending CDR lock and the batch CDR lock. This patch
resolves the intent of r375757 by simply providing a new lock that protects
the scheduling of the batches. The original batch CDR lock is kept to protect
manipulation of the batch CDR settings, but has been placed such that it
is not held when the pending lock is held.
Thanks to Chase Venters for providing lock analysis on the issue.
(issue ASTERISK-21162)
Reported by: Chase Venters
........
Merged revisions 383839 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an SLA trunk is ringing (inbound call on the trunk) Asterisk will
make outbound calls to the stations that have that trunk. If more than
one station answers the call at the same time, all channels other than
the first one to answer are left in a bad state. The channel gets
leaked, is not connected to anything, and there's no way to get rid of
it.
We now properly clean up these losing channels by hanging up on them.
Since they lost the race, as we process their answer, there is no
ringing trunk for them to answer.
........
Merged revisions 383835 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383836 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CALLEDTON channel variable is set for incoming ISDN calls to the lower
7 bits of the Q.931 type-of-number/numbering-plan octet. The
CALLERID(dnid-num-plan) should have the same value.
(closes issue ASTERISK-21248)
Reported by: rmudgett
........
Merged revisions 383796 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A regression was accidentally introduced when allowing an optional ID to be used
when calling StopMixMonitor. When we are unable to stop MixMonitor on a
channel, -1 is being returned which triggers the hangup of the channel.
This patch restores the prior behavior by returning 0 whether we were successful
or not. It also allows the call from the manager to use the return code when
the action fails.
(closes issue ASTERISK-21294)
Reported by: daroz
Tested by: daroz
Patches:
asterisk-21294-stop_mixmonitor_hangingup.diff Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2404/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383631 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AMI, HTTP, and chan_sip all support TLS in some way, but none of them
support all the options that Asterisk's TLS core is capable of
interpreting. This prevents consumers of the TLS/SSL layer from setting
TLS/SSL options that they do not support.
This also gets tlsverifyclient closer to a working state by requesting
the client certificate when tlsverifyclient is set. Currently, there is
no consumer of main/tcptls.c in Asterisk that supports this feature and
so it can not be properly tested.
Review: https://reviewboard.asterisk.org/r/2370/
Reported-by: John Bigelow
Patch-by: Kinsey Moore
(closes issue AST-1093)
........
Merged revisions 383165 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a session timer expires during a dialog that has re-negotiated to T.38
and Asterisk is the refresher, Asterisk will send a re-INVITE with an SDP
containing audio media only. This causes some hilarity with the poor fax
session under weigh.
This patch corrects that by sending T.38 parameters if we are in the middle of
a T.38 session.
(closes issue ASTERISK-21232)
Reported by: Nitesh Bansal
patches:
dont-send-audio-reinvite-for-sess-timer-in-t38-call.patch uploaded by nbansal (License 6418)
........
Merged revisions 383124 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383125 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In certain situations, call files are not processed when using KQueue with
pbx_spool. Asterisk was sending an invalid timeout value when the spool
directory is empty, causing the call to kevent to error immediately. This
can create a tight loop, increasing the CPU load on the system.
(closes issue ASTERISK-21176)
Reported by: Carlton O'Riley
patches:
kqueue_osx.patch uploaded by coriley (License 6473)
........
Merged revisions 383120 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@383121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When retrieving the parking lots from a MySQL database table, the current order
is "filename, cat_metric desc, var_metric asc, category". If there are multiple
parking lots with the same cat_metric but different categories, everything is
being sorted on cat_metric first resulting in errors when loading the parking
lots.
This patch fixes the problem by sorting on the category field first, then the
cat_metric field.
(closes issue ASTERISK-21035)
Reported by: Alex Epshteyn
Patches:
asterisk-21035-orderby.diff Michael L. Young (license 5026)
........
Merged revisions 382942 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit updates some fields in the contributed realtime schema files to
handle IPv6 addresses.
(closes issue ASTERISK-21173)
Reported by: Torrey Searle
Patches:
realtime_sql.patch Torrey Searle (license 5334)
asterisk-21173-update-ip-fields.diff Michael L. Young (license 5026)
........
Merged revisions 382939 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382940 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ASTERISK-17888, the AMI Registry event during SIP registrations was supposed
to include the Username field. Somehow, one of the events was missed. This
patch corrects that - the Username field should be included in all AMI Registry
events involving SIP registrations.
(issue ASTERISK-17888)
(closes issue ASTERISK-21201)
Reported by: Dmitriy Serov
patches:
chan_sip.c.diff uploaded by Dmitriy Serov (license 6479)
........
Merged revisions 382847 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382848 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this change, certain conditions for sending the message would
result in an address of '(null)' being used in the via header of the
SIP message because a NULl value of pvt->ourip was used when initially
generating the via header. This is fixed by adding a call to build_via
when the address is set before sending the message.
(closes issue ASTERISK-21148)
Reported by: Zhi Cheng
Patches:
700-sip_msg_send_via_fix.patch uploaded by Zhi Cheng (license 6475)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382739 65c4cc65-6c06-0410-ace0-fbb531ad65f3
r381835 fixed a bug in vm_mailbox_snapshot where combining INBOX and Old forgot
that Urgent also "counts" as new messages. This fixed the problem when any of
the three folders was specified and the combine option was used.
It missed the case where the folder isn't specified and we build a snapshot of
all folders. This patch corrects that.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382617 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
Correct app_page documentation
The 'A' and 'n' options for Page() mention that the announcement will
be played simultaneously. This is not necessarily the case.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382514 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Several new IEs were not given types (or names), causing the comparison
function to improperly succeed. This adds those.
(closes issue AST-1128)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
