6 Apr
2015
6 Apr
'15
3:30 p.m.
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
6 Apr
6 Apr
3:41 p.m.
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
7 Apr
7 Apr
10:34 a.m.
Hello,
On 06/04/15 14:41, Juha Heinanen wrote:
Juha Heinanen writes:
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
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
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.
12:04 p.m.
Daniel-Constantin Mierla writes:
yes, i missed it.
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?
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
1:23 p.m.
On 07/04/15 11:04, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
yes, i missed it.
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
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
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?
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?
8 Apr
8 Apr
4:28 p.m.
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
6:31 p.m.
On 08/04/15 15:28, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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
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? 
10:32 p.m.
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(a)gmail.com>
wrote:
On 08/04/15 15:28, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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? 
10:34 p.m.
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.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
10 Apr
10 Apr
9:01 a.m.
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,
http://nginx.com/blog/websocket-nginx/
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
3517
days inactive
3521
days old
9 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
Juha Heinanen -
Muhammad Shahzad