This patch adds a new operation for stored recordings, copy. It takes an
existing stored recording and makes a copy of it in the same directory
or a relative directory under the stored recording directory.

/ari/recordings/stored/{recordingName}/copy?destinationRecordingName={copy_name}

This is particularly useful for voicemail-esque applications, which may need to
copy or move recordings around a directory structure.

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

ASTERISK-24036 #close
Reported by: Sam Galarneau
Tested by: Sam Galarneau
........

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


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

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

If a reference count goes negative, instead of
just logging that fact, be more helpful with a
backtrace and an assert that will DO_CRASH.

This patch also removes the duplicate ao2_bt()
function and cleans up extraneous usage of the
ast_log_backtrace() call.

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



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

Whenever possible, audiohooks and framehooks will now be copied over
to the channel that the masquerading channel gets cloned into. This
should occur for all audiohooks and most framehooks. As a result,
in Asterisk 12.5 and up, the AUDIOHOOK_INHERIT function is now
deprecated and its behavior is essentially the new default for all
audiohooks, plus some additional audiohooks/framehooks.

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

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


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

Specifically the following equivalents were created:
fax show session -> FAXSession
fax show sessions -> FAXSessions
fax show stats -> FAXStats

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


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

Most channel drivers let you specify a default accountcode to be set on
channels associated with a particular peer/endpoint/object. Prior to this
patch, chan_pjsip/res_pjsip did not support such a setting.

This patch adds a new setting to the res_pjsip endpoint object, 'accountcode'.
When a channel is created that is associated with an endpoint with this value
set, the channel will automatically have its accountcode property set to the
value configured for the endpoint.

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

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

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


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

This patch adds support for the PostgreSQL application_name connection setting.
When the appropriate PostgreSQL module's configuration is set with an
application name, the name will be passed to PostgreSQL on connection and
displayed in the database's pg_stat_activity view, as well as in CSV logs. This
aids in managing which applications/servers are connected to a PostgreSQL
database, as well as tracing the activity of those connections.

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

ASTERISK-23737 #close
Reported by: Gergely Domodi
patches:
  pgsql_application_name.patch uploaded by Gergely Domodi (License 6610)


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

* Create a Stasis bridge sub-class to propagate linkedids and
accountcodes.

* Fixed the basic bridge sub-class to update peeraccount codes when the
number of channels in the bridge drops back down to two parties.

* Refactored ast_bridge_channel_update_accountcodes() to handle channels
joining/leaving the bridge.

* Fixed the basic bridge sub-class to not call the base bridge class pull
method twice.

AFS-105 #close
ASTERISK-23852 #close
Reported by: Richard Mudgett

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

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


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

The dtls_perform_handshake function was mistakenly placed under the guards for
USE_PJPROJECT. If PJPROJECT was not installed, the function would not be
defined, while other functions would attempt to still use it. This prevented
res_rtp_asterisk from being loaded.

ASTERISK-24001 #close
Reported by: Don Fanning
........

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


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

This module implements dialog-info+xml for the purposes of presence. This means
that phones such as Grandstreams can now subscribe to receive presence information
for an extension.

ASTERISK-21443 #close
Reported by: Matt Jordan

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

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


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

This patch fixes two bugs:

1. When originating a channel into a Stasis application, we already create a
   subscription for the channel that is going into our Stasis app.
   Unfortunately, when you create a Local channel and pass it off to a Stasis
   app, you really aren't creating just one channel: you're creating two. This
   patch snags the second half of the Local channel pair (assuming it is a
   Local channel pair, but luckily core_local is kind about such assumptions)
   and subscribes to it as well.

2. Subscriptions are a bit sticky right now. If a subscription is made, the
   'interest' count gets bumped on the Stasis subscription - but unless
   something explicitly unsubscribes the channel, said subscription sticks
   around. This is not much of a problem is a user is creating the subscription
   - if they made it, they must want it. However, when we are creating
   implicit subscriptions, we need to make sure something clears them out.
   This patch takes a pessimistic approach: it watches the cache updates
   coming from Stasis and, if we notice that the cache just cleared out an
   object, we delete our subscription object. This keeps our ao2 container of
   Stasis forwards in an application from growing out of hand; it also is a
   bit more forgiving for end users who may not realize they were supposed to
   unsubscribe from that channel that just hung up.

Review: https://reviewboard.asterisk.org/r/3710/
#ASTERISK-23939 #close
........

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


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

This corrects two issues with the extra field information in Asterisk
12+ in channel event logs.

It is possible to inject custom values into the dialstatus provided by
ast_channel_dial_type() Stasis messages that fall outside the
enumeration allowed for the DIALSTATUS channel variable. CEL now
filters for the allowed values and ignores other values.

The "hangupsource" extra field key is always blank if the far end
channel is a chan_pjsip channel. This is because the hangupsource is
never set for the pjsip channel driver. This change sets the
hangupsource whenever a hangup is queued for chan_pjsip channels.

This corrects an issue with the pjsip channel driver where the
hangupcause information was not being set properly.

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

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


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

Billing records are fair,
To get paid is quite bright,
You should really use ODBC;
Good-bye cdr_sqlite.

Microsoft did once push H.323,
Hell, we all remember NetMeeting.
But try to compile chan_h323 now
And you will take quite a beating.

The XMPP and SIP war was fierce,
And in the distant fray
Was birthed res_jabber/chan_jingle;
But neither to stay.

For everyone did care and chase what Google professed.
"Free Internet Calling" was what devotees cried,
But Google did change the specs so often
That the developers were happy the day chan_gtalk died.

And then there was that odd application
Dedicated to the Polish tongue.
app_saycountpl was subsumed by Say;
One could say its bell was rung.

To read and parse a file from the dialplan
You could (I guess) use an application.
app_readfile did fill that purpose, but I think
A function is perhaps better in its creation.

Barging is rude, I'm not sure why we do it.
Inwardly, the caller will probably sigh.
But if you really must do it,
Don't use app_dahdibarge, use ChanSpy.

We all despise the sound of tinny robots
It makes our queues so cold.
To control such an abomination
It's better to not use Wait/SetMusicOnHold.

It's often nice to know properties of a channel
It makes our calls right
We have a nice function called CHANNEL
And so SIPCHANINFO is sent off into the night.

And now things get odd;
Apparently one could delimit with a colon
Properties from the SIPPEER function!
Commas are in; all others are done.

Finally, a word on pipes and commas.
We're sorry. We can't say it enough.
But those compatibility options in asterisk.conf;
To maintain them forever was just too tough.

This patch removes:

* cdr_sqlite
* chan_gtalk
* chan_jingle
* chan_h323
* res_jabber
* app_saycountpl
* app_readfile
* app_dahdibarge

It removes the following applications/functions:

* WaitMusicOnHold
* SetMusicOnHold
* SIPCHANINFO

It removes the colon delimiter from the SIPPEER function.

Finally, it also removes all compatibility options that were configurable from
asterisk.conf, as these all applied to compatibility with Asterisk 1.4 systems.

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



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

* Removed some incorrect newlines on ast_http_error() messages in
manager.c.

* Removed an incorrect newline in res_ari_channels.c.

Addendum to ASTERISK-23552
........

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


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

Persistent HTTP connection support is needed due to the increased usage of
the Asterisk core HTTP transport and the frequency at which REST API calls
are going to be issued.

* Add http.conf session_keep_alive option to enable persistent
connections.

* Parse and discard optional chunked body extension information and
trailing request headers.

* Increased the maximum application/json and
application/x-www-form-urlencoded body size allowed to 4k.  The previous
1k was kind of small.

* Removed a couple inlined versions of ast_http_manid_from_vars() by
calling the function.  manager.c:generic_http_callback() and
res_http_post.c:http_post_callback()

* Add missing va_end() in ast_ari_response_error().

* Eliminated unnecessary RAII_VAR() use in http.c:auth_create().

ASTERISK-23552 #close
Reported by: Scott Griepentrog

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

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


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

The variables body parameter under the originate and originate with id
operations of the channel resource showed invalid JSON in its description.

The variables body parameter under the userEvent operation of the event
resource made no mention that the custom key/value pairs should be wrapped
in a variables key in order to be added to the custom user event.

ASTERISK-23975 #close

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

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


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

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

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


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

........

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


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

........
res_rtp_asterisk: Add SHA-256 support for DTLS and perform DTLS negotiation on RTCP.

This change fixes up DTLS support in res_rtp_asterisk so it can accept and provide
a SHA-256 fingerprint, so it occurs on RTCP, and so it occurs after ICE negotiation
completes. Configuration options to chan_sip and chan_pjsip have also been added to
allow behavior to be tweaked (such as forcing the AVP type media transports in SDP).

ASTERISK-22961 #close
Reported by: Jay Jideliov

Review: https://reviewboard.asterisk.org/r/3679/
Review: https://reviewboard.asterisk.org/r/3686/
........

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


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

In the abstraction effort, this bit of logic got messed up. We
want to recreate the persistence if things go well, not if things
fail.



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

A number of various PJSIP AMI actions were failing to parse out and place the
ActionID into their responses. This patch updates the various PJSIP actions
such that the passed in ActionID is emitted on any event list complete events,
as well as any intermediate events created as a result of the action.

#ASTERISK-23947 #close
Reported by: Mark Michelson

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

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


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

Thanks to Sean Bright for pointing out that this was missed in #asterisk-dev.
........

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

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


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

When a client takes a long time to process information received from Asterisk,
a write operation using fwrite may fail to write all information. This causes
the underlying file stream to be in an unknown state, such that the socket
must be disconnected. Unfortunately, there are two problems with this in
Asterisk's existing websocket code:
1. Periodically, during the read loop, Asterisk must write to the connected
   websocket to respond to pings. As such, Asterisk maintains a reference to
   the session during the loop. When ast_http_websocket_write fails, it may
   cause the session to decrement its ref count, but this in and of itself
   does not break the read loop. The read loop's write, on the other hand,
   does not break the loop if it fails. This causes the socket to get in a
   'stuck' state, preventing the client from reconnecting to the server.
2. More importantly, however, is that the fwrite in ast_http_websocket_write
   fails with a large volume of data when the client takes awhile to process
   the information. When it does fail, it fails writing only a portion of
   the bytes. With some debugging, it was shown that this was failing in a
   similar fashion to ASTERISK-12767. Switching this over to ast_careful_fwrite
   with a long enough timeout solved the problem.

Note that this version of the patch, unlike r417310 in Asterisk 11, exposes
configuration options beyond just chan_sip's sip.conf. Configuration options
to configure the write timeout have also been added to pjsip.conf and ari.conf.

#ASTERISK-23917 #close
Reported by: Matt Jordan

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

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

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


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

This helps to pave the way for RLS work that is to come.
Since this is a self-contained change and subscription
tests still pass, this work is being committed directly
to trunk instead of a working branch.

ASTERISK-23865 #close
Review: https://reviewboard.asterisk.org/r/3628



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

ASTERISK-23834 #close
Reported by: Richard Kenner
........

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

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


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

Previously module information was not included due to an oversight.

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

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


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

* Added ast_sockaddr_cidr_bits() to count the 1 bits in an ast_sockaddr.
* Added ast_ha_join_cidr() which uses ast_sockaddr_cidr_bits() for the netmask
  instead of ast_sockaddr_stringify_addr.
* Changed res_pjsip_endpoint_identifier_ip to call ast_ha_join_cidr() instead
  of ast_ha_join() for the CLI output.

This is a CLI change only.  AMI was not affected.

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

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


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

........

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

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

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


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

pjpidf_print() does not return < 0 if there is not enough
room for the document to be printed. Rather, it returns
39, the length of the XML prolog.

The algorithm also had a bug in that it would return if
it attempted to grow the string larger.
........

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


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

Currently, music on hold will stop and then start again from the
beginning if ast_moh_start() is called multiple times. This can happen
if a call is put on hold repeatedly (the channel receives multiple
HOLD control frames) and can be triggered from ARI by starting MoH on a
channel multiple times. This is fairly jarring/annoying to users.

This change prevents MoH from being restarted if the requested music
class is the same as the one currently playing.

This includes an extra check to prevent the errors previously
experienced in the testsuite and has 100+ test runs behind it.

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

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

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

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


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

There was a problem when reading a string from the websocket. It assumed the
received data had a null terminator and tried to write the data to an ast_str.
This of course could/would read past the end of the given buffer while
writing the data to the internal buffer of ast_str. Modified the the code to
correctly place a null terminator on the result string.


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

We have faced situation when using CDR and CEL by sqlite3 modules. With system having high load (~100 concurrent calls created by sipp) we found many cdr and cel records missed. There is special finction in sqlite3, that make able to fix this situation - sqlite3_wait_timeout, that also can replace awful code cdr_sqlite3 ad cel_sqlite3 modules. Also this function can be used for aastdb and res_config_sqlite3 to avoid missed writes to sqlite db.

#ASTERISK-23766 #close
Reported by: Igor Goncharovsky

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

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

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

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


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

This patch reverts r416150. When the comparison between mohclass->name and
state->class->name is made, you are not guaranteed that (a) state->class is
non-NULL or that state or state->class are in a safe state.

Crashes caught by the bridges/transfer_capabilities test.
........

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

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

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


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

Add MODULEINFO comment block to define support level core for these new
modules.

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


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

During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
 * AGI execution
 * Returning objects for ARI commands
 * During some Local channel operations
 * During some dialling operations
 * During variable setting
 * During some bridging operations
And more.

This patch does the following:
 - It removes a number of fields from channel snapshots. These fields were
   rarely used, were expensive to have on the snapshot, and hurt performance.
   This included formats, translation paths, Log Call ID, callgroup, pickup
   group, and all channel variables. As a result, AMI Status,
   "core show channel", "core show channelvar", and "pjsip show channel" were
   modified to either hit the live channel or not show certain pieces of data.
   While this is unfortunate, the performance gain from this patch is worth
   the loss in behaviour.
 - It adds a mechanism to publish a cached snapshot + blob. A large number of
   publications were changed to use this, including:
   - During Dial begin
   - During Variable assignment (if no AMI variables are emitted - if AMI
     variables are set, we have to make snapshots when a variable is changed)
   - During channel pickup
   - When a channel is put on hold/unhold
   - When a DTMF digit is begun/ended
   - When creating a bridge snapshot
   - When an AOC event is raised
   - During Local channel optimization/Local bridging
   - When endpoint snapshots are generated
   - All AGI events
   - All ARI responses that return a channel
   - Events in the AgentPool, MeetMe, and some in Queue
 - Additionally, some extraneous channel snapshots were being made that were
   unnecessary. These were removed.
 - The result of ast_hashtab_hash_string is now cached in stasis_cache. This
   reduces a large number of calls to ast_hashtab_hash_string, which reduced
   the amount of time spent in this function in gprof by around 50%.

#ASTERISK-23811 #close
Reported by: Matt Jordan

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

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


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

Currently, music on hold will stop and then start again from the
beginning if ast_moh_start() is called multiple times. This can happen
if a call is put on hold repeatedly (the channel receives multiple
HOLD control frames) and can be triggered from ARI by starting MoH on a
channel multiple times. This is fairly jarring/annoying to users.

This change prevents MoH from being restarted if the requested music
class is the same as the one currently playing.

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

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

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

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


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

........

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


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

Simply establishing a TCP connection and never sending anything to the
configured HTTP port in http.conf will tie up a HTTP connection.  Since
there is a maximum number of open HTTP sessions allowed at a time you can
block legitimate connections.

A similar problem exists if a HTTP request is started but never finished.

* Added http.conf session_inactivity timer option to close HTTP
connections that aren't doing anything.  Defaults to 30000 ms.

* Removed the undocumented manager.conf block-sockets option.  It
interferes with TCP/TLS inactivity timeouts.

* AMI and SIP TLS connections now have better authentication timeout
protection.  Though I didn't remove the bizzare TLS timeout polling code
from chan_sip.

* chan_sip can now handle SSL certificate renegotiations in the middle of
a session.  It couldn't do that before because the socket was non-blocking
and the SSL calls were not restarted as documented by the OpenSSL
documentation.

* Fixed an off nominal leak of the ssl struct in
handle_tcptls_connection() if the FILE stream failed to open and the SSL
certificate negotiations failed.

The patch creates a custom FILE stream handler to give the created FILE
streams inactivity timeout and timeout after a specific moment in time
capability.  This approach eliminates the need for code using the FILE
stream to be redesigned to deal with the timeouts.

This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
the SSL_read/SSL_write operations.

ASTERISK-23673 #close
Reported by: Richard Mudgett
........

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

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

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


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

A remotely exploitable crash vulnerability exists in the PJSIP channel driver's
pub/sub framework. If an attempt is made to unsubscribe when not currently
subscribed and the endpoint's "sub_min_expiry" is set to zero, Asterisk tries
to create an expiration timer with zero seconds, which is not allowed, so an
assertion raised.

The fix was to reject a subscription that is attempting to unsubscribe when not
being already subscribed.  Asterisk now checks for this situation appropriately
and responds with a 400 instead of crashing.

AST-2014-005

ASTERISK-23489 #close
........

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


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

SIP transaction timeouts are handled in the PJSIP monitor thread. When
this happens on a subscription, and the subscription is destroyed, the
subscription destruction is dispatched synchronously to the threadpool.
The issue is that the PJSIP dialog is locked by the monitor thread,
and then the dispatched task attempts to lock the dialog. This leads
to a deadlock that causes SIP traffic to no longer be accepted on the
Asterisk server.

The fix here is to treat the monitor thread as if it were a threadpool
thread when it attempts to dispatch synchronous tasks. This way, the
dispatched task turns into a simple function call within the same thread,
and the locking issue is averted.

AST-2014-008

ASTERISK-23802 #close
........

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


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