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

........

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


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

Egads. Another bad deletion of too much when attempting to remove h323 stuff.



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

The previous patch (r418034) fixed the 'glitch' that the channels/h323
Makefile no longer existed. Unfortunately, removing the entire line was a bit
of a blunder, as it meant that build_tools/menuselect-deps was never
generated. Hilarity ensued when actually trying to compile.

But hey! At least configure worked.

This patch fixes *that* glitch, and removes some more of the vestiges of h323.
(It had tendrils in the main Makefile? Crazy.)



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

This simply removes that check from the configure script, as r418019 removed
chan_h323.


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

The new inband_on_setup_ack option causes Asterisk to assume inband audio
may be present when a SETUP_ACKNOWLEDGE message is received.

Q.931 Section 5.1.3 says that in scenarios with overlap dialing, when a
dialtone is sent from the network side, progress indicator 8 "Inband info
now available" MAY be sent to the CPE if no digits were received with the
SETUP.  It is thus implied that the ie is mandatory if digits came with
the SETUP and dialtone is needed.  This option should be enabled, when the
network sends dialtone and you want to hear it, but the network doesn't
send the progress indicator when needed.

NOTE: For Q.SIG setups this option should be enabled when outgoing overlap
dialing is also enabled because Q.SIG does not send the progress indicator
with the SETUP ACK.

The commit -r413714 (AST-1338) which causes this issue was dealing with a
SIP-to-ISDN interoperability issue.

This commit is a merge of the two patches indicated below.

ASTERISK-23897 #close
Reported by: Pavel Troller
Patches:
      pri-4.diff (license #6302) patch uploaded by Pavel Troller
      jira_asterisk_23897_v11.patch (license #5621) patch uploaded by rmudgett

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

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

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

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


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

Adds the following AMI commands:
PRIDebugSet - Set PRI debug levels for a specific span
PRIDebugFileSet - Set the file used for PRI debug message output
PRIDebugFileUnset - Disables file output for PRI debug messages

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


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

Adds two new manager commands to pbx_config - DialplanExtensionAdd and
DialplanExtensionRemove which allow manager users to create and delete
extensions respectively.

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417910 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 patch for ASTERISK-23905 that added PFS support in Asterisk depends on the
elliptic curve library support being present in OpenSSL. As it turns out, some
versions of OpenSSL don't have this library - notably the version running on
our build agents.

This patch fixes the build by providing a configure check for the specific
library calls that the PFS patch relies on.

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


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

This patch updates the api.wiki.mustache template and the swagger_model python
script to understand if an operation has a body parameter. If an operation
does have a body parameter, it will now be displayed in the corresponding
wiki entry.
........

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


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

Install a hook script for DAHDI to register new spans with Asterisk
automatically by running:

  asterisk -rx 'dahdi create channel FIRST LAST'

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


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

This patch enables Perfect Forward Secrecy (PFS) in Asterisk's core TLS API.
Modules that wish to enable PFS should consider the following:

- Ephemeral ECDH (ECDHE) is enabled by default. To disable it, do not
  specify a ECDHE cipher suite in a module's configuration, for example:
  tlscipher=AES128-SHA:DES-CBC3-SHA

- Ephemeral DH (DHE) is disabled by default. To enable it, add DH parameters
  into the private key file, i.e., tlsprivatekey. For an example, see the
  default dh2048.pem at
http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098-35.1/src/apps/dh2048.pem?txt

- Because clients expect the server to prefer PFS, and because OpenSSL sorts
  its cipher suites by bit strength, (see "openssl ciphers -v DEFAULT")
  consider re-ordering your cipher suites in the conf file. For example:
tlscipher=AES128+kEECDH:AES128+kEDH:3DES+kEDH:AES128-SHA:DES-CBC3-SHA:-ADH:-AECDH
  will use PFS when offered by the client. Clients which do not offer PFS
  fall-back to AES-128 (or even 3DES as recommend by RFC 3261).

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

ASTERISK-23905 #close
Reported by: Alexander Traud
patches:
  tlsPFS_for_HEAD.patch uploaded by Alexander Traud (License 6520)
  tlsPFS.patch uploaded by Alexander Traud (License 6520)



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

A loop in ast_careful_fwrite exists that will continually attempt to write to
a file stream, even in the presence of EAGAIN/EINTR errors. However, if a
connection that uses ast_careful_fwrite closes suddenly, ast_careful_fwrite's
call to fflush may return EAGAIN/EINTER along with EOF. A subsequent call to
fflush will return EOF but not clear errno, resulting in an infinite loop.

This patch clears errno after it is detected and handled the loop, such that
any subsequent call to fflush will not get erroneously stuck.

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

#ASTERISK-23984 #close
Reported by: Steve Davies
patches:
  fflush_loop_fix uploaded by one47 (License 5012)
........

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

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

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


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

Not sure why that change to ast_channel_alloc was made but ... okay.


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

This patch adds support for the Japanese language to both the say family of
applications, as well as for VoiceMail and VoiceMailMain. A new pack of
language sounds will be released at the same time as the next major version
of Asterisk to support the new language features.

The language features can be enabled using a language code of 'ja'.

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

ASTERISK-23324 #close
Reported by: Kevin McCoy
patches:
  app_voicemail.c.20140226.jb.patch uploaded by Kevin McCoy (License 6586)
  say.c.20140226.jb.patch uploaded by Kevin McCoy (License 6586)



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

This patch is essentially a backport of a small portion of r397526 from
ASTERISK-21981. In that patch, pass through support and format attribute
negotiation was added for Opus. Part of that included being more tolerant to
whitespace in the fmtp line of an SDP; that part of the patch is being
applied here.

As the author of the backport pointed out, in SDP, the fmtp line is allowed to
include whitespace between attributes. RFC 3267 chapter 8.3 (from 2001)
includes an example for this. This was not removed in the updated RFC 4867 in
2007.

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

#ASTERISK-23916 #close
Reported by: Alexander Traud
patches:
  sdpFMTPspace_Asterisk11.patch uploaded by Alexander Traud (License 6520)
........

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

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

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


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

In v12+ the type values from the table are only used by the CEL unit
tests.  Since the unit tests were only comparing a generated expected
event with a real event to see if the ie contents matched and using the
same table IE_PLTYPE values to read the event contents, the type
mismatches were not detected.
........

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


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

This change ensures that __ao2_ref_debug writes to ref_log when given a
non-NULL pointer to an invalid ao2 object.  This is to ensure that we
record any attempt manipulate references of already freed objects.

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

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

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

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


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

When processing a 212MB refs file, refcounter.py used over 3GB of RAM.
This change greatly reduces memory usage in two ways:

* Saving object history in whole lines instead of separated values.
* Not saving normal/skewed/leaked object lists unless they are requested.

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

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

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

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


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

Update the CEL unit tests that handle BRIDGE_ENTER and BRIDGE_EXIT
events to expect the "bridge_technology" extra field key.


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

Add missing CHANGES changes from r417361 and r417383.


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

This will drive the test on review r3419. Note that the patch for this was
done by Ben Ford, although it was slightly modified for this commit.

ASTERISK-23562
Reported by: Matt Jordan
........

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


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

Add the "bridge_technology" extra field key to BRIDGE_ENTER and
BRIDGE_EXIT CEL events to convey the bridge technology in use at the
time the record was generated.


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

This patch allows the current owner of a channel to define various
feature hooks to be made available once the channel has entered a
bridge. This includes any hooks that are setup on the
ast_bridge_features struct such as DTMF hooks, bridge event hooks
(join, leave, etc.), and interval hooks.

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


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

This patch enables the jack-audiohook to cope with dynamic sampling rates from
and to Asterisk. Information from the channel is taken to derive the channel's
sampling rate, suiting SLINxx format and frame->datalen.

There are stil a few limitations after this patch:
* Required information is taken from the channel during initialization as
  the audiohook does not provide this information.
  Audiohook.internal_sampl_rate(...) is set later, but no callback is available
  to inform app_jack.

* Frame.datalen is computed using "rate / 50" assuming a ptime of 20ms.
  There is no internal API available to determine datalen for a SLINxx.

* Ringbuffer size is now dynamic depending on the value of frame.datalen
  (see above) and the number of frames, which are in RINGBUFFER_FRAME_CAPACITY,
  that need to fit.

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

Note that the patch being committed here is based on the patch posted on
ASTERISK-23836. However, Matthis Schmieder also provided a patch to enable
this functionality, and that patch is noted below.

ASTERISK-20696 #close
Reported by: Matthis Schmieder
patches:
  app_jack.patch uploaded by Matthis Schmieder (License 6445)

ASTERISK-23836 #close
Reported by: Dennis Guse
patches:
  patch-app_jack.c uploaded by Dennis Guse (License 6513)



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

When using FEC, with span=3 and entries=4 Asterisk will attempt to repair
the packet with sequence number 5, as it will see that packet -4 is
missing. The result is Asterisk sending garbage packets that can kill a
fax.

This patch adds a check to see if the sequence number is valid before
checking if the packet is missing.

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

#ASTERISK-23908 #close
Reported by: Torrey Searle
patches:
  udptl_fec.patch uploaded by Torrey Searle (License 5334)
........

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

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

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


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

From headers were processed using a 256 character buffer on the stack.
This change replaces that with a heap allocation by ast_strdup.

ASTERISK-23790 #close
Reported by: uniken1
Tested by: uniken1
Review: https://reviewboard.asterisk.org/r/3669/
Patches:
    chan_sip-large-from-header-1.8-r3.patch uploaded by wdoekes (license 5674)
........

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

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

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


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