Some telco switches occasionally ignore ISDN RESTART requests.  The fix
for ASTERISK-19608 added an escape clause for B channels in the restarting
state if the telco ignores a RESTART request.  If the telco fails to
acknowledge the RESTART then Asterisk will assume the telco acknowledged
the RESTART on the second call attempt requesting the B channel by the
telco.  The escape clause is good for dealing with RESTART requests in
general but it does cause the next call for the restarting B channel to be
rejected if the telco insists the call must go on that B channel.

chan_dahdi doesn't really need to issue a RESTART request in response to
receiving a cause 44 (Requested channel not available) code.  Sending the
RESTART in such a situation is not required (nor prohibited) by the
standards.  I think chan_dahdi does this for historical reasons to deal
with buggy peers to get channels unstuck in a similar fashion as the
chan_dahdi.conf resetinterval option.

* Add the chan_dahdi.conf force_restart_unavailable_chans compatability
option that when disabled will prevent chan_dahdi from trying to RESTART
the channel in response to a cause 44 code.

ASTERISK-25034 #close
Reported by: Richard Mudgett

Change-Id: Ib8b17a438799920f4a2038826ff99a1884042f65

This patch adds a new option to cdr.conf, 'newcdrcolumns', that will handle CDR
columns added in Asterisk 1.8. The columns are:
 * peeraccount
 * linkedid
 * sequence
When enabled, the columns in the database entry will be populated with the data
from the CDR.

ASTERISK-24976 #close

Change-Id: I51a57063f4ae5e194a9d933a8df45dc8a4534f0b

Change-Id: I7080d32b559f8c5d06ddd3198e0cd6e342bac841

Add new column to INSERT new columns added in cdr 1.8 version. The columns are:
 * peeraccount
 * linkedid
 * sequence
This feature is configurable in cdr_odbc.conf using a new configuration
option, 'newcdrcolumns'.

ASTERISK-24976 #close

Change-Id: Ibe0c7540a88305c6012786f438a0813ad8b19127

The next expected release from the 11 branch is 11.18.0. This patch
updates the UPGRADE notes to reflect that.

Change-Id: I8e6e9d62b3916484a68733cfc8d64b3709adb0c2

Backport menuselect from 13->12->11->1.8

Change-Id: I54c4dd2bdacd3c9d858be3acab08706941f2e585

Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file.
As a result, this patch removes Asterisk's support for showing source file
versions.

Specifically, it does the following:
* main/asterisk:
  - Refactor the file_version structure to reflect that it no longer
    tracks a version field.
  - Alter the "core show file version" CLI command such that it always
    reports the version of Asterisk. The file version is no longer
    available.

* main/manager: The Version key now always reports the Asterisk version.

* UPGRADE: Add notes for:
  - Modification to the ModuleCheck AMI Action.
  - Modification to the CLI "core show file version" command.

Change-Id: Ia932d3c64cd18a14a3c894109baa657ec0a85d28

The distinctive ring feature interferes with detecting Caller ID and
appears to have been broken for years.  What happens is if you have a
ring-ring cadence as used in the UK you get too many DAHDI events for the
distinctive ring pattern array and Caller ID detection is aborted.  I
think when Zapata/DAHDI added the ring begin event it broke distinctive
ring.  More events happen than before and the code does no filtering of
which event times are recorded in the pattern array.

* Made distinctive ring only record the ringt count when the ring ends
instead of on just any DAHDI event.  Distinctive ring can be ring,
ring-ring, ring-ring-ring, or different ring durations for the up to three
rings.

* Fixed the distinctive ring detection enable (chan_dahdi.conf option
usedistinctiveringdetection) to be per port instead of somewhat per port
and somewhat global.  This has been broken since v1.8.

* Fixed using the default distinctive ring context when the detected
pattern does not match any configured dringX patterns.  The default
context did not get set when the previous call was a matched distinctive
ring pattern and the current call is not matched.  This has been broken
since v1.8.

* Made distinctive ring have no effect on Caller ID detection when it is
disabled.  Caller ID detection just monitors for 10 seconds before giving
up.

* Fixed leak of struct callerid_state memory when a polarity reversal
during Caller ID detection causes the incoming call to be aborted.

DAHDI-1143
AST-1545
ASTERISK-24825 #close
Reported by: Richard Mudgett

ASTERISK-17588
Reported by: Daniel Flounders

Review: https://reviewboard.asterisk.org/r/4444/


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@432530 65c4cc65-6c06-0410-ace0-fbb531ad65f3

For the featdmf signaling mode the incoming MF Caller-ID information is
formatted as follows: *${CALLERID(ani2)}${CALLERID(ani)}#*${EXTEN}#

Rather than discarding the ani2 digits, populate the CALLERID(ani2) value
with what is received instead.

AST-1368 #close
Reported by: Denis Martinez
Patches:
      extract_ani2_for_featdmf_v11.patch (license #5621) patch uploaded by Richard Mudgett


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@429783 65c4cc65-6c06-0410-ace0-fbb531ad65f3

There are two aspects to the vulnerability:
(1) res_jabber/res_xmpp use SSLv3 only. This patch updates the module to use
    TLSv1+. At this time, it does not refactor res_jabber/res_xmpp to use the
    TCP/TLS core, which should be done as an improvement at a latter date.
(2) The TCP/TLS core, when tlsclientmethod/sslclientmethod is left unspecified,
    will default to the OpenSSL SSLv23_method. This method allows for all
    encryption methods, including SSLv2/SSLv3. A MITM can exploit this by
    forcing a fallback to SSLv3, which leaves the server vulnerable to POODLE.
    This patch adds WARNINGS if a user uses SSLv2/SSLv3 in their configuration,
    and explicitly disables SSLv2/SSLv3 if using SSLv23_method.

For TLS clients, Asterisk will default to TLSv1+ and WARN if SSLv2 or SSLv3 is
explicitly chosen. For TLS servers, Asterisk will no longer support SSLv2 or
SSLv3.

Much thanks to abelbeck for reporting the vulnerability and providing a patch
for the res_jabber/res_xmpp modules.

Review: https://reviewboard.asterisk.org/r/4096/

ASTERISK-24425 #close
Reported by: abelbeck
Tested by: abelbeck, opsmonitor, gtjoseph
patches:
  asterisk-1.8-jabber-tls.patch uploaded by abelbeck (License 5903)
  asterisk-11-jabber-xmpp-tls.patch uploaded by abelbeck (License 5903)
  AST-2014-011-1.8.diff uploaded by mjordan (License 6283)
  AST-2014-011-11.diff uploaded by mjordan (License 6283)


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@425986 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The new inband_on_setup_ack option causes Asterisk to assume inband audio
may be present when a SETUP_ACKNOWLEDGE message is received.

Q.931 Section 5.1.3 says that in scenarios with overlap dialing, when a
dialtone is sent from the network side, progress indicator 8 "Inband info
now available" MAY be sent to the CPE if no digits were received with the
SETUP.  It is thus implied that the ie is mandatory if digits came with
the SETUP and dialtone is needed.  This option should be enabled, when the
network sends dialtone and you want to hear it, but the network doesn't
send the progress indicator when needed.

NOTE: For Q.SIG setups this option should be enabled when outgoing overlap
dialing is also enabled because Q.SIG does not send the progress indicator
with the SETUP ACK.

The commit -r413714 (AST-1338) which causes this issue was dealing with a
SIP-to-ISDN interoperability issue.

This commit is a merge of the two patches indicated below.

ASTERISK-23897 #close
Reported by: Pavel Troller
Patches:
      pri-4.diff (license #6302) patch uploaded by Pavel Troller
      jira_asterisk_23897_v11.patch (license #5621) patch uploaded by rmudgett

Review: https://reviewboard.asterisk.org/r/3633/
........

Merged revisions 417956 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@417957 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This change fixes up DTLS support in res_rtp_asterisk so it can accept and provide
a SHA-256 fingerprint, so it occurs on RTCP, and so it occurs after ICE negotiation
completes. Configuration options to chan_sip have also been added to allow behavior
to be tweaked (such as forcing the AVP type media transports in SDP).

ASTERISK-22961 #close
Reported by: Jay Jideliov

Review: https://reviewboard.asterisk.org/r/3679/


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@417677 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When a client takes a long time to process information received from Asterisk,
a write operation using fwrite may fail to write all information. This causes
the underlying file stream to be in an unknown state, such that the socket
must be disconnected. Unfortunately, there are two problems with this in
Asterisk's existing websocket code:
1. Periodically, during the read loop, Asterisk must write to the connected
   websocket to respond to pings. As such, Asterisk maintains a reference to
   the session during the loop. When ast_http_websocket_write fails, it may
   cause the session to decrement its ref count, but this in and of itself
   does not break the read loop. The read loop's write, on the other hand,
   does not break the loop if it fails. This causes the socket to get in a
   'stuck' state, preventing the client from reconnecting to the server.
2. More importantly, however, is that the fwrite in ast_http_websocket_write
   fails with a large volume of data when the client takes awhile to process
   the information. When it does fail, it fails writing only a portion of
   the bytes. With some debugging, it was shown that this was failing in a
   similar fashion to ASTERISK-12767. Switching this over to ast_careful_fwrite
   with a long enough timeout solved the problem.

ASTERISK-23917 #close
Reported by: Matt Jordan

Review: https://reviewboard.asterisk.org/r/3624/



git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@417310 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Simply establishing a TCP connection and never sending anything to the
configured HTTP port in http.conf will tie up a HTTP connection.  Since
there is a maximum number of open HTTP sessions allowed at a time you can
block legitimate connections.

A similar problem exists if a HTTP request is started but never finished.

* Added http.conf session_inactivity timer option to close HTTP
connections that aren't doing anything.  Defaults to 30000 ms.

* Removed the undocumented manager.conf block-sockets option.  It
interferes with TCP/TLS inactivity timeouts.

* AMI and SIP TLS connections now have better authentication timeout
protection.  Though I didn't remove the bizzare TLS timeout polling code
from chan_sip.

* chan_sip can now handle SSL certificate renegotiations in the middle of
a session.  It couldn't do that before because the socket was non-blocking
and the SSL calls were not restarted as documented by the OpenSSL
documentation.

* Fixed an off nominal leak of the ssl struct in
handle_tcptls_connection() if the FILE stream failed to open and the SSL
certificate negotiations failed.

The patch creates a custom FILE stream handler to give the created FILE
streams inactivity timeout and timeout after a specific moment in time
capability.  This approach eliminates the need for code using the FILE
stream to be redesigned to deal with the timeouts.

This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
the SSL_read/SSL_write operations.

ASTERISK-23673 #close
Reported by: Richard Mudgett
........

Merged revisions 415841 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@415854 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The change was marked against the wrong version of Asterisk. My apologies.


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@415837 65c4cc65-6c06-0410-ace0-fbb531ad65f3

MixMonitor AMI commands StartMixMonitor and StopMixMonitor lacked class
authorization. StopMixMonitor now requires that the manager user either have
the call or system class authorization. StartMixMonitor is a slightly larger
issue since it can execute shell commands if the right arguments are passed
into it, and we consider this a permission escalation. A security release
will be issued for problem this shortly.

ASTERISK-23609 #close
Reported by: Corey Farrell


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@415825 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........

Merged revisions 414345 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@414346 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........

Merged revisions 411807 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@411808 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The masquerade supertest frequently fails because either the local channel
chain doesn't completely optimize out or the DTMF handshake doesn't
completely get accross.  Local channel optimization requires frames
flowing to trigger when optimization can happen.  When optimization
happens the media frame that triggered the optimization is dropped.
Sending DTMF requires frames to flow in the other direction for timing
purposes while sending nothing.  If internal timing is not enabled when
MOH is playing, Asterisk switches to received timing when an audio frame
is received.  With optimization dropping media frames and MOH not sending
frames unless it receives frames, occasionaly there are no more frames
being passed and the test fails.

* The asterisk command line -I option and the asterisk.conf
internal_timing option are removed.  Asterisk now always uses internal
timing when needed if any timing module is loaded.  The issue
ASTERISK-14861 did this quite awhile ago in v1.4 but effectively is broken
if other internal timing modules besides DAHDI are used.  The
ast_read_generator_actions() now only does received timing if it has no
choice for frame generators like MOH, silence, and playback streaming.

* Cleaned up some code dealing with frame generators in
ast_deactivate_generator(), generator_write_format_change(),
ast_activate_generator(), and ast_channel_stop_silence_generator().

ASTERISK-22846 #close
Reported by: Matt Jordan

Review: https://reviewboard.asterisk.org/r/3414/
........

Merged revisions 411715 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@411716 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........

Merged revisions 411457 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@411458 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch fixes setting nullable integer columns to NULL instead of an empty
string, which fails for PostgreSQL, for example. The current code is supposed
to do so, but the check is broken. The patch also allows the first column in
the list to be a nullable integer.

This patch also adds a compatibility setting in res_odbc.conf,
allow_empty_string_in_nontext. It is enabled by default. It should be disabled
for database backends (such as PostgreSQL) that require NULL instead of an
empty string for Integer columns.

Review: https://reviewboard.asterisk.org/r/3375

(issue ASTERISK-23459)
Reported by: zvision
patches:
  res_config_odbc.diff uploaded by zvision (License 5755)
........

Merged revisions 411399 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@411408 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Currently, when the first marked user enters the conference that
contains waitmarked users, a prompt is played indicating that the user
is being placed into the conference. Unfortunately, this prompt is
played to the marked user and not the waitmarked users which is not
very helpful.

This patch changes that behavior to play a prompt stating
"The conference will now begin" to the entire conference after adding
and unmuting the waitmarked users since the design of confbridge is not
conducive to playing a prompt to a subset of users in a conference in
an asynchronous manner.

(closes issue PQ-1396)
Review: https://reviewboard.asterisk.org/r/3155/
Reported by: Steve Pitts


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@407857 65c4cc65-6c06-0410-ace0-fbb531ad65f3

According to the new standard for V.27 and V.32 they are able to transmit
at a bit rate of 4,800 or 9,600.  The check_mode_rate function needed to be
updated to reflect this.  Also, because of this change the default 'minrate'
value was updated to be 4800.

(closes issue ASTERISK-22790)
Reported by: Paolo Compagnini
Patches:
     res_fax.txt uploaded by looserouting (license 6548)
........

Merged revisions 405656 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@405693 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The per console verbose level feature as previously implemented caused a
large performance penalty.  The fix required some minor incompatibilities
if the new rasterisk is used to connect to an earlier version.  If the new
rasterisk connects to an older Asterisk version then the root console
verbose level is always affected by the "core set verbose" command of the
remote console even though it may appear to only affect the current
console.  If an older version of rasterisk connects to the new version
then the "core set verbose" command will have no effect.

* Fixed the verbose performance by not generating a verbose message if
nothing is going to use it and then filtered any generated verbose
messages before actually sending them to the remote consoles.

* Split the "core set debug" and "core set verbose" CLI commands to remove
the per module verbose support that cannot work with the per console
verbose level.

* Added a silent option to the "core set verbose" command.

* Fixed "core set debug off" tab completion.

* Made "core show settings" list the current console verbosity in addition
to the root console verbosity.

* Changed the default verbose level of the 'verbose' setting in the
logger.conf [logfiles] section.  The default is now to once again follow
the current root console level.  As a result, using the AMI Command action
with "core set verbose" could again set the root console verbose level and
affect the verbose level logged.

(closes issue AST-1252)
Reported by: Guenther Kelleter

Review: https://reviewboard.asterisk.org/r/3114/


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@405431 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Add a note that the "retry on 403 response to REGISTER" for chan_sip is
non-functional in the versions in which it was first introduced.
........

Merged revisions 405088 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@405089 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch allows individual dialplan functions to be marked as
'dangerous', to inhibit their execution from external sources.

A 'dangerous' function is one which results in a privilege escalation.
For example, if one were to read the channel variable SHELL(rm -rf /)
Bad Things(TM) could happen; even if the external source has only read
permissions.

Execution from external sources may be enabled by setting
'live_dangerously' to 'yes' in the [options] section of asterisk.conf.
Although doing so is not recommended.

(closes issue ASTERISK-22905)
Review: http://reviewboard.digium.internal/r/432/
........

Merged revisions 403913 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@403917 65c4cc65-6c06-0410-ace0-fbb531ad65f3

While looking at ASTERISK-22236, Walter Doekes pointed out that when running
"sip show peers", the setting being displayed can be confusing.  The display of
"N" used to mean NAT (i.e. yes).  The NAT setting has gone through many
different changes resulting in the display of different characters to try and
convey what the current setting is for 'Forcerport' (A for Auto and Forcerport
is currently on, a for Auto but Forcerport is off, Y for yes, and N for no).
During the initial code review to try and clarify these settings (especially
since "N" no longer meant what it used to mean in prior versions of Asterisk),
Mark Michelson suggested using the full space available to display the settings
which helped to make the settings very clear.  That was a great suggestion.

Therefore, this patch does the following:

* The column for 'Forcerport' now will show: Auto (Yes), Auto (No), Yes, or No.

* A column for the 'Comedia' setting has been added.  It too will display the
  setting in a non-cryptic way: Auto (Yes), Auto (No), Yes, or No.

* UPGRADE.txt has been updated to document this change.

(closes issue ASTERISK-22728)
Reported by: Walter Doekes
Tested by: Michael L. Young
Patches:
    asterisk-forcerport-display-clarification_v3.diff
                                     uploaded by Michael L. Young (license 5026)

Review: https://reviewboard.asterisk.org/r/2941


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@402111 65c4cc65-6c06-0410-ace0-fbb531ad65f3

ConfBridge now has the ability to set the language of announcements to the
conference.  The language can be set on a bridge profile in
confbridge.conf or by the dialplan function
CONFBRIDGE(bridge,language)=en.

(closes issue ASTERISK-19983)
Reported by: Jonathan White
Patches:
      M19983_rev2.diff (license #5138) patch uploaded by junky (modified)
Tested by: rmudgett


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@400741 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This adds a global option in chan_sip to allow it to continue
attempting registration if a 403 is received, clearing the cached nonce
and treating it as a non-fatal response. Normally, this would cause
registration attempts to that endpoint to stop.

(closes issue ASTERISK-17138)
Review: https://reviewboard.asterisk.org/r/2874/
Reported by: Rudi
........

Merged revisions 400137 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@400140 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Review: https://reviewboard.asterisk.org/r/2777/


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397604 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(related to issue ASTERISK-21903)


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@396199 65c4cc65-6c06-0410-ace0-fbb531ad65f3

indicate when streaming an audio file fails like it is done in other parts
of the code to indicate an error.

Note was requested by Paul Belanger: 
http://lists.digium.com/pipermail/asterisk-dev/2013-July/061420.html

(related to issue ASTERISK-21903)
........

Merged revisions 396196 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@396197 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch notes that libuuid is now a dependency for res_rtp_asterisk; this
was introduced in between 11.4.0 and 11.5.0 to resolve a dependency for
pjproject, which res_rtp_asterisk uses for ICE/STUN/TURN support.

It also removes a conflicting note from CHANGES. While support for playing
prompts to the first participant was added for app_queue, it was disabled
by default and an option added to enable it. That was properly noted in the
UPGRADE.txt file.


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@395020 65c4cc65-6c06-0410-ace0-fbb531ad65f3

In r386792, the ability to play prompts to the first caller in a call queue was
added. While this is arguably a bug fix for those who expect the first caller
to continue receiving prompts while the agent is dialed, it has the side effect
of preventing the first caller from hearing the agent immediately upon
bridging. This may not be a problem for those who really want this option, but
for those who didn't care whether or not the first caller in queue heard their
position, it was an issue.

This patch disables the ability for the first caller in the queue to hear
prompts and adds a new option, announce-to-first-user, to queues.conf. Those
who the behavior can enable it by setting this value to True.

Note that if we ever implement the ability to have the prompts be stopped
upon bridging, this option can be removed.

(closes issue ASTERISK-21782)
Reported by: Remi Quezada
........

Merged revisions 391215 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@391241 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

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

For some channel drivers, specifically those that have a varying rate in the
number of audio samples, the audio quality for a MeetMe conference can be
exceedingly poor. This is due to a unilateral application of the DENOISE
function in func_speex to channels joining the conference.

The denoiser function in the speex library is initialized with the number of
audio samples in each sample that will be provided to it. If the number of
audio samples changes, the denoiser has to be thrown away and re-initialized.

While this could be worked around by removing func_speex, that doesn't help
if you actually use the denoiser with other channels on the system.

This patches does the following:
 * Checks for the presence of func_speex as opposed to codec_speex when
   determining if the DENOISE function is present (which is where the function
   is actually implemented)
 * Adds an option to MeetMe 'n' that causes the denoiser to not be applied
   to a channel when it joins. This keeps the current behavior the default, but
   let's users disable the denoiser if it causes problems on their system.

Review: https://reviewboard.asterisk.org/r/2358

(closes issue AST-1062)
Reported by: Thomas Arimont
........

Merged revisions 382227 from http://svn.asterisk.org/svn/asterisk/branches/1.8


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@382230 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When r376428 was commited to re-order start up sequences to be more tolerant of
forking with thread primitives, a few items were changed that caused changes
in behavior on some distros. This includes:
 * Not displaying the splash screen on a remote console.
 * Displaying an error message on stderr when a remote console cannot connect
   to a running instance of Asterisk.

In the first case, the splash screen was re-added (thanks to Michael L. Young).
In the second case, the various init.d scripts were modified to pipe stderr
to /dev/null, as the error message is useful - if you execute a remote
console or a remote console command execution and it fail, it should tell
you. Note that the error message was always present, it just failed to be
printed prior to r376428.

Much thanks to the folks who quickly reported this problem, provided solutions,
and promptly tested the various init.d scripts on a variety of distros.

(closes issue ASTERISK-20945)
Reported by: Warren Selby
Tested by: Michael L. Young, Jamuel Starkey, kaldemar, Danny Nicholas, mjordan
patches:
  asterisk-20945-remote-intro-msg.diff uploaded by elguero (license 5026)
  ASTERISK-20945-1.8-mjordan.diff uploaded by mjordan (license 6283)
........

Merged revisions 379760 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 379777 from http://svn.asterisk.org/svn/asterisk/branches/10


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@379790 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This allows Asterisk to start without having to specify the
LD_LIBRARY_PATH. This can be disabled by passing --disable-rpath to
configure.

(closes issue ASTERISK-20407)
Reported by: David M. Lee
Review: https://reviewboard.asterisk.org/r/2132/


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@379475 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When ringinuse=no queue members can receive more than one call if these
calls happen at nearly the same time.

* Fix so a queue member does not receive more than one call from a queue.

NOTE: This fix does not prevent multiple calls to a member if the member
is in more than one queue.

* Did some refactoring to eliminate some code redundancy.

(issue ASTERISK-16115)
Reported by: nik600
Patches:
      jira_asterisk_16115_single_q_v1.8.patch (license #5621) patch uploaded by rmudgett
      Modified

* Revert the -r341580 and -r341599 changes adding the queues.conf
check_state_unknown option as it was added in an attempt to fix this
problem.  The fix did not need to be optional.  The fix should not have
tried to explicitly set the device state.  Setting the device state by
something other than the device introduces a race condition.  I also could
not see how the change would be effective other than delaying the
app_queue code long enough for the device state to propagate to app_queue.
........

Merged revisions 378663 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 378683 from http://svn.asterisk.org/svn/asterisk/branches/10


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@378687 65c4cc65-6c06-0410-ace0-fbb531ad65f3