This module supports sending both unicast and multicast RTP
to a specified target. Multicast functionality is the same as
chan_multicast_rtp was. In the case of unicast a specific
IP address and port can be specified, along with optional RTP
engine and format in the form of:

UnicastRTP/<ip address>:<port>/<engine>/<format>

This can be useful for sending a copy of a media stream to
another application for processing.

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


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

Also has could affect with anything that goes through ast_destroy_realtime.
If a CLI user used the command 'realtime destroy <family>' with only a single
column/value pair, Asterisk would crash when trying to create a variable list
from a NULL value.

ASTERISK-24231 #close
Reported by: Niklas Larsson
Review: https://reviewboard.asterisk.org/r/3985/
........

Merged revisions 422984 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422985 from http://svn.asterisk.org/svn/asterisk/branches/13


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

ast_play_and_record_full() has a parameter called "acceptdtmf" that is a
string of acceptable DTMF digits that may be pressed by a caller to end
and accept the recording.

ARI uses this function in order to perform recording, and it provides
options for what is passed as acceptdtmf to ast_play_and_record_full().
By default, ARI passes an empty string, with the intention that no DTMF
can be used to end the recording.

The problem is that ast_play_and_record_full() attempts to be "helpful"
by setting "#" as the acceptdtmf if an empty string or NULL pointer
has been passed in. With ARI, this results in unexpected behavior
occurring if you have attempted to intercept "#" yourself in order
to perform some other manipulation of the live recording.

This change removes the "helpful" behavior by no longer accepting
"#" as a default acceptdtmf if none is specified by the caller of
ast_play_and_record_full(). This makes the ARI scenario work as
expected.

The other callers of ast_play_and_record_full() are app_voicemail
and app_minivm, and in both cases, they pass an explicit "#" to
ast_play_and_record_full() as acceptdtmf, so they are unaffected
by this change.
........

Merged revisions 422964 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422965 from http://svn.asterisk.org/svn/asterisk/branches/13


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

ast_config_text_file_save() currently truncates include files as they
are processed.  If a subsequent include file or the main config file has
a permissions error that prevents writing, earlier include files are left
truncated resulting in a frantic search for backups.

This patch causes ast_config_text_file_save to check for write access
on all files before it truncates any of them.

Will be applied 1.8 > trunk.

Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3986/
........

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

Merged revisions 422903 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 422904 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422905 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The errors generated when validating 'auth' settings are missing a space which
makes the messages a little confusing.
........

Merged revisions 422899 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422901 from http://svn.asterisk.org/svn/asterisk/branches/13


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

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

Modifying Makefile and sounds.xml to include new core 1.4.26 and extra 1.4.15
sound prompt releases, plus the new Japanese core sound prompts contributed
by QLOOG.

ASTERISK-23324
Reported by: Kevin McCoy
Tested by: Rusty Newton
........

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

Merged revisions 422790 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 422791 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422883 from http://svn.asterisk.org/svn/asterisk/branches/13


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

It would be useful to get the current hold status of a channel.

Added CHANNEL(onhold) item that returns 1 (onhold) and 0 (not-onhold) for
the hold status of a channel.

ASTERISK-24038
Reported by: Matt Jordan

AFS-113 #close
Reported by: Mark Michelson

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


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

........

Merged revisions 422855 from http://svn.asterisk.org/svn/asterisk/branches/13


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

On review /r/3977, it was recommended to note in the
sample configuration about the size limitation for
resource lists. However, since there was no section in
the sample configuration at all for resource list
subscriptions, I decided to make a separate commit
where I have added the necessary sample configuration
as well as the size limitation warning.
........

Merged revisions 422853 from http://svn.asterisk.org/svn/asterisk/branches/13


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

PJSIP, unless a constant is modified at compilation time, limits
SIP requests to 4000 bytes. Full-state RLS notifications can easily
exceed this limit with moderately small lists.

This changeset allows for Asterisk to work around this size limit by
performing its own allocation of the transmission data buffer. This
way, Asterisk can allocate a buffer that exceeds the built-in maximum.

We still impose our own limit of 64000 bytes, mainly because making
allocations larger than that is a bit absurd.

ASTERISK-24181 #close
Reported by Mark Michelson

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

Merged revisions 422851 from http://svn.asterisk.org/svn/asterisk/branches/13


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

resource list

https://wiki.asterisk.org/wiki/display/AST/Resource+List+Subscription+Test+Plan
According to the off-nominal plan, if evenlist support is not specified in a
SUBSCRIBE's supported header(s), that subscription should be rejected with an
error.

ASTERISK-23871
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3960/diff/#index_header
........

Merged revisions 422836 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When a CDR is forked, a new CDR is created and appended to the CDR chain for
the Party A. The forked CDR starts life off as a clone of the last
non-finalized for the particular Party A. In the past, merely copying over
the snapshots for Party A/Party B would be sufficient. However, as the CDRs
now contain cached information from Party A - specifically application/data,
context, and extension - we need to copy that over during a fork as well.

Huzzah for unit tests catching this when the context/extension were derived
from a cached value on the CDR instead of on Party A.
........

Merged revisions 422769 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422770 from http://svn.asterisk.org/svn/asterisk/branches/13


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

On some systems, a timeval's tv_sec/tv_usec will be unsigned lont ints, as
opposed to long ints. When the RTP engine formats these as strings, it was
previously formatting them as signed integers, which can result in some
odd negative timestamp values (particularly on 32-bit systems). This patch
formats the values as unsigned long integers.
........

Merged revisions 422766 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422767 from http://svn.asterisk.org/svn/asterisk/branches/13


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

........

Merged revisions 422746 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422747 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The context/extension in a CDR is generally considered the destination of a
call. When looking at a 2-party call CDR, users will typically be presented
with the following:

context    exten      channel     dest_channel app  data
default    1000       SIP/8675309 SIP/1000     Dial SIP/1000,,20

However, if the Dial actually takes place in a Macro, the current behaviour
in 12 will result in the following CDR:

context    exten      channel     dest_channel app  data
macro-dial s          SIP/8675309 SIP/1000     Dial SIP/1000,,20

The same is true of a GoSub:

context    exten      channel     dest_channel app  data
subs       dial_stuff SIP/8675309 SIP/1000     Dial SIP/1000,,20

This generally makes the context/exten fields less than useful.

It isn't hard to preserve these values in the CDR state machine; however, we
need to have something that informs us when a channel is executing a
subroutine. Prior to this patch, there isn't anything that does this.

This patch solves this problem by adding a new channel flag,
AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a
Macro or a GoSub. The CDR engine looks for this value when updating a Party A
snapshot; if the flag is present, we don't override the context/exten on the
main CDR object. In a funny quirk, executing a hangup handler must *not* abide
by this logic, as the endbeforehexten logic assumes that the user wants to see
data that occurs in hangup logic, which includes those subroutines. Since
those execute outside of a typical Dial operation (and will typically have
their own dedicated CDR anyway), this is unlikely to cause any heartburn.

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

ASTERISK-24254 #close
Reported by: tm1000, Tony Lewis
Tested by: Tony Lewis
........

Merged revisions 422718 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422719 from http://svn.asterisk.org/svn/asterisk/branches/13


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

This patch fixes an issue where CDRs would get stuck generating an infinite
number of CDRs, eventually crashing Asterisk (and consuming a lot of memory
along the way).

When a channel enters into a multi-party bridge, the CDR engine creates
mappings of each participant to each other participant, picking the 'A' party
as it goes. So, if we have four channels in a multi-party bridge (Alice, Bob,
Charlie, Denise), we would have something like:

Alice => Bob
Alice => Charlie
Alice => Denise
Bob => Charlie
Bob => Denise
Charlie => Denise

This works fine when participants enter the bridge a single time.

When a participant leaves a bridge, the CDRs for that channel are transitioned
to a finalized state.

The bug occurs if Bob rejoins. When the CDR engine creates mappings between the
channels, it walks through all the participants currently in the bridge, and
realizes that no one in the bridge can create a CDR with the channel (Bob).
As such it creates a new CDR for the candidate and appends it to that
candidate's chain. Unfortunately, on this particular code path, it doesn't
stop traversing the candidate's chain. Since we just added ourselves to the
chain, this causes the loop to keep going, constantly adding new CDRs.

This patch makes it so the engine bails when it creates a CDR match in this
case.

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

ASTERISK-24241 #close
Reported by: Deepak Singh Rawat
Tested by: Deepak Singh Rawat

ASTERISK-24208
Reported by: Frankie Chin
........

Merged revisions 422715 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422716 from http://svn.asterisk.org/svn/asterisk/branches/13


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

* The CHANNEL() audionativeformat, videonativeformat, audioreadformat, and
audiowriteformat now need locking since the media format rework when
accessing the channel's format pointers.

* Increased the buffer size for CHANNEL() audionativeformat and
videonativeformat output strings since the allow=all can be a lengthy
list.

* Tweaked the CHANNEL() XML documentation for secure_bridge_signaling,
secure_bridge_media, and state.

* Ensured the output buffer is initialized for secure_bridge_signaling and
secure_bridge_media.

* Made use the locked_copy_string() macro instead of inlining it for trace
and checkhangup.
........

Merged revisions 422700 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Adds an option to the dial API that marks an outgoing dial as replacing the dialing channel for the purpose of propagating accountcode. When it is used, AST_CHANNEL_REQUESTOR_REPLACEMENT is used instead of AST_CHANNEL_REQUESTOR_BRIDGE_PEER when setting accountcodes on the involved channels with ast_channel_req_accountcodes.

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

Merged revisions 422684 from http://svn.asterisk.org/svn/asterisk/branches/13


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

NULL call IDs were meant to appear as '(none)' but instead were showing
the contents of an uninitialized character buffer.

ASTERISK-24223
Review: https://reviewboard.asterisk.org/r/3979/
........

Merged revisions 422664 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422665 from http://svn.asterisk.org/svn/asterisk/branches/13


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

* In ast_state_chan2dev() use ARRAY_LEN() instead of a sentinel value in
chan2dev[].

* Fix some comments in chan_iax2.c.
........

Merged revisions 422661 from http://svn.asterisk.org/svn/asterisk/branches/13


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

This corrects a situation where menuselect can incorrectly enable a
module by default that has defaultenabled set to "no" and has
failed/non-selected dependencies. The bug is due to an inverted test
when checking for whether the given module should be set to enabled by
default on load.

Review: https://reviewboard.asterisk.org/r/3975/
Reported by: John Bigelow
........

Merged revisions 422646 from http://svn.asterisk.org/svn/asterisk/branches/13


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

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

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

Merged revisions 422625 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 422626 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422631 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The code for changing the Contact header wrongly assumed that the Contact
would always contain a URI. This is incorrect.

ASTERISK-24271
Reported by: Dafi Ni
........

Merged revisions 422557 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422558 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Testsuite tests will occasionally fail because on reception of a 200 OK SIP response,
an AST_CONTROL_ANSWER frame is queued prior to when media has finished being
negotiated. This is because session supplements are called into before PJSIP's
inv_session code has told us that media has been updated. Sometimes the queued answer
frame is handled by the PBX thread before the ensuing media negotiations occur, causing
a test failure.

As it turns out, there is another place that session supplements could be called into, which is
after media has finished getting negotiated. What this commit introduces is a means for session
supplements to indicate when they wish to be called into when handling an incoming SIP response.
By default, all session supplements will be run at the same point that they were prior to this
commit. However, session supplements may indicate that they wish to be handled earlier than
normal on redirects, or they may indicate they wish to be handled after media has been negotiated.

In this changeset, two session supplements have been updated to indicate a preference for when
they should be run: res_pjsip_diversion executes before handling redirection in order to get
information from the Diversion header, and chan_pjsip now handles responses to INVITEs after
media negotiation to fix the race condition mentioned previously.

ASTERISK-24212 #close
Reported by Matt Jordan

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

Merged revisions 422536 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422542 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Internal channels don't have CDRs. Querying the CDR engine for their variables
will make it cranky.
........

Merged revisions 422506 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422507 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When ARI manipulates a bridge, it generally doesn't care what the mixing
technology is. Operations on a bridge initiated through ARI should perform
their action in generally the same way, regardless of the bridge's mixing
technology. While the mixing technology may determine how media flows to
channels, the actual operations on a bridge themselves should be the same.

Currently, this isn't the case with holding bridges. When a channel joins
without a role, MoH is started on that channel automatically. Subsequent bridge
operations that would stop MoH would fail (as there is no Announcer channel
playing MoH to the bridge). Starting MoH on the bridge will also create two
MoH streams: one from the MoH being played on the participant channel, and one
from the announcer channel. From the perspective of ARI users, this is
counter-intuitive - I would not expect MoH to be started for me. The mixing
technology determines how media is shared between participants, not the
application experience.

This patch does the following:
 * The Stasis bridge class now inspects channels as they are going into a
   bridge. If the bridge has a holding capability, and the channel has no
   roles, we give it a participant role and mark the default behaviour to have
   no entertainment. This allows addChannel operations to continue to set a
   participant role with an entertainment option if it felt like it (or could
   do it).
 * The music on hold channel is now Stasis approved (tm)

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

ASTERISK-24264 #close
Reported by: Samuel Galarneau
Tested by: Samuel Galarneau 
........

Merged revisions 422503 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422504 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The ConfbridgeList event doesn't include how long the user has been a
member of the conference.  This patch adds Duration (seconds) which
is based on user->chan->answertime.

Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3955/
........

Merged revisions 422444 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422445 from http://svn.asterisk.org/svn/asterisk/branches/13


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

A WaitEvent issued via an http session isn't respecting eventfilters defined
for the user. I just added a match_filter to the predicate that controls
astman_append.

Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3958/
........

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

Merged revisions 422440 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 422441 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422442 from http://svn.asterisk.org/svn/asterisk/branches/13


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

This patch adds a manpage for the smsq utility. Note that this is one of
the patches the Debian distro applies for the Asterisk project, as per
ASTERISK-24191.

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

ASTERISK-24171 #close
Reported by: Jeremy Laine
patches:
  smsq.8 uploaded by Jeremy Laine (License 6561)
........

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

Merged revisions 422377 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 422378 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422379 from http://svn.asterisk.org/svn/asterisk/branches/13


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

This patch adds a manpage for the aelparse utility. Note that this is one of
the patches the Debian distro applies for the Asterisk project, as per
ASTERISK-24191.

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

ASTERISK-24171 #close
Reported by: Jeremy Laine
patches:
  aelparse.8 uploaded by Jeremy Laine (License 6561)
........

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

Merged revisions 422372 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 422373 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422374 from http://svn.asterisk.org/svn/asterisk/branches/13


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

message was being triggered on configuration reload.
This patch changes that case to just return instead.

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



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

The UniMRCP project distributes Asterisk modules that integrate Asterisk with
UniMRCP, and other Asterisk users use the UniMRCP library as well.
Unfortunately, the UniMRCP license is Apache 2.0, which per the Free Software
Foundation, is not a compatible license with the GPLv2.

"Please note that this license is not compatible with GPL version 2, because it
has some requirements that are not in that GPL version. These include certain
patent termination and indemnification provisions. The patent termination
provision is a good thing, which is why we recommend the Apache 2.0 license for
substantial programs over other lax permissive licenses."

On the other hand, UniMRCP is a great project and we'd like to let people use
it with Asterisk.

This patch updates the LICENSE text to allow users to link Asterisk with
UniMRCP and distribute the resulting binaries.
........

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

Merged revisions 422294 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 422295 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422296 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The reporter on the issue found some issues when upgrading from version 10 to 11
on 55 hosts.

Two situations that can occur with dynamic registrations.

1.  With dnsmgr disabled, if the host is not resolvable we are not trying to
    resolve the host again when it is time to attempt to register again.  This
    results in never registering to the host.
2.  With dnsmgr enabled, when the host is temporarily not resolvable the
    address is set to 0.0.0.0:0 and then when the host is resolvable the port
    is not being restored and stays set to 0.

This patch resolves these two issues by:

* Storing the hostname so that it can be used for resolving with DNS.
* Resolve the hostname on the next scheduled attempt to register.
* Storing the port used to reach the host so that when the hostname is
  resolvable again, we can set the port again if the port is still unset after
  looking up the host.

ASTERISK-23767 #close
Reported by: David Herselman
Tested by: David Herselman, Michael L. Young
Patches:
    asterisk-23767-dns_reg_retry_and_set_port_11_v3.diff
                                     uploaded by Michael L. Young (license 5026)

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

Merged revisions 422274 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 422275 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422276 from http://svn.asterisk.org/svn/asterisk/branches/13


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

........

Merged revisions 422255 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422256 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Users now have the ability to bind the rtpengine instance to a specific IP
address.  For example, you want chan_sip (call control) on eth0 but rtp (media)
on eth1.

ASTERISK-24280 #close
Reported by: Paul Belanger
Tested by: Paul Belanger
Review: https://reviewboard.asterisk.org/r/3952/
Patches:
    rtpengine.diff uploaded by Paul Belanger


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

A misunderstanding of how the scheduler worked caused further batched notifications
beyond the first not to get scheduled. Now we reset our scheduler ID to -1 after
the batched notification is sent. This way, further notifications can be scheduled
when they arise.
........

Merged revisions 422239 from http://svn.asterisk.org/svn/asterisk/branches/13


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

* Fix off nominal ref leak in find_or_create_contact_status().

* Add missing NULL check of status in update_contact_status() and
init_start_time().
........

Merged revisions 422214 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422215 from http://svn.asterisk.org/svn/asterisk/branches/13


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

........

Merged revisions 422200 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Currently there's no way to tell if a user is an admin or not when receiving
the join, leave, mute, unmute and talking events.  This patch adds that
capability.

Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3950/
........

Merged revisions 422176 from http://svn.asterisk.org/svn/asterisk/branches/12
........

Merged revisions 422177 from http://svn.asterisk.org/svn/asterisk/branches/13


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