app_record: Fix bug where using the 'k' option and hanging up would trim 1/4 of a second of the recording.

The Record dialplan function trims 1/4 of a second from the end of recordings in case
they are terminated because of DTMF. When hanging up, however, you don't want this to happen.
This change makes it so on hangup this does not occur.

ASTERISK-24530 #close
Reported by: Ben Smithurst
patches:
 app_record_v2.diff submitted by Ben Smithurst (license 6529)

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

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

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

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


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

The static buffer for codecs when invoking the "core show channeltype" CLI command
did not have enough room for all codecs. This has been extended so it does.

ASTERISK-24542 #close
Reported by: snuffy
patches:
 channeltype-tech.diff submitted by snuffy (license 5024)

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

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


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

Fix the failing /channels/features/test_features_channel_dtmf unit test.

DTMF emulation does not work without a stream of packets to prod the
emulation code.

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

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


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

Any partially collected DTMF digits for a DTMF hook need to be pushed into
the bridge when a channel leaves the bridging system as if there were a
timeout.

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

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

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


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

When shutting down Asterisk that has an active AMI connection, you get
several "failed to extend from %d to %d" messages because use of the
EVENT_FLAG_SHUTDOWN attempts to add all AMI permission strings to the
event.

* Created MAX_AUTH_PERM_STRING to use when creating stack based struct
ast_str variables used with the authority_to_str() and
user_authority_to_str() functions instead of a variety of magic numbers
that could be too small.

* Added a special check for EVENT_FLAG_SHUTDOWN to authority_to_str() so
it will not attempt to add all permission level strings.

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

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

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

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


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

As a result of https://reviewboard.asterisk.org/r/3305, res_sorcery_realtime
was tossing database fields that didn't have an exact match to a sorcery
registered field.  This broke the ability to use regexes as field names which
manifested itself as a failure of res_pjsip_phoneprov_provider which uses
this capability.  It also broke handling of fields that start with '@' in
realtime but I don't think anyone noticed.

This patch does the following...
* Modifies ast_sorcery_fields_register to pre-compile the name regex.
* Modifies ast_sorcery_is_object_field_registered to test the regex if it
  exists instead of doing an exact strcmp.
* Modifies res_pjsip_phoneprov_provider with a few tweaks to get it to work
  with realtime.

Tested-by: George Joseph

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

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

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


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

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

In r428165, two bugs were introduced:

* Prior to entering the features retry loop, the buffer that holds the
  collected digits is wiped. However, this inadvertently wipes out the
  first collected digit on the first pass through, which is obtained
  in ast_stream_and_wait. This caused all of the features tests to fail.
* If ast_app_dtget returns a hangup (-1), the loop would retry incorrectly.
  If we detect a hangup, we have to stop trying the feature.

This patch fixes both issues.

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

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


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

Prior to this commit, the address family of the first item in an ACL
was used to compare all incoming traffic. This could lead to traffic
of other IP address families bypassing ACLs.

ASTERISK-24469 #close

Reported by Matt Jordan
Patches:
	ASTERISK-24469-11.diff uploaded by Matt Jordan (License #6283)

AST-2014-012
........

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

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

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

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


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

The DB dialplan function when executed from an external protocol (for instance
AMI), could result in a privilege escalation.

Asterisk now inhibits the DB function from being executed from an external
interface if the live_dangerously option is set to no.

ASTERISK-24534
Reported by: Gareth Palmer
patches: submitted by Gareth Palmer (license 5169)
........

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

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

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

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


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

The biggest problem this patch fixes is that ACLs weren't previously being
loaded when the res_pjsip_acl module was loaded. Yikes. In addition, the
ACL options contact_permit and contact_acl were effectively interpreted as
contact_deny and this patch fixes that as well.

AST-1418 #close
Reported by: Thomas Thompson
Review: https://reviewboard.asterisk.org/r/4120/

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

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

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


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

Confbridge dialplan function permission escalation via AMI and inappropriate
class authorization on the ConfbridgeStartRecord action. The CONFBRIDGE dialplan
function when executed from an external protocol (for instance AMI), could
result in a privilege escalation. Also, the AMI action “ConfbridgeStartRecord”
could also be used to execute arbitrary system commands without first checking
for system access. The AMI “ConfbridgeStopRecord” has also been updated to
only run under a system authorization.

Asterisk now inhibits the CONFBRIDGE function from being executed from an
external interface if the live_dangerously option is set to no.  Also, the
“ConfbridgeStartRecord” AMI action is now only allowed to execute under a
user with system level access.

ASTERISK-24490
Reported by: Gareth Palmer
........

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

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

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


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

The implementation of INVITE with Replaces in res_pjsip_refer did not expect them to
occur in-dialog. As a result it would incorrectly attempt to hang up a channel it
thought was under its control. In reality the channel would be under the control of
another thread. When the other thread accessed the channel it would be accessing freed
memory and could crash.

This change makes res_pjsip_refer not act on an in-dialog INVITE with Replaces.

ASTERISK-24528 #close
Reported by: Joshua Colp
........

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

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


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

AST-2014-015: Fix race condition in chan_pjsip when sending responses after a CANCEL has been received.

Due to the serialized architecture of chan_pjsip there exists a race condition where a CANCEL may
be received and processed before responses (such as 180 Ringing, 183 Session Progress, and 200 OK)
are sent. Since the session is in an unexpected state PJSIP will assert when this is attempted.

This change makes it so that these responses are not sent on disconnected sessions.

ASTERISK-24471 #close
Reported by: yaron nahum
........

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

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


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

ast_string_fields_copy relies on the fact that
__ast_string_field_release_active never previously
zeroed pool->used, so keeping the existing pointer
was "ok".  Now that existing pools can be reset to
'empty', it is important to set each field to
__ast_string_field_empty after releasing the memory.

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

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

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


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

Accessing members of struct ast_str outside of the string manipulation API
routines is invalid since struct ast_str is supposed to be treated as
opaque.

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

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

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

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


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

Optimistic SRTP is the ability to enable SRTP but not have it be
a fatal requirement. If SRTP can be used it will be, if not it won't be.
This gives you a better chance of using it without having your sessions
fail when it can't be.

Encrypt all the things!

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

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


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

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

There is no guarantee that when we get a Refer-To that it will be NULL terminated.
As the URI parsing function requires it to be we now NULL terminate it.

Additionally parsing the Refer-To as a 'To' header is needless and it can
simply be done as a URI. This also fixes a problem where certain Refer-To headers
would not be parsed as a 'To' header causing the REFER to fail.

ASTERISK-24508 #close
Reported by: Beppo Mazzucato

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

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

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


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

........

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

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


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

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