This patch adds support for automatically detecting the type of DTMF that a
PJSIP endpoint supports. When the 'dtmf_mode' endpoint option is set to 'auto',
the channel created for an endpoint will attempt to determine if RFC 4733
DTMF is supported. If so, it will use that DTMF type. If not, the DTMF type
for the channel will be set to inband.

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

ASTERISK-24706 #close
Reported by: yaron nahum
patches:
  yaron_patch_3_Feb.diff submitted by yaron nahum (License 6676)


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

While investigating other unload issues I realized that the load/unload process 
for the config wizard was pretty ugly so I've refactored it as follows...

When the res_pjsip sorcery instance is created the config_wizard bumps it's own 
module reference to prevent it from unloading while the sorcery instance is 
still active.  When res_pjsip unloads and it's sorcery instance is destroyed, 
the config wizard unrefs itself which then allows itself to unload cleanly.  
Since the config wizard now can't load after res_pjsip or unload before it 
(which should have been the correct behavior all along), I was able to remove 
the chunks of code in both load_module and unload_module that handled that case.

Ran the testsuite tests to insure there were no functional changes and REF_DEBUG 
to insure that Asterisk was shutting down cleanly with no FRACKs or leaks.

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




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

* Made code easier to follow in bridge_softmix.c:analyse_softmix_stats()
and made some debug messages more helpful.

* Made some debug and warning messages more helpful in
channel.c:set_format().

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


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

Given a source capability of h264 and ulaw, a destination capability of
h264 and g722 then ast_translator_best_choice() would pick h264 as the
best choice even though h264 is a video codec and Asterisk only supports
translation of audio codecs.  When the audio starts flowing, there are
warnings about a codec mismatch when the channel tries to write a frame to
the peer.

* Made ast_translator_best_choice() only select audio codecs.

* Restore a check in channel.c:set_format() lost after v1.8 to prevent
trying to set a non-audio codec.

This is an intermediate patch for a series of patches aimed at improving
translation path choices for ASTERISK-24841.

This patch is a complete enough fix for ASTERISK-21777 as the v11 version
of ast_translator_best_choice() does the same thing.  However, chan_sip.c
still somehow tries to call ast_codec_choose() which then calls
ast_best_codec() with a capability set that doesn't contain any audio
formats for the incoming call.  The remaining warning message seems to be
a benign transient.

ASTERISK-21777 #close
Reported by: Nick Ruggles

ASTERISK-24380 #close
Reported by: Matt Jordan

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

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


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

When the ChannelHold event was added, the 'musicclass' parameter was
erroneously removed. This caused the ChannelHold events to be rejected as
they failed model validation. This patch updates the Swagger schema such that
it now properly reflects the event that is being created.

Hooray for tests that catch things like this.


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

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)
........

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


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

res_pjsip_phoneprov_provider was leaking references to phoneprov objects due to 
a missing OBJ_NODATA in an ao2_callback in load_users().  Rather than adding the 
OBJ_NODATA, I changed load_users to use a more straightforward ao2_iterator.  
This plugged the leak but exposed an unload order issue between 
res_pjsip_phoneprov_provider, res_phoneprov and res_pjsip.

res_pjsip_phoneprov_provider unloads first, then res_phoneprov, then res_pjsip.  
Since res_pjsip_phoneprov_provider uses res_pjsip's sorcery instance, when it 
unloads, it's objects are still in the sorcery instance.  When res_pjsip 
unloads, it destroys all its objects including res_pjsip_phoneprov_provider's.  
The phoneprov destructor then attempts to unregister the extension from 
res_phoneprov but because res_phoneprov is already cleaned up, its users 
container is gone and we get a FRACK.

Simple solution, check for the NULL users container before attempting to remove 
the entry. Duh.

Ran tests/res_phoneprov/res_phoneprov_provider.  No leaks in 
res_pjsip_phoneprov_provider and no FRACKs.

Reported-by: Corey Farrell
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4608/
ASTERISK-24935 #close



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

Until we have a true module management facility it's sometimes necessary for one 
module to force a reload on another before its own load is complete.  If 
Asterisk isn't fully booted yet, these reloads are deferred.  The problem is 
that asterisk reports fully booted before processing the deferred reloads which 
means Asterisk really isn't quite ready when it says it is.

This patch moves the report of fully booted after the processing of the deferred 
reloads is complete.

Since the pjsip stack has the most number of related modules, I ran the 
channels/pjsip testsuite to make sure there aren't any issues.  All tests 
passed.

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



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

Added a new CLI command for res_pjsip that shows both global and system
configuration settings: pjsip show settings

ASTERISK-24918 #close
Reported by: Scott Griepentrog
Review: https://reviewboard.asterisk.org/r/4597/


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

* Increased warning message format capability string buffer size in
iax2_request().

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


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

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


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

This patch adds a new session supplement that handles in-dialog OPTIONS
requests. Said OPTIONS requests are sent a 200 OK, as an endpoint lookup
for the OPTIONS request would already have been done by the time the
session supplement receives the inbound request.

ASTERISK-24862 #close
Reported by: yaron nahum
patches:
  res_pjsip_dlg_options.c submitted by yaron nahum (License 6676)


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434506 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.
 * res_pjsip_exten_state: Use a temporary value to cache the return of
   ast_hint_presence_state
 * res_stasis_playback: Fix enum comparisons where the enum can never be
   negative
 * res_stasis_recording: Add an enum value for the case where the recording
   operation is in error; fix enum comparisons
 * resource_bridges: Use enum value as opposed to -1
 * resource_channels: Use enum value as opposed to -1

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

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


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

Although it only occurred once, a crash occurred when a queue attempted to
evaluate a queue penalty rule that appeared to have already been destroyed.
In many locations in app_queue, a test is done to see if qe->pr is NULL;
however, when we dispose of a queue's penalty rules, we don't set the pointer
to NULL after free'ing it. This patch does that to prevent any dangling
pointers from lingering on the queue object.

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

ASTERISK-23319 #close
Reported by: Vadim
patches:
  rb4552.patch submitted by Stefan Engström (License 6691)
........

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


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

Without this patch, if a PJSIP endpoint with udptl enabled and authentication
set attempted to use sendFax, the FAX session would fail during setup. This
was because the invite issued in response to being auth challenged would cause
the PJSIP channel performing the FAX to receive a second T38 framehook and
this would cause frames to be consumed in an inappropriate manner.

ASTERISK-24933 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4577/


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

When a channel enters the bridging system it is first made compatible with
the bridge and then the bridge technology makes the channel compatible
with the technology.  For all but the DAHDI native and softmix bridge
technologies the make channel compatible with the bridge step is an
effective noop because the other technologies allow all audio formats.
For the DAHDI native bridge technology it doesn't matter because it is not
an initial bridge technology and chan_dahdi allows only one native format
per channel.  For the softmix bridge technology, it is a noop at best and
harmful at worst because the wrong translation path could be setup if the
channel's native formats allow more than one audio format.

This is an intermediate patch for a series of patches aimed at improving
translation path choices.

* Removed code dealing with the unnecessary step of making the channel
compatible with the bridge.

ASTERISK-24841
Reported by: Matt Jordan

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


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

When registering to a SIP server with TLS, Asterisk will accept CA signed
certificates with a common name that was signed for a domain other than the
one requested if it contains a null character in the common name portion of
the cert. This patch fixes that by checking that the common name length
matches the the length of the content we actually read from the common name
segment. Some certificate authorities automatically sign CA requests when
the requesting CN isn't already taken, so an attacker could potentially
register a CN with something like www.google.com\x00www.secretlyevil.net
and have their certificate signed and Asterisk would accept that certificate
as though it had been for www.google.com - this is a security fix and is
noted in AST-2015-003.

ASTERISK-24847 #close
Reported by: Maciej Szmigiero
Patches:
 asterisk-null-in-cn.patch submitted by mhej (license 6085)
........

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

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


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

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

Don't mix declarations and code


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

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


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

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


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

This patch fixes several warnings pointed out by the clang compiler.
* chan_pjsip: Removed check for data->text, as it will always be non-NULL.
* app_minivm: Fixed evaluation of etemplate->locale, which will always
  evaluate to 'true'. This patch changes the evaluation to use
  ast_strlen_zero.
* app_queue:
  - Fixed evaluation of qe->parent->monfmt, which always evaluates to
    true. Instead, we just check to see if the dereferenced pointer
    evaluates to true.
  - Fixed evaluation of mem->state_interface, wrapping it with a call to
    ast_strlen_zero.
* res_smdi: Wrapped search_msg->mesg_desk_term with calls to ast_strlen_zero.

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

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

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


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

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

A change in r430179 inserted a variable near the top of a
structure caused a problem when running DPMA in a version
of Asterisk compiled across the change.  This patch moves
the new variable to the end of the structure, eliminating
the problem.

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

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


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

After completing an attended transfer the transfer target channel (the one that
gets swapped out) was not being hung up after leaving the bridge. This resulted
in a channel possibly being left around. Added an explicit softhangup for the
channel in question after the transfer is successfully completed in order to
make sure the channel is hung up.

ASTERISK-24782 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4575/



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

If we receive a MESSAGE request that we cannot send a response
to, we should not send the incoming MESSAGE to the dialplan.

This commit should help the bouncing message_retrans test to
pass consistently.



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

For some applications - such as SLA - a phone pressing hold should not behave
in the fashion that the Asterisk core would like it to. Instead, the hold
action has some application specific behaviour associated with it - such as
disconnecting the channel that initiated the hold; only playing MoH to channels
in the bridge if the channels are of a particular type, etc.

One way of accomplishing this is to use a framehook to intercept the
hold/unhold frames, raise an event, and eat the frame. Tasty. This patch
accomplishes that using a new dialplan function, HOLD_INTERCEPT.

In addition, some general cleanup of raising hold/unhold Stasis messages was
done, including removing some RAII_VAR usage.

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

ASTERISK-24922 #close


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

This patch fixes a bug in a unit test in func_math where a variable could be
passed to ast_free that wasn't allocated. This patch corrects the issue and
ensures that we only attempt to free a variable if we previously allocated
it.

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

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

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


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

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


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

When setting the configuration option 'timers' equal to 'no' the bit flag was
not properly negated. This patch clears all associated flags and only sets the
specified one. pjsip will handle any necessary flag combinations. Also went
ahead and did similar for the '100rel' option.

ASTERISK-24910 #close
Reported by: Ray Crumrine
Review: https://reviewboard.asterisk.org/r/4582/


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

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


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

This patch fixes a warning caught by clang, in which it detected that large
chunks of extconf were unused. Frankly, I wish we could pretend that all of
extconf was unused, but alas, that is not yet the case.

A few extraneous functions in the parking tests were removed as well, for
the same reason.

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

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

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


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

This patch fixes a warning caught by clang, in which a char pointer could be
assigned to before it was initialized. The patch re-organizes the code to
ensure that the pointer is always initialized, even on off nominal paths.

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

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

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


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

This patch fixes an invalid format specifier used in the formatting of an
ERROR message in the framehook code. The format specifier specifies a
type of 'unsigned short', but the argument passed to it is of type 'int'.
The patch changes the format specifier to 'i'.

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

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

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


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

Versions of Asterisk prior to 12 defaulted to 8000 as a sample rate
if one was not provided by a format. In Asterisk 13, this was removed.
The result was that some calculations which involve dividing by the
sample rate resulted in dividing by 0. The fix being put in place
here is to have the same default fallback that was present in previous
versions of Asterisk.

Asterisk-24914 #close
Reported by Marcello Ceschia



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

res_pjsip_phoneprov_provider is using ao2_callback with OBJ_MULTIPLE, then
ignoring the return.  OBJ_NODATA flag was to prevent a reference leak, but
this caused the module to FRACK on unload.  Revert change until this can
be investigated further.

ASTERISK-24935
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4578/


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

This is a change to align behavior with that of Asterisk 11 and previous versions.
In those versions, if a parked call were retrieved, and the call ended, the parked
call retriever would be hung up after the ParkedCall application ran. Prior to this
patch, in Asterisk 13, the same situation would result in the parked call retriever
falling through to additional priorities in the extension where the ParkedCall
application was called. With this patch, the behavior between Asterisk 11 and 13
aligns.

ASTERISK-24899 #close
Reported by Malcolm Davenport
Patches:
	ASTERISK-24899.patch uploaded by Mark Michelson(license #5049)



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

res_pjsip_phoneprov_provider was using ao2_callback with OBJ_MULTIPLE, then
ignoring the return.  Added OBJ_NODATA flag to prevent a reference leak.

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


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

Outbound SIP MESSAGEs had the potential to be sent out
of order from how they were specified in a set of
dialplan steps.

This change creates a serializer for sending outbound
MESSAGE requests on. This ensures that the MESSAGEs are
sent by Asterisk in the same order that they were sent
from the dialplan.

ASTERISK-24937 #close
Reported by Mark Michelson

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



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

A change in r430179 inserted a variable near the top of a
structure caused a problem when running DPMA in a version
of Asterisk compiled across the change.  This patch moves
the new variable to the end of the structure, eliminating
the problem.

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



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