<div dir="ltr"><div><div><div>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.<br><br></div>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).<br><br></div>Have a look at this for more details,<br><br><a href="http://nginx.com/blog/websocket-nginx/">http://nginx.com/blog/websocket-nginx/</a><br><br></div><div>Hope this helps.<br></div><div><br></div>Thank you.<br><div><div><br><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 8, 2015 at 5:31 PM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 08/04/15 15:28, Juha Heinanen wrote:<br>
> Daniel-Constantin Mierla writes:<br>
><br>
>> It still not clear to me what is going (or expected) to happen<br>
>> afterwards. Will this connection be http or websocket? Because websocket<br>
>> requires framing of the data. Http stays tcp streaming connection.<br>
>><br>
>> Given that it is started as HTTP but no Upgrade is required, I guess<br>
>> that Apache is expecting to deal with http further. And then practically<br>
>> is not websocket and should not be considered as such.<br>
>><br>
>> Anyhow, perhaps you can look inside the websocket function and try to<br>
>> ignore the parts dealing with the missing headers. Then see what apache<br>
>> sends next. You can eventually send a 101 reply with some forged<br>
>> Sec-WebSocket-Accept from config file just to emulate and see the<br>
>> results. Then if it is websocket transmission, then websocket module can<br>
>> be adjusted to cope with this situation.<br>
> i removed CONNECTION and UPGRADE from ws_handle_handshake<br>
> REQUIRED_HEADERS:<br>
><br>
> #define REQUIRED_HEADERS      (CONNECTION | UPGRADE | SEC_WEBSOCKET_KEY\<br>
>                                       | SEC_WEBSOCKET_PROTOCOL\<br>
>                                       | SEC_WEBSOCKET_VERSION)<br>
><br>
> and in the config called ws_handle_handshake() if Sec-WebSocket-Protocol<br>
> header exists and has body 'sip'. after that websocket connections via<br>
> apache ws_tunnel worked fine.<br>
><br>
> in my opinion we could make the above change, since existence of<br>
> Connection and Upgrade headers can be checked in config rather than in<br>
> the code.  that is what the example websocket config does anyway:<br>
><br>
>       if (($hdr(Upgrade) == "websocket") &&<br>
>                 in_list("Upgrade", $hdr(Connection), ",") &&<br>
>                       ($rm == "GET")) {<br>
><br>
> comments?<br>
<br>
</div></div>I think this behaviour should be made based on a new parameter for the<br>
module, defaulting to the current behavior -- using the http/websocket<br>
proxy is not a common scenario. Also, I am not sure how valid is to<br>
expect switching to websocket connection without demanding it. Plus, in<br>
this way the upgrade to newer version is not breaking exiting configs.<br>
<span class="im HOEnZb"><br>
Cheers,<br>
Daniel<br>
<br>
--<br>
Daniel-Constantin Mierla<br>
<a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a><br>
Kamailio World Conference, May 27-29, 2015<br>
Berlin, Germany - <a href="http://www.kamailioworld.com" target="_blank">http://www.kamailioworld.com</a><br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</div></div></blockquote></div><br></div>