res_http_websocket: Close websocket correctly and use careful fwrite

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/12@417311 f38db490-d61c-443f-a65b-d21fe96a405b
udptl: Correct FEC to not consider negative sequence numbers as missing

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/12@417324 f38db490-d61c-443f-a65b-d21fe96a405b