v11 only fix.

Change-Id: I340512f86cfd3a6f7703971fa8acfffc7d47132b

Change glue->update_peer() parameter from 0 to NULL to better indicate it
is a pointer.

Change-Id: I8ff2e5087f0e19f6998e3488a712a2470cc823bd

Commit 54b25c80 solved an issue where a
specific scenario involving local channels and a native local RTP bridge
could result in ringback still being heard on a calling channel even
after the call is bridged.

That commit caused many tests in the testsuite to fail with alarming
consequences, such as not sending DialBegin and DialEnd events, and
giving incorrect hangup causes during calls.

This commit reverts the previous commit and implements and alternate
solution. This new solution involves only passing AST_CONTROL_RINGING
frames across local channels if the local channel is in AST_STATE_RING.
Otherwise, the frame does not traverse the local channels. By doing
this, we can ensure that a playtones generator does not get started on
the calling channel but rather is started on the local channel on which
the ringing frame was initially indicated.

ASTERISK-25250 #close
Reported by Etienne Lessard

Change-Id: I3bc87a18a38eb2b68064f732d098edceb5c19f39

Control frames with a -1 payload are used as a special signal to stop
playtones generators on channels. This indication is sent both by
app_dial as well as by ast_answer() when a call is answered in case any
tones were being generated on a calling channel.

This control frame type was made to stop traversing local channel pairs
as an optimization, because it was thought that it was unnecessary to
send these indications, and allowing such unnecessary control frames to
traverse the local channels would cause the local channels to optimize
away less quickly.

As it turns out, through some special magic dialplan code, it is
possible to have a tones being played on a non-local channel, and it is
important for the local channel to convey that the tones should be
stopped. The result of having tones continue to be played on the
non-local channel is that the tones play even once the channel has been
bridged. By not blocking the -1 control frame type, we can ensure that
this situation does not happen.

ASTERISK-25250 #close
Reported by Etienne Lessard

Change-Id: I40227e4249d6d61dc6a9b08bbe9ee3aa18be7e30

In channels/sig_pri.h, struct sig_pri_span, the field
force_restart_unavailable_chans is only defined if

#if defined(HAVE_PRI_MCID) is true.

All other occurences of force_restart_unavailable_chans are outside of the

#if defined(HAVE_PRI_MCID)
endif

scope.

ASTERISK-25257 #close
Reported by: Patric Marschall

Change-Id: I071de89cc2cd0d85927a013036e235851f672549

If non-magic pickup (no "pickup-" in callid) is used, chan_sip locks the
channel it wants to pick up, and a bit further down, it locks the
channel list when allocating a new channel.

That causes a deadlock when another part of the code traverses over the
channel list, locking all the channels one by one.

This changeset fixes it by releasing the locks before calling sip_new
and reacquiring them afterwards.  Unfortunately this involves doing the
checks we already did again (because the channel may have changed).

While trying to avoid duplicate code, I did some refactoring for
readability:
- if refer_locked == 1, we guarantee there is a locked channel
- magic_callid holds a cached version of !ast_strlen_zero(pickup.exten)

This is for branch 11 only. It appears that the changed code in 13 does
not lock the components like it does in 11 and below. Reproducing the
deadlock on 13 has thusfar failed.

ASTERISK-25213 #close

Change-Id: Ie1d15bec7d634035f48892e1ed6227411d7de2c1

ASTERISK-25220 #close

Change-Id: Ic48f3a82f51ada87f2fb0e016c9efe0ad56f1ee3

Change-Id: I0ec7fd10d56d90d5a60b12b5a7d6807f265ac5e0

This patch updates a variety of Makefiles in Asterisk's build system to
remove .gcda and .gcno files when 'make clean' is executed. These files
are generated when '--enable-coverage' is passed to the Asterisk
configure script.

Change-Id: Ib70b41eea2ee2908885bff02e80faf9f40c84602

If a client sends and INVITE which is 401 rejected, then subsequently
sends a new INVITE with the auth info and uses a different fromtag
from the first INVITE, Asterisk will accept the new INVITE as part of
the original dialog - match_req_to_dialog() specifically ignores the
fromtag. However it does not update the stored dialog with the new
fromtag.

This results in Asterisk being unable to match future packets that are
part of this dialog (such as the ACK to the OK or the OK to the BYE),
and the call is dropped.

This problem was originally found when using an NEC-i SV8100-GE (NEC SIP
Card).

* After a successful match of a packet to the dialog, if the packet is
  not a SIP_RESPONSE, authentication is present and the fromtags are
  different, the stored fromtag is updated with the one from the recent
  INVITE.

ASTERISK-25154 #close
Reported by: Damian Ivereigh
Tested by: Damian Ivereigh

Change-Id: I5c16cf3b409e5ef9f2b2fe974b6bd2a45a6aa17e

When a BYE with an Also header is successfully processed, and the sender
of the BYE is bridged with another channel, chan_sip will unlock the
owner of the dialog on which the BYE was received, call ast_async_goto()
on the bridged channel, and then re-lock the owner. The reason for this
locking behavior is that ast_async_goto() can result in a masquerade,
which requires that the involved channels are unlocked.

The problem here is that this causes a locking inversion since the
dialog's lock is held when re-locking the owner channel after the async
goto. The lock order is supposed to be channel and then sip_pvt.

The fix proposed is simple. In addition to unlocking the owner channel
before the ast_async_goto() call, also unlock the sip_pvt. Then relock
both after ast_async_goto() returns, being sure to lock the channel and
then the sip_pvt.

ASTERISK-25139 #close
Reported by Gregory Massel

Change-Id: I72c4fc295ec8573bee599e8e9213c5350a3cd224

Although ast_context_find, ast_context_find_or_create and
ast_context_destroy perform locking of the contexts table,
any context pointer can become invalid at any time that the
contexts table is unlocked. This change adds locking around
all complete operations involving these functions.

Places where ast_context_find was followed by ast_context_destroy
have been replaced with calls ast_context_destroy_by_name.

ASTERISK-25094 #close
Reported by: Corey Farrell

Change-Id: I1866b6787730c9c4f3f836b6133ffe9c820734fa

ASTERISK-24887 #close
Reported by: Makoto Dei
Tested by: tensai

Change-Id: I6a96f572adb17f76b3acafe503a01c48eb5dd9bf

If an ISDN call is hungup by both sides at the same time a crash could
happen.

* Added missing NULL checks for the owner channel after calling
pri_queue_pvt_cause_data() in two places.  Code after those calls need to
check the owner channel pointer for NULL before use because
pri_queue_pvt_cause_data() needs to do deadlock avoidance to lock the
owner and the owner may get hung up.

ASTERISK-21893 #close
Reported by:  Alexandr Gordeev

Change-Id: Ica3e266ebc7a894b41d762326f08653e1904bb9a

Change-Id: If5eef47d03399ff93e3f2f490780144971f6b64a

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

The chan_dahdi channel driver is a very old driver.  The ability for it to
support ISDN was added well after the initial analog support.  Setting the
softhangup flags is a carry over from the original analog code.  The
driver was not updated to call ast_queue_hangup() which will post the AMI
HangupRequest event.

* Changed sig_pri.c to call ast_queue_hangup() instead of setting the
softhangup flag when the remote party initiates a hangup.

ASTERISK-24895 #close
Reported by: Andrew Zherdin

Change-Id: I5fe2e48556507785fd8ab8e1c960683fd5d20325

Added bootstrap products
Added channels/h323/Makefile
Added res/pjproject

Change-Id: I6b3bc56bf7bdaee0554f36fc2ce3a77e9eaf8aa3

POKE is used to check for peer availability; however, in networks with packet
loss, the current calculations may result in POKE expiration times that are too
short. This patch alters the expiration/retry time logic to take into account
the last known qualify round trip time, as opposed to always using a static
value for each peer.

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

ASTERISK-22352 #close
Reported by: Frederic Van Espen

ASTERISK-24894 #close
Reported by: Y Ateya
patches:
  poke_noanswer_duration.diff submitted by Y Ateya (License 6693)


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

This fixes autological comparison warnings in the following:
 * chan_skinny: letohl may return a signed or unsigned value, depending on the
   macro chosen
 * func_curl: Provide a specific cast to CURLoption to prevent mismatch
 * cel: Fix enum comparisons where the enum can never be negative
 * enum: Fix comparison of return result of dn_expand, which returns a signed
   int value
 * event: Fix enum comparisons where the enum can never be negative
 * indications: tone_data.freq1 and freq2 are unsigned, and hence can never be
   negative
 * presencestate: Use the actual enum value for INVALID state
 * security_events: Fix enum comparisons where the enum can never be negative
 * udptl: Don't bother to check if the return value from encode_length is less
   than 0, as it returns an unsigned int
 * translate: Since the parameters are unsigned int, don't bother checking
   to see if they are negative. The cast to unsigned int would already blow
   past the matrix bounds.

Review: https://reviewboard.asterisk.org/r/4533
ASTERISK-24917
Reported by: dkdegroot
patches:
  rb4533.patch submitted by dkdegroot (License 6600)


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

Interestingly enough, clang doesn't care about this.


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

This patch fixes an access to the peer callnumber that is unprotected by a
corresponding mutex. The peer->callno value can be changed by multiple threads,
and all data inside the iaxs array must be procted by a corresponding lock
of iaxsl.

The patch moves the unprotected access to a location where the mutex is
safely obtained.

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

ASTERISK-21211 #close
Reported by: Jaco Kroon
patches:
  asterisk-11.2.1-iax2_poke-segfault.diff submitted by Jaco Kroon (License 5671)


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

When udpbindaddr is set to the IPv6 bind all address of '::', Asterisk will
attempt to handle both IPv4 and IPv6 addresses, although the information will
be stored in a struct with an AF_INET6 address type. However, the current
NAT handling code won't handle the IPv4 mapped IPv6 addresses correctly.
This patch adds an additional check for the mapped address case, allowing
the NAT code to handle clients even when the address is IPv6.

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

ASTERISK-18032 #close
Reported by: Christoph Timm
patches:
  nat_with_ipv6.diff submitted by Valentin Vidić (License 6697)


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

Clang will flag errors when a char pointer is set to '\0', as opposed to a
value that the char pointer points to. This patch fixes this warning
in a variety of locations.

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

ASTERISK-24917
Reported by: dkdegroot
patches:
  rb4551.patch submitted by dkdegroot (License 6600)


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

These are fixes for compilation under gcc 5.0...

chan_sip.c:    In parse_request needed to make 'lim' unsigned.
inline_api.h:  Needed to add a check for '__GNUC_STDC_INLINE__' to detect C99 
               inline semantics (same as clang).
ccss.c:        In ast_cc_set_parm, needed to fix weird comparison.
dsp.c:         Needed to work around a possible compiler bug.  It was throwing 
               an array-bounds error but neither
               sgriepentrog, rmudgett nor I could figure out why.
manager.c:     In action_atxfer, needed to correct an array allocation.

This patch will go to 11, 13, trunk.

Review: https://reviewboard.asterisk.org/r/4581/
Reported-by: Jeffrey Ollie
Tested-by: George Joseph
ASTERISK-24932 #close




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

Fix misplaced parentheses in original fabs() expression.


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

This patch fixes several warnings caught by clang - in this case, usage of the
abs function on non-integer values. This patch uses labs and fabs, as
appropriate, in the various affected files.

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

ASTERISK-24917
Reported by: dkdegroot
patches:
  rb4525.patch submitted by dkdegroot (License 6600)


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

This patch fixes some invalid enum conversion warnings caught by clang. In
particular, several functions in chan_sip mixed usage of the st_refresher_param
enum and st_refresher enum. This patch corrects that.

ASTERISK-24917
Reported by: dkdegroot
patches:
  rb4535.patch submitted by dkdegroot (License 6600)


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

In chan_iax2, we attempt to assign a -1 to a bitfield. This gets caught by
clang, as it will truncate the -1 to a 1 implicitly.

Instead, we just assign the value a '1'.

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

ASTERISK-24917
Reported by: dkdegroot
patches:
  rb4537.patch submitted by dkdegroot (License 6600)


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

This patch fixes clang compilers warnings for unused functions. Specifically:
 * channels/chan_iax2: removed user_ref function
 * main/dsp.c: removed goertzel_update function

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

ASTERISK-24917
Reported by: dkdegroot
patches:
  rb4527.patch submitted by dkdegroot (License 6600)


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

Release the scheduler reference to the dialog for reinvite timeout during
dialog_unlink_all.

ASTERISK-24876 #close 
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4491/


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

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

When a realtime peer is built it can cause a locking inversion when the
just built peer is poked.  If the CLI command "sip show channels" is
periodically executed then a deadlock can happen because of the locking
inversion.

* Push the peer poke off onto the scheduler thread to avoid the locking
inversion of the just built realtime peer.

AST-1540
ASTERISK-24838 #close
Reported by: Richard Mudgett

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


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

Both the apps and channels Makefiles still listed 'res_features' as modules to
link against when compiling for cygwin or mingw32. This module hasn't existed
for quite some time.

ASTERISK-18105 #close
Reported by: feyfre


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

When Asterisk fails to start a PBX thread for a new channel - for example, when
the maxcalls setting in asterisk.conf is exceeded - we currently send a final
response, and then attempt to send a BYE request to the UA. Since that's all
sorts of wrong, this patch fixes that by setting sipalreadygone on the sip_pvt
such that we don't get stuck sending BYE requests to something that does not
want it.

Note that this patch is a slight modification of the one on ASTERISK-15434.
For clarity, it explicitly calls sipalreadygone with the calls to transmit a
final response.

ASTERISK-21845
ASTERISK-15434 #close
Reported by: Makoto Dei
Tested by: Matt Jordan
patches:
  sip-pbxstart-failed.patch uploaded by Makoto Dei (License 5027)



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

When we receive an SDP as part of an offer/answer for a peer/friend has been
configured to require encryption, and that SDP offer/answer failed to provide
acceptable crypto attributes, we currently issue a WARNING that uses the phrase
"we" and "requested". In this case, both of those terms are ambiguous - the
user will probably think "we" is Asterisk (it most likely isn't) and it may
not be a "request", so much as an SDP that was received in some fashion.

This patch makes the WARNING messages slightly less bad and a bit more
accurate as well.

ASTERISK-23214 #close
Reported by: Rusty Newton


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

Prior to this patch, SDP offers negotiating SDES-SRTP crypto attributes would
be rejected if those crypto attributes contained either a key lifetime or a
MKI parameter. While from a theoretical point of view this was defensible -
Asterisk does not support key lifetimes or multiple crypto keys - from a
practical point of view, this is quite a problem. A large number of endpoints
offer lifetimes/MKI, which Asterisk can tolerate so long as it doesn't actually
have to support anything more than a single key or refresh the key.
In reality, this is (so far as we've seen) always the case.

This patch is a forward port of Olle's work in the lingon-srtp-key-lifetime-1.8
branch. To quote Olle from ASTERISK-17721, it handles lifetime/MKI parameters
in the following fashion:

> The Lingon branch now handle lifetime and MKI parameters.
>
> We only accept lifetimes up to max for the crypto and higher than 10 hours
> for packetization of 20 ms (50 pps).
>
> We only handle MKI with index 1.
>
> We do not really bother with counting packets and reinviting at end of
> lifetime, so the min of 10 hours kind of takes care of most calls. If there
> are longer ones, we rely on the other side for re-invites.
>
> It's still not perfect, but I personally think this is an improvement. A
> configuration option for minimum lifetime accepted could be added.

When the patch was ported forward, I decided against adding a configuration
option as Olle's handling was more than sufficient for every case I've seen
come through the issue tracker or through interoperability testing. We can
revisit that decision if it proves to be false.

A few small other tweaks were made to the surrounding code to reduce
indentation and provide better type safety for the 'tag' parameter.

Review: https://reviewboard.asterisk.org/r/4419/
Review: https://reviewboard.asterisk.org/r/4418/

ASTERISK-17721 #close
Reported by: Terry Wilson

ASTERISK-17899 #close
Reported by: Dwayne Hubbard
patches:
  lingon-srtp-key-lifetime-1.8.diff uploaded by oej (License 5267)

ASTERISK-20233
Reported by: tootai

ASTERISK-22748
Reported by: Alejandro Mejia



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

When the monitor thread is stopped, its pthread ID is set to a specific value
(AST_PTHREADT_STOP) so that later portions of the code can determine whether
or not it is safe to manipulate the thread. Unfortunately, __sip_reliable_xmit
failed to check for that value, checking instead only for AST_PTHREAD_STOP.
Passing the invalid yet very specific value to pthread_kill causes a crash.

This patch adds a check for AST_PTHREADT_STOP in __sip_reliable_xmit such that
it doesn't attempt to poke the thread if the thread has already been stopped.

ASTERISK-24800 #close
Reported by: JoshE


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

With the log messages on one line, you can search for the log message seen
in the log and expect to find it.


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

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