2013-07-03 16:33:13 +00:00
|
|
|
[general]
|
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
........
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
2014-06-26 12:21:14 +00:00
|
|
|
enabled = yes ; When set to no, ARI support is disabled.
|
|
|
|
|
;pretty = no ; When set to yes, responses from ARI are
|
|
|
|
|
; ; formatted to be human readable.
|
|
|
|
|
;allowed_origins = ; Comma separated list of allowed origins, for
|
|
|
|
|
; ; Cross-Origin Resource Sharing. May be set to * to
|
|
|
|
|
; ; allow all origins.
|
|
|
|
|
;auth_realm = ; Realm to use for authentication. Defaults to Asterisk
|
|
|
|
|
; ; REST Interface.
|
|
|
|
|
;
|
|
|
|
|
; Default write timeout to set on websockets. This value may need to be adjusted
|
|
|
|
|
; for connections where Asterisk must write a substantial amount of data and the
|
|
|
|
|
; receiving clients are slow to process the received information. Value is in
|
|
|
|
|
; milliseconds; default is 100 ms.
|
|
|
|
|
;websocket_write_timeout = 100
|
2016-11-11 16:45:37 +00:00
|
|
|
;
|
|
|
|
|
; Display certain channel variables every time a channel-oriented
|
|
|
|
|
; event is emitted:
|
|
|
|
|
;
|
2018-11-07 17:18:34 +00:00
|
|
|
; Note that this does incur a performance penalty and should be avoided if possible.
|
|
|
|
|
;
|
2016-11-11 16:45:37 +00:00
|
|
|
;channelvars = var1,var2,var3
|
2013-07-03 16:33:13 +00:00
|
|
|
|
2013-07-11 14:39:55 +00:00
|
|
|
;[username]
|
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
........
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
2014-06-26 12:21:14 +00:00
|
|
|
;type = user ; Specifies user configuration
|
|
|
|
|
;read_only = no ; When set to yes, user is only authorized for
|
|
|
|
|
; ; read-only requests.
|
2013-07-03 16:33:13 +00:00
|
|
|
;
|
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
........
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
2014-06-26 12:21:14 +00:00
|
|
|
;password = ; Crypted or plaintext password (see password_format).
|
2013-07-03 16:33:13 +00:00
|
|
|
;
|
|
|
|
|
; password_format may be set to plain (the default) or crypt. When set to crypt,
|
|
|
|
|
; crypt(3) is used to validate the password. A crypted password can be generated
|
|
|
|
|
; using mkpasswd -m sha-512.
|
|
|
|
|
;
|
|
|
|
|
; When set to plain, the password is in plaintext.
|
|
|
|
|
;
|
|
|
|
|
;password_format = plain
|
