This allows for a configurable number of attempts for a transferer
to dial an extension to transfer the call to. For Asterisk 13, the
default values are such that upgrading between versions will not
cause a behaivour change. For trunk, though, the defaults will be
changed to be more user-friendly.

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

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


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

If transmit_refer is called when p->refer is already allocated,
it leaks the previous allocation.  Updated code to always free
previous allocation during a new allocation.  Also instead of
checking if we have a previous allocation, always create a
clean record.

ASTERISK-15242 #close
Reported by: David Woolley
Review: https://reviewboard.asterisk.org/r/4160/
........

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

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

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


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

When r428077 was made for ASTERISK-24522, it failed to take into account users
who are neither wait_marked nor end_marked. These users are *also* supposed to
hear the 'leader has left the conference' message. Granted, this behaviour is
a bit odd; however, that is how it used to work... and behaviour changes are
not good.

This patch ensures that if there are any 'normal' users present when the last
marked user leaves the conference, the message will still be played to them.

Note that this regression was caught by the Asterisk Test Suite's
confbridge_nominal test, which has a quirky combination of users.
........

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

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

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


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

Consider the following:
- A marked user in a conference
- One or more end_marked only users in the conference

When the marked users leaves, we will be in the conf_state_multi_marked state.
This currently will traverse the users, kicking out any who have the end_marked
flags. When they are kicked, a full ast_bridge_remove is immediately called on
the channels. At this time, we also unilaterally set the need_prompt flag.

When the need_prompt flag is set, we then playback a sound to the bridge
informing everyone that the leader has left; however, no one is left in the
bridge. This causes some odd behaviour for the end_marked users - they are
stuck waiting for the bridge to be unlocked. This results in them waiting for
5 or 6 seconds of dead air before hearing that they've been kicked.

Unfortunately, we do have to keep the bridge locked while we're playing back
the 'leader-has-left' prompt. If there are any wait_marked users in the
conference, this behaviour can't be easily changed - but we do make the case
of the end_marked users better with this patch.

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

ASTERISK-24522 #close
Reported by: Matt Jordan
........

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

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

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


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

The AOR value may contain the name of an AOR or a full SIP URI.
Checking if the AOR exists can't be done as a result of this.
........

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

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


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

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

This patch adds microsecond precision when inserting a CEL record into a table
with an "eventtime" column of type timestamp, instead of second precision. The
documentation (configs/cel_odbc.conf.sample) was already saying that the
eventtime column included microseconds precision, but that was not the case.

Also, without this patch, if you had a table with an "eventtime" column of
type varchar, you had millisecond precision. With this patch, you also get
microsecond precision in this case.

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

ASTERISK-24283 #close
Reported by: Etienne Lessard
patches:
  cel_odbc_time_precision.patch uploaded by Etienne Lessard (License 6394)
........

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

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

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


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

ASTERISK-24499 #close
Reported by: Rusty Newton
........

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

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


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

For chan_motif the direct return value of the underlying config options framework
was passed back. This can relay various states which the module loader would not
interpet as success. It has been changed so only on errors will it report back
an error.

For chan_pjsip the code implemented a dummy reload function which always
returned an error. This has been removed as all configuration is held within
res_pjsip instead.

ASTERISK-23651 #close
Reported by: Rusty Newton
........

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

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


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

res_pjsip: Enforce requirements for session timer minimum expiration period and normal expiration period.

This change enforces the requirements in PJSIP for session timer configuration. The minimum
expiration period must be 90 seconds or higher and the normal expiration period can not
be lower than the minimum expiration period. If either of these were done the code would
assert at session setup time.

ASTERISK-24336 #close
Reported by: Leon Rowland
........

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

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


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

Configuration of DTLS in the general section will be applied to any users
or peers. If configuration exists at their level it overrides the general
section values.

ASTERISK-24128 #close
Reported by: Michael K.
patches:
  dtls_default_settings.patch submitted by Michael K. (license 6621)

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


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

If the test fails due to memory allocation errors, we may as well attempt to
unlock the bridge on the way out.
........

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


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

ASTERISK-24279 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4109/
........

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

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


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

When sending the USERNAME attribute in an RTP STUN
response, the implementation in append_attr_string
passed the actual length, instead of padding it up
to a multiple of four bytes as required by the RFC
3489.  This change adds separate variables for the
string and padded attributed lengths, and performs
padding correctly.

Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/4139/
........

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

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

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


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

From reviewboard:

"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?

The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."

The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.

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

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

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


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

Currently if the leader of a conference bridge leaves any participant
that has musiconhold enabled will not hear the "leader has left" sound.
This is because musiconhold is started and THEN the sound is played.

This change makes it so that the sound is played and THEN musiconhold
is started. This provides a better experience for users as they may not
have known previously why they went back to musiconhold.

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

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

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

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


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

This is the Asterisk 13 version of the patch. The main difference is in the pubsub
code since it was completely refactored between Asterisk 12 and 13.

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

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


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

When using a non-default sorcery wizard (in this instance realtime) for
outbound registrations and after adding in an appropriate call to
ast_sorcery_apply_config() (since it is missing) Asterisk will crash after
a stack overflow occurs due to the code infinitely recursing.  The fix entails
removing the outbound registration state dependency from the outbound
registration sorcery object and instead keeping an in memory container that
can be used to lookup the state when needed.

ASTERISK-24514
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4164/
........

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

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


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

This change corrects message ordering in cases where a channel-related
message can be received after a Stasis/ARI application has received the
StasisEnd message. The StasisEnd message was being passed to
applications directly without waiting for the channel topic to empty.

As a result of this fix, other bugs were also identified and fixed:
* StasisStart messages were also being sent directly to apps and are
  now routed through the stasis message bus properly
* Masquerade monitor datastores were being removed at the incorrect
  time in some cases and were causing StasisEnd messages to not be sent
* General refactoring where necessary for the above
* Unsubscription on StasisEnd timing changes to prevent additional
  messages from following the StasisEnd when they shouldn't

A channel sanitization function pointer was added to reduce processing
and AO2 lookups.

Review: https://reviewboard.asterisk.org/r/4163/
ASTERISK-24501 #close
Reported by: Matt Jordan
........

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

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


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

Asterisk - in res_rtp_asterisk - only understands a single RTCP report info
block. When the RTCP information was refactored in the RTP Engine to be pushed
over the Stasis message bus, I put in the hooks into the engine to handle
multiple RTCP report info blocks, in the hope that a future RTP implementation
would be able to provide that data. Unfortunately, res_rtp_asterisk has a
tendency to "lie":
(1) It will send RTCP reports with a reception_report_count greater than 1
    (which is pulled directly from the RTCP packet itself, so that part is
    correct)
(2) It will only provide a single report block

When the rtp_engine goes to convert this to a JSON blob, hilarity ensues as it
looks for a report block that doesn't exist.

This patch updates the rtp_engine to be a bit more skeptical about what it is
presented with. While this could also be fixed in res_rtp_asterisk, this patch
prefers to fix it in the engine for two reasons:
(1) The engine is designed to work with multiple RTP implementation, and hence
    having it be more robust is a good thing (tm)
(2) res_rtp_asterisk's handling of RTCP information is "fun". It should report
    the correct reception_report_count; ideally it should also be giving us all
    of the blocks - but it is *definitely* not designed to do that. Going down
    that road is a non-trivial effort.

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

ASTERISK-24489 #close
Reported by: Gregory Malsack
Tested by: Gregory Malsack

ASTERISK-24498 #close
Reported by: Beppo Mazzucato
Tested by: Beppo Maazucato
........

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

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


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

Add missing reference cleanup for newly created bridge.

ASTERISK-24281
Reported by: Stefan Engström
Review: https://reviewboard.asterisk.org/r/4154/
........

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

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


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

If during the operation of adding an extension a priority is added but
fails it is possible for the extension to be freed but still exist in
the PBX core. If this occurs subsequent lookups may try to access the
extension and end up in freed memory.

This change removes the extension from the PBX core when the priority
addition fails and then frees the extension.

ASTERISK-24444 #close
Reported by: Leandro Dardini

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

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

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

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


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

When DONT_OPTIMIZE is enabled with dev-mode, it causes a shadow compilation
to be done with output to /dev/null.  This can cause errors with coverage
when GCC attempts to write to /dev/null.gcno.  This change disables
coverage for the shadow compilation.

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

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

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

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


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

Fix reference leak that happens if (session && !blastaway).

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

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

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

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


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

In r227276, a while loop was turned into a for loop. Unfortunately, a portion
of the while loop was left in the code such that, when a static gateway is
encountered in the list of MGCP gateways, the next gateway would be skipped.
At best, we would simply flip past a gateway; at worst, this could lead to a
crash.

ASTERISK-24500 #close
Reported by: Xavier Hienne
patches:
  chan_mgcp.patch uploaded by Xavier Hienne (License 6657)
........

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

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

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


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

When UCS2 character encoding is used, one symbol in national language can be
expanded to 4 bytes. The current buffer used for receiving message in
do_monitor_phone is 256 bytes, which is not large enough for incoming messages.

For example:
* AT+CMGR phone response prefix
  '+CMGR: "REC UNREAD","+7**********",,"14/10/29,13:31:39+12"\r\n' - 60 bytes
* SMS body with UCS2 encoding (max) - 280 bytes
* AT+CMGR phone response suffix '\r\n\r\nOK\r\n' - 8 bytes
* Terminating null character - 1 byte

This results in a needed buffer size of 349 bytes. Hence, this patch opts for a
350 byte buffer.

ASTERISK-24468 #close
Reported by: Dmitriy Bubnov
patches:
  chan_mobile-1_8.diff uploaded by Dmitriy Bubnov (License 6651)
  chan_mobile-trunk.diff uploaded by Dmitry Bubnov (License 6651)
........

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

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

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


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

An issue existed in r420577, which added multiple recipients to voicemail
emails. The patch, when looking at the intended recipients, looked ahead for
the '|' character inside a while loop which already had pulled out the
appropriate field parsing on the '|' character. This would cause it to skip
the recipients.

This patch fixes it such that it relies completely on the while loop to parse
through the e-mail fields.

Note that the original author of the patch looked at this fix and approved it.

ASTERISK-24250 #close
Reported by: abelbeck
patches:
  voicemail-420577-to-comma-fix.diff uploaded by abelbeck (License 5903)
........

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


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

After r425242 the fax/sip/directmedia_reinvite_t38 test started failing due to
the surviving channel not being re-INVITEd back from T.38 to audio. This patch
fixes that bug - a deeper explanation of what happened follows.

When two RTP channels are in a native bridge, the bridging layer will
investigate each via the get_rtp_info glue callback. This callback returns the
native bridge preference of the channel *at that moment in time* (that part is
key). At different points during the bridging, the native bridging layer will
inform the RTP capable channels of the status of the bridge via the update_peer
glue callback.

In a T.38 scenario with audio direct media, the sequence of events will often
look like the following:
 * SIP/A and SIP/B both have audio and enter a native bridge.
 * Asterisk re-INVITEs audio between SIP/A and SIP/B directly (via an
   update_peer callback).
 * SIP/A sends a re-INVITE to T.38, which causes Asterisk to send a re-INVITE
   to T.38 to SIP/B. Assuming everyone 200 OKs the process, the UDPTL stack
   receives UDPTL packets in Asterisk from both endpoints. From the perspective
   of the channels, we are now in a local bridge for T.38, even though we are
   technically still in a remote bridge in bridge_native_rtp. (YAY!)
 * When one side hangs up, bridge_native_rtp is told to stop bridging. It then
   re-evaluates the channels and asks them how they are bridged - and since
   T.38 is enabled, they reply with a Local bridge (which is correct), but is
   wrong because the audio portion is still technically in a remote bridge.
 * Asterisk releases the surviving channel, whose audio is *not* re-INVITED
   back to Asterisk as bridge_native_rtp incorrectly assumes that it was in a
   local bridge.

Ironically, prior to r425242, this used to work mostly due to a fluke in the
bridging layer.

The purpose of the get_rtp_info callback shouldn't be modified: it should tell
the bridging layer what kind of bridge the channel prefers at that moment in
time. If you have T.38 enabled, that *must* be a local bridge, as the UDPTPL
stack must be in the media path. As such, this patch does not modify that
part of the code.

However, we have to tell the channels to re-evaluate themselves when they come
out of a native bridge, since we can no longer trust the get_rtp_info callbacks
when the native bridge is being stopped. Something else may have changed in the
channels, and they may now be lying to us. As such, this patch makes it so that
we unilaterally tell the channels that they are no longer bridged via the
update_peer callback. This is actually what the channels expect anyway: code in
both chan_sip and chan_pjsip's callbacks look at the T.38 state and - if they
were in T.38 - send a re-INVITE to get the audio back to Asterisk.

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

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

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


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

Fix a bunch of calls to get_active_pvt
where the reference is never released.

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

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

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

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


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

Made agent able to interrupt the alerting beep playback with DTMF.  Any
digit can interrupt if the call does not need to be acknowledged.  Only
the first digit of the acknowledgement can interrupt if the call needs to
be acknowledged.  The agent interrupting the alerting playback builds on
the ASTERISK-24447 patch because it knows what digit interrupted the
playback and needs to be able to pass that digit to the DTMF hook digit
collection code.

ASTERISK-24257 #close
Reported by: Steve Pitts

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

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

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


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

* Made collecting DTMF digits for the DTMF feature hooks pass frames from
the bridge.

* Made collecting DTMF digits possible by other bridge hooks if there is a
need.

ASTERISK-24447 #close
Reported by: Richard Mudgett

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

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

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


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

When handling incoming messages we determine if it is associated with
a dialog. If so we use that to determine what serializer and endpoint
to use for the message. Previously this would pass the endpoint to the
endpoint lookup module to actually place the endpoint completely on the
message. For in-dialog responses, however, this did not occur as
dialog processing took over and the endpoint lookup did not occur.

This change just places the endpoint in the expected spot immediately
instead of relying on the endpoint lookup module. In-dialog responses
thus have the expected endpoint.

AST-1459 #close

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

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

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


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

fn_wrapper only adds a reference to the format's module if the file
was able to be opened.  If not this causes an unmatched
ast_module_unref in filestream_destructor.  Move ast_module_ref to
get_stream.

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

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

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

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


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

Add missing unreference in hepv3_send_packet.

ASTERISK-24491 #close
Reported by: Zane Conkle
Tested by: Zane Conkle
Review: https://reviewboard.asterisk.org/r/4150/
........

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

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


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

* Fix missing / unreachable calls to __ast_string_field_release_active.
* Reset pool->used to zero when the current pool->active reaches zero.

ASTERISK-24307 #close
Reported by: Etienne Lessard
Tested by: ibercom, Etienne Lessard
Review: https://reviewboard.asterisk.org/r/4114/
........

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

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

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

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


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

Since unit tests are run with DO_CRASH, those tests were causing
the test to fail.

Tested-by: George Joseph
........

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

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

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


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

Testing has shown repeatedly that PJSIP's default behavior of switching
automatically to TCP for large messages can cause issues. The most common
issues are that devices that we are communicating with do not handle the
switch to TCP gracefully, thus causing situations such as broken calls or
broken subscriptions. Now, in order to have this behavior happen, you must
opt into it. The sample file has been updated to warn that enabling the
TCP switch behavior may cause issues for you, so use at your own risk.
........

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


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

This change adds a bit of logging so if the local DNS is misbehaving it is easier
to track down what is going on and where Asterisk may be hanging.

ASTERISK-24438 #close
Reported by: Melissa Shepherd

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

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

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


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

When a config file is read, an unescaped semicolon signals comments which are
stripped from the value before it's stored.  Escaped semicolons are then
unescaped and become part of the value.  Both of these behaviors are normal
and expected.  When the config is serialized either by 'dialplan save' or
AMI/UpdateConfig however, the now unescaped semicolons are written as-is.
If you actually reload the file just saved, the unescaped semicolons are
now treated as start of comments.

Since true comments are stripped on read, any semicolons in
ast_variable.value must have been escaped originally.  This patch
re-escapes semicolons in ast_variable.values before they're written to
file either by 'dialplan save' or config/ast_config_text_file_save which
is called by AMI/UpdateConfig. I also fixed a few pre-existing formatting
issues nearby in pbx_config.c

Tested-by: George Joseph
ASTERISK-20127 #close

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

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

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


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

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