ASTERISK-18739
Patch by: pawel (modified)
........

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

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


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

Residual changes for Asterisk v10 branch from ASTERISK-18747 after
https://reviewboard.asterisk.org/r/1564/ commit and associated dialogs
callid hash key change fix.

* Make check_rtp_timeout() return CMP_MATCH if need to delete dialog from
dialogs_rtpcheck.  This is an optimization to avoid an unneeded
lock/unlock and object search when using ao2_unlink.

* Prevent crash in check_rtp_timeout() if dialog->rtp is NULL.

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

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


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

"dialplan remove include x from y" crashed when the amount of arguments
was less than 6.

(closes issue ASTERISK-18762)
Reported by: Andrey Solovyev
Tested by: Andrey Solovyev
........

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

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


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

https://origsvn.digium.com/svn/asterisk/branches/10

........
  r343900 | dvossel | 2011-11-08 12:29:33 -0600 (Tue, 08 Nov 2011) | 11 lines
  
  Fixes regression caused by r343635
  
  There was a missing unlock for a function return that is only
  present in Asterisk 10 and Asterisk Trunk.
  
  (closes issue ASTERISK-18839)
  Reported by: Michael L. Young
  Patches:
      asterisk-18839-missing-lock-trunk-v2.diff (License #5026) patch uploaded by Michael L. Young
........


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

* Fixed a LOG_ERROR message referencing the config variable list v that
had previously been processed and became NULL.

* Added error return value set that was missing in an ast_append_ha()
error return path.

(closes issue ASTERISK-18743)
Reported by: Michele
Patches:
      issueA18743-fix_dynamic_exclude_static_bad_host_log.patch (license #5674) patch uploaded by Walter Doekes
Tested by: Michele
........

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

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


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

A hardcoded a branch number was in the prep_tarball which could not work. Changed
it to the  variable.
........

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


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

The "Trust RPID" and "Send RPID" entries in the "sip show settings" CLI command
pulled the flags from the incorrect global flags page.  These are now read from
sip global flags page 0.

(closes issue AST-711)
........

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


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

You can now use the built in variables , , and 
within a dynamic weight. For example, this could be useful when you want
to pass requested lookup number to the SHELL() function which could be
used to execute a script to dynamically set the weight of the result.

(Closes issue ASTERISK-13657)
Reported by: Joel Vandal
Tested by: Leif Madsen, Russell Bryant
Patches:
     asterisk-1.6-dundi-varhead.patch uploaded by Joel Vandal (License #5374)

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

ASTERISK-18669
........

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

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


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

Changing an object value used as a container key requires removing the
object from the container and reinserting it.

* Created change_callid_pvt() to call instead of build_callid_pvt().  The
change_callid_pvt() will correctly change the dialog callid so the ao2
conainter can explicitly unlink it.
........

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

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


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

Fix a locking inversion in sip_send_mwi_to_peer that was causing deadlocks.
This function now requires that both the peer and associated pvt be unlocked
before it is called for cases where peer and peer->mwipvt form a circular
reference.

(closes issue ASTERISK-18663)
Review: https://reviewboard.asterisk.org/r/1563/
........

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

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


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

The udptl port range was defined as 4000-4999 in the udptl.conf.sample,
as 4500-4599 if you didn't have a config and 4500-4999 if your config
was broken. Default is now 4000-4999.

(closes issue ASTERISK-16250)
Reviewed by: Tilghman Lesher

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

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


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

A dialog cannot be destroyed by the ao2_callback dialog_needdestroy
because of a deadlock between the dialogs container lock and the RWLOCK of
the events subscription list.

* Create dialogs_to_destroy container to hold dialogs that will be
destroyed.

* Ensure that the event subscription callback will never happen with an
invalid peer pointer by making the event callback removal the first thing
in the peer destructor callback.

NOTE: This particular deadlock will not happen with Asterisk 10, but some
of the changes still apply.

(closes issue ASTERISK-18747)
Reported by: Gregory Hinton Nietsky

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

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

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


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

AST-699
........

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


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

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

(these memleaks stop development of gk codes, now i can continue)
Fix printHandler 'Unbalanced Structure' issues with locking printHandler
data for single thread.
........

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

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


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

The sqlite realtime handler assumed you had a static config configured
as well. The realtime multientry handler assumed that you weren't using
dynamic realtime.

(closes issue ASTERISK-18354)
(closes issue ASTERISK-18355)

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

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

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


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

........

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

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


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

The original REGISTERTRYING flag, in addition to being impossible to
check, also encroached on the space for the flag above it. This
patch moves the flags that were below REGISTERTRYING back to where
they were as though we had just removed the REGISTERTRYING option.
........

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

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


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

This option is not only useless, but has been broken since inception since
the flag was never copied from the peer where it is set to the pvt where
it was checked. RFC 3261 specificially states that you should not send a
provisional response to a non-INVITE request, and if we did fix the code
so that it worked, it would cause the same kind of user enumeration
vulnerability that we've discussed with the nat= setting. This patch
removes registertrying option and any code that would have sent a 100
response to a register.

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

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

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


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

Changeset r342927 introduced a warning which was only supposed to be
emitted when a found realtime peer had an empty (or no) name. It turned
out that there were some inconsistencies left. Now found peers with an
empty name are explicitly ignored like before r342927 but better.

Reviewed by: Stefan Schmidts, Terry Wilson

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

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

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


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

Integers should always be aligned. For some platforms (ARM, SPARC) this
is more important than for others. This changeset ensures that the
string field string lengths are aligned on *all* platforms, not just on
the SPARC for which there was a workaround. It also fixes that the
length integer can be resized to 32 bits without problems if needed.

(closes issue ASTERISK-17310)
Reported by: radael, S Adrian
Reviewed by: Tzafrir Cohen, Terry Wilson
Tested by: S Adrian

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

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

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


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

(closes issue ASTERISK-17422)
Reported by: Leif Madsen
........

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

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


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

In queues.conf.sample the leastrecent strategy was incorrectly described. Now updated
to reflect how the strategy actually checks peers.

(closes issue ASTERISK-17854)
Reported by: Sebastian Denz
Patches:
     queues.conf-doc_issue.patch (License #6139)
........

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

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


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

The MeetMe application documentation has some comments about usage of DAHDI,
and they were a bit outdated relative to modern DAHDI releases. This patch
changes the comment to just tell the user that a functional DAHDI timing
source is required, and no longer mention 'dahdi_dummy', since that module
does not exist in current DAHDI releases.
........

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

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


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

There were several problems with the dynamic realtime peer/user lookup
code. The lookup logic had become rather hard to read due to lots of
incremental changes to the realtime_peer function. And, during the
addition of the sipregs functionality, several possibilities for memory
leaks had been introduced. The insecure=port matching has always been
broken for anyone using the sipregs family. And, related, the broken
implementation forced those using sipregs to *still* have an ipaddr
column on their sippeers table.

Thanks Terry Wilson for comprehensive testing and finding and fixing
unexpected behaviour from the multientry realtime call which caused
the realtime_peer to have a completely unused code path.

This changeset fixes the leaks, the lookup inconsistenties and that
you won't need an ipaddr column on your sippeers table anymore (when
you're using sipregs). Beware that when you're using sipregs, peers
with insecure=port will now start matching!

(closes issue ASTERISK-17792)
(closes issue ASTERISK-18356)
Reported by: marcelloceschia, Walter Doekes
Reviewed by: Terry Wilson

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

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

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


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

Somewhere between 1.4 and 1.8 the sipusers family has become completely
unused. Before that, the sipfriends family had been obsoleted in favor
of separate sipusers and sippeers families. Apparently, they have been
merged back again into a single family which is now called "sippeers".

Reviewed by: irroot, oej, pabelanger

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

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

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


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

* Fixed typo in format_cap.c:joint_copy_helper() using the wrong variable.

* Fix potential race between checking if an interface exists and adding it
to the container in format.c:ast_format_attr_reg_interface().

* Fixed double rwlock destroy in format.c:ast_format_attr_init() error
exit path.

* Simplified format.c:find_interface() and format.c:has_interface().
........

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


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

When an extension is removed from a context, its entry in the pattern match
tree is not deleted.  Instead, the extension is marked as deleted.  When an
extension is removed and re-added, if that extension is also a prefix of
another extension, several log messages would report an error and did not
check whether or not the extension was deleted before accessing the memory.
Additionally, if the extension was already in the tree but previously
deleted, and the pattern was at the end of a match, the findonly flag was
not honored and the extension would be erroneously undeleted.  

Additionaly, it was discovered that an IAX2 peer could be unregistered
via the CLI, while at the same time it could be scheduled for unregistration
by Asterisk.  The unregistration method now checks to see if the peer
was already unregistered before continuing with an unregistration.

(closes issue ASTERISK-18135)
Reported by: Jaco Kroon, Henry Fernandes, Kristijan Vrban
Tested by: Matt Jordan

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

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

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


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

........

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


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

* Renamed AST_LIST_TRAVERSE_SAFE_BEGIN __new_prev to __list_current.

* Renamed AST_LIST_MOVE_CURRENT __list_cur to __extracted.


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

AST_LIST_INSERT_BEFORE_CURRENT() could not be used twice in an iteration
or before AST_LIST_REMOVE_CURRENT() without corrupting the list.
AST_LIST_INSERT_BEFORE_CURRENT() could also corrupt the list if
AST_LIST_INSERT_BEFORE_CURRENT() or AST_LIST_REMOVE_CURRENT() is used on
the next iteration.

* Fixed cut and paste error using the wrong variable in
AST_LIST_INSERT_BEFORE_CURRENT().

* Added linked list unit tests for AST_LIST_INSERT_BEFORE_CURRENT(),
AST_LIST_APPEND_LIST(), and AST_LIST_INSERT_LIST_AFTER().
........

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

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


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

........

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


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

Sequence number was handled as an unsigned integer (usually 32 bits I think, more
depending on the architecture) and was put into the rtp packet which is basically
just a bunch of bits using an or operation. Sequence number only has 16 bits
allocated to it in an RTP packet anyway, so it would add to the next field which
just happened to be the codec. This makes sure the sequence number is set to be
a 16 bit integer regardless of architecture (hopefully) and also makes it so the
incrementing of the sequence number does bitwise or at the peak of a 16 bit number
so that the value will be set back to 0 when going beyond 65535 anyway.

(closes issue ASTERISK-18291)
Reported by: Will Schick
Review: https://reviewboard.asterisk.org/r/1542/
........

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

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


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

res_jabber.c had a number of places where astobjs would be referenced and have their
reference counts bumped without having a dereference made before the object lost scope.
This patch adds a number of ASTOBJ_UNREFs to resolve that.

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

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

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


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

Reported by: wdoekes
Patched by: wdoekes

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

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

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


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

The "No D-channels available!  Using Primary channel as D-channel anyway!"
WARNING message has been confusing on non-NFAS setups.  The message refers
to things that are NFAS specific.

* Changed the warning to several different warnings to be more accurate
for the situation and less confusing as a result:
"No D-channels up!  Switching selected D-channel from X to Y.",
"No D-channels up!", and
"D-channel is down!".
........

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

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


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

AST-676
........

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

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


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

Despite an ominous sounding comment stating that membercount was for "logged
in" members only and thus we couldn't use ao2_container_count(), I could not
find a single place in the code where that seemed to be accurate. The only time
we decremented membercount was when we were marking something dead or actually
removing it. The only places we incremented it were either after ao2_link(), or
trying to correct for having set it to 0 during a reload. In every case where
we were correcting the value, it seemed that we were trying to make the count
actually match what ao2_container_count() would return. The only place I could
find where we made a determination about something being "logged in" or not, we
didn't trust the membercount, but instead looked at devicestate, paused, etc.

This patch removes membercount, replaces its use with ao2_container_count, and
manually adds the results of ao2_container_count to a "membercount" field for
ast_data queue query results. This patch also would fix AST-676, but as it is
slightly riskier than the previously committed fix, the two commits have been
made separately.

Reivew: https://reviewboard.asterisk.org/r/1541/
........

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

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


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

Since q->membercount is set to 0 before reloading, it is important
to increment it again for reloaded members as well as added.

(closes issue AST-676)

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

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

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


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