apache 2.4 has capability to tunnel websocket requests:
https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html
the tunnel also automatically upgrades the connection to websocket connection meaning that ws_handle_handshake() is not needed.
has anyone managed to configure kamailio to handle sip requests via apache wstunnel?
-- juha
Juha Heinanen writes:
apache 2.4 has capability to tunnel websocket requests:
https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html
the tunnel also automatically upgrades the connection to websocket connection meaning that ws_handle_handshake() is not needed.
has anyone managed to configure kamailio to handle sip requests via apache wstunnel?
forgot to include an example of a GET request from the tunnel:
GET / HTTP/1.1. Host: 192.98.102.30:8000. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8. Accept-Language: en-US,en;q=0.5. Accept-Encoding: gzip, deflate. DNT: 1. Sec-WebSocket-Version: 13. Origin: https://test.tutpro.com. Sec-WebSocket-Protocol: sip. Sec-WebSocket-Key: NKwlVvwJcj2Z07MlXm8URg==. Pragma: no-cache. Cache-Control: no-cache. X-Forwarded-For: 192.98.103.30. X-Forwarded-Host: 192.98.103.33. X-Forwarded-Server: jessie.test.tutpro.com.
since Connection, Upgrade and Sec-WebSocket-Version headers are missing, it looks to me that a modified version of ws_handle_handshake() would be needed.
-- juha
Hello,
On 06/04/15 14:41, Juha Heinanen wrote:
Juha Heinanen writes:
apache 2.4 has capability to tunnel websocket requests:
https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html
the tunnel also automatically upgrades the connection to websocket connection meaning that ws_handle_handshake() is not needed.
has anyone managed to configure kamailio to handle sip requests via apache wstunnel?
forgot to include an example of a GET request from the tunnel:
GET / HTTP/1.1. Host: 192.98.102.30:8000. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8. Accept-Language: en-US,en;q=0.5. Accept-Encoding: gzip, deflate. DNT: 1. Sec-WebSocket-Version: 13. Origin: https://test.tutpro.com. Sec-WebSocket-Protocol: sip. Sec-WebSocket-Key: NKwlVvwJcj2Z07MlXm8URg==. Pragma: no-cache. Cache-Control: no-cache. X-Forwarded-For: 192.98.103.30. X-Forwarded-Host: 192.98.103.33. X-Forwarded-Server: jessie.test.tutpro.com.
since Connection, Upgrade and Sec-WebSocket-Version headers are missing, it looks to me that a modified version of ws_handle_handshake() would be needed.
I see Sec-WebSocket-Version header.
Anyhow, if upgrade header is missing, isn't this just going to be bare http(s) connection?
Or what is apache expecting to happen? To still upgrade to websocket?
Cheers, Daniel
Daniel-Constantin Mierla writes:
forgot to include an example of a GET request from the tunnel:
GET / HTTP/1.1. Host: 192.98.102.30:8000. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8. Accept-Language: en-US,en;q=0.5. Accept-Encoding: gzip, deflate. DNT: 1. Sec-WebSocket-Version: 13. Origin: https://test.tutpro.com. Sec-WebSocket-Protocol: sip. Sec-WebSocket-Key: NKwlVvwJcj2Z07MlXm8URg==. Pragma: no-cache. Cache-Control: no-cache. X-Forwarded-For: 192.98.103.30. X-Forwarded-Host: 192.98.103.33. X-Forwarded-Server: jessie.test.tutpro.com.
since Connection, Upgrade and Sec-WebSocket-Version headers are missing, it looks to me that a modified version of ws_handle_handshake() would be needed.
I see Sec-WebSocket-Version header.
yes, i missed it.
Anyhow, if upgrade header is missing, isn't this just going to be bare http(s) connection?
Or what is apache expecting to happen? To still upgrade to websocket?
i don't think so, but perhaps it should still include Sec-WebSocket-Accept header in 101 reply and add the connection to Websocket connection table?
-- juha
On 07/04/15 11:04, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
forgot to include an example of a GET request from the tunnel:
GET / HTTP/1.1. Host: 192.98.102.30:8000. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.6.0. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8. Accept-Language: en-US,en;q=0.5. Accept-Encoding: gzip, deflate. DNT: 1. Sec-WebSocket-Version: 13. Origin: https://test.tutpro.com. Sec-WebSocket-Protocol: sip. Sec-WebSocket-Key: NKwlVvwJcj2Z07MlXm8URg==. Pragma: no-cache. Cache-Control: no-cache. X-Forwarded-For: 192.98.103.30. X-Forwarded-Host: 192.98.103.33. X-Forwarded-Server: jessie.test.tutpro.com.
since Connection, Upgrade and Sec-WebSocket-Version headers are missing, it looks to me that a modified version of ws_handle_handshake() would be needed.
I see Sec-WebSocket-Version header.
yes, i missed it.
Anyhow, if upgrade header is missing, isn't this just going to be bare http(s) connection? Or what is apache expecting to happen? To still upgrade to websocket?
i don't think so, but perhaps it should still include Sec-WebSocket-Accept header in 101 reply and add the connection to Websocket connection table?
It still not clear to me what is going (or expected) to happen afterwards. Will this connection be http or websocket? Because websocket requires framing of the data. Http stays tcp streaming connection.
Given that it is started as HTTP but no Upgrade is required, I guess that Apache is expecting to deal with http further. And then practically is not websocket and should not be considered as such.
Anyhow, perhaps you can look inside the websocket function and try to ignore the parts dealing with the missing headers. Then see what apache sends next. You can eventually send a 101 reply with some forged Sec-WebSocket-Accept from config file just to emulate and see the results. Then if it is websocket transmission, then websocket module can be adjusted to cope with this situation.
Cheers, Daniel
Daniel-Constantin Mierla writes:
It still not clear to me what is going (or expected) to happen afterwards. Will this connection be http or websocket? Because websocket requires framing of the data. Http stays tcp streaming connection.
Given that it is started as HTTP but no Upgrade is required, I guess that Apache is expecting to deal with http further. And then practically is not websocket and should not be considered as such.
Anyhow, perhaps you can look inside the websocket function and try to ignore the parts dealing with the missing headers. Then see what apache sends next. You can eventually send a 101 reply with some forged Sec-WebSocket-Accept from config file just to emulate and see the results. Then if it is websocket transmission, then websocket module can be adjusted to cope with this situation.
i removed CONNECTION and UPGRADE from ws_handle_handshake REQUIRED_HEADERS:
#define REQUIRED_HEADERS (CONNECTION | UPGRADE | SEC_WEBSOCKET_KEY\ | SEC_WEBSOCKET_PROTOCOL\ | SEC_WEBSOCKET_VERSION)
and in the config called ws_handle_handshake() if Sec-WebSocket-Protocol header exists and has body 'sip'. after that websocket connections via apache ws_tunnel worked fine.
in my opinion we could make the above change, since existence of Connection and Upgrade headers can be checked in config rather than in the code. that is what the example websocket config does anyway:
if (($hdr(Upgrade) == "websocket") && in_list("Upgrade", $hdr(Connection), ",") && ($rm == "GET")) {
comments?
-- juha
On 08/04/15 15:28, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
It still not clear to me what is going (or expected) to happen afterwards. Will this connection be http or websocket? Because websocket requires framing of the data. Http stays tcp streaming connection.
Given that it is started as HTTP but no Upgrade is required, I guess that Apache is expecting to deal with http further. And then practically is not websocket and should not be considered as such.
Anyhow, perhaps you can look inside the websocket function and try to ignore the parts dealing with the missing headers. Then see what apache sends next. You can eventually send a 101 reply with some forged Sec-WebSocket-Accept from config file just to emulate and see the results. Then if it is websocket transmission, then websocket module can be adjusted to cope with this situation.
i removed CONNECTION and UPGRADE from ws_handle_handshake REQUIRED_HEADERS:
#define REQUIRED_HEADERS (CONNECTION | UPGRADE | SEC_WEBSOCKET_KEY\ | SEC_WEBSOCKET_PROTOCOL\ | SEC_WEBSOCKET_VERSION)
and in the config called ws_handle_handshake() if Sec-WebSocket-Protocol header exists and has body 'sip'. after that websocket connections via apache ws_tunnel worked fine.
in my opinion we could make the above change, since existence of Connection and Upgrade headers can be checked in config rather than in the code. that is what the example websocket config does anyway:
if (($hdr(Upgrade) == "websocket") && in_list("Upgrade", $hdr(Connection), ",") && ($rm == "GET")) {
comments?
I think this behaviour should be made based on a new parameter for the module, defaulting to the current behavior -- using the http/websocket proxy is not a common scenario. Also, I am not sure how valid is to expect switching to websocket connection without demanding it. Plus, in this way the upgrade to newer version is not breaking exiting configs.
Cheers, Daniel
i somewhat agree with Daniel. The wstunnel should forward Connection and Upgrade headers, instead of absorbing them. Otherwise kamailio or whatever back-end server you may use will never know it is WS connection, thus would treat the connection in simple HTTP context.
In my opinion, Nginx has a better solution then apache for WS proxy. It allows to define "extra" headers that the proxy service is suppose to forward to backend server, so that back-end server have full understanding of client characteristics (including the connection type being WS instead of HTTP).
Have a look at this for more details,
http://nginx.com/blog/websocket-nginx/
Hope this helps.
Thank you.
On Wed, Apr 8, 2015 at 5:31 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 08/04/15 15:28, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
It still not clear to me what is going (or expected) to happen afterwards. Will this connection be http or websocket? Because websocket requires framing of the data. Http stays tcp streaming connection.
Given that it is started as HTTP but no Upgrade is required, I guess that Apache is expecting to deal with http further. And then practically is not websocket and should not be considered as such.
Anyhow, perhaps you can look inside the websocket function and try to ignore the parts dealing with the missing headers. Then see what apache sends next. You can eventually send a 101 reply with some forged Sec-WebSocket-Accept from config file just to emulate and see the results. Then if it is websocket transmission, then websocket module can be adjusted to cope with this situation.
i removed CONNECTION and UPGRADE from ws_handle_handshake REQUIRED_HEADERS:
#define REQUIRED_HEADERS (CONNECTION | UPGRADE | SEC_WEBSOCKET_KEY\ | SEC_WEBSOCKET_PROTOCOL\ | SEC_WEBSOCKET_VERSION)
and in the config called ws_handle_handshake() if Sec-WebSocket-Protocol header exists and has body 'sip'. after that websocket connections via apache ws_tunnel worked fine.
in my opinion we could make the above change, since existence of Connection and Upgrade headers can be checked in config rather than in the code. that is what the example websocket config does anyway:
if (($hdr(Upgrade) == "websocket") && in_list("Upgrade", $hdr(Connection), ",") && ($rm == "GET")) {
comments?
I think this behaviour should be made based on a new parameter for the module, defaulting to the current behavior -- using the http/websocket proxy is not a common scenario. Also, I am not sure how valid is to expect switching to websocket connection without demanding it. Plus, in this way the upgrade to newer version is not breaking exiting configs.
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 04/08/2015 03:32 PM, Muhammad Shahzad wrote:
In my opinion, Nginx has a better solution then apache for WS proxy. It allows to define "extra" headers that the proxy service is suppose to forward to backend server, so that back-end server have full understanding of client characteristics (including the connection type being WS instead of HTTP).
+1 for Nginx as a ws-proxy. We use it inside our product for bulk data transfers streamed over WebSockets and it works very well.
Muhammad Shahzad writes:
In my opinion, Nginx has a better solution then apache for WS proxy. It allows to define "extra" headers that the proxy service is suppose to forward to backend server, so that back-end server have full understanding of client characteristics (including the connection type being WS instead of HTTP).
Have a look at this for more details,
well, by default also nginx proxy removes Upgrade and Connection headers because they need to explicitly added back in proxy definition. looks like the same can be done in apache proxy by adding lines
RequestHeader set myheader "myvalue"
into the proxy definition. i haven't yet tested it though.
-- juha