<div dir="ltr">Hi Peter<div><br></div><div style>I can confirm it works correctly for WS and not WSS, and it appears to be only the NOTIFY request in the direction of Kamailio > UAC. INVITE requests in the direction of Kamailio > UAC are fine.</div>
<div style><br></div><div style>I've tried it with the tls tls_disable_compression flag set to both 0 and 1</div><div style><br></div><div style>Pete</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 24 January 2013 09:53, Peter Dunkley <span dir="ltr"><<a href="mailto:peter.dunkley@crocodile-rcs.com" target="_blank">peter.dunkley@crocodile-rcs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>
<div>
Hi,<br>
<br>
I've done some checking online and in the code. The compressed bit is defined in draft-ietf-hybi-permessage-compression and uses the RSV1 bit from the WebSocket frame header. As per RFC 6455 the Kamailio WebSocket implementation is careful to leave RSV1, RSV2, and RSV3 with values of 0.<br>
<br>
As this part of the code is identical for WS and WSS connections can you confirm that it works correctly for WS?<br>
<br>
Regards,<br>
<br>
Peter<div><div class="h5"><br>
<br>
On Thu, 2013-01-24 at 09:09 +0000, Peter Dunkley wrote:
<blockquote type="CITE">
I shod also add that the Kamailio WebSocket implementation does not support any extensions. So unless the deflate frame extension is implicit for TLS it will not be negotiated. Further, the implementation does not set any compressed bits and all unused flags etc should be zeroed automatically - but I will look at the code later.
</blockquote>
<blockquote type="CITE">
<br>
<br>
</blockquote>
<blockquote type="CITE">
Peter<br>
<br>
On 24 Jan 2013, at 09:05, Peter Dunkley <<a href="mailto:peter.dunkley@crocodile-rcs.com" target="_blank">peter.dunkley@crocodile-rcs.com</a>> wrote:<br>
<br>
<br>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">
I am not sure how to investigate this. It sounds like it might be a TLS related problem (or a WebSocket/TLS interworking problem in Kamailio). I don't know anything about the Kamailio TLS implementation - I just drop WebSocket frames into it as required.
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">
<br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">
I did do (a little) WSS testing and saw no problems myself.
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">
<br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">
Regards,
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">
<br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">
Peter<br>
<br>
On 23 Jan 2013, at 22:12, Pete Kelly <<a href="mailto:pkelly@gmail.com" target="_blank">pkelly@gmail.com</a>> wrote:<br>
<br>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
Hi, I am having an issue at the moment with SIP NOTIFY messages being sent from Kamailio (latest git master) over wss transport<br>
<br>
I am getting reports from the receiving end saying "Compressed bit must be 0 if no negotiated deflate-frame extension"<br>
<br>
The only reference I can find to it is at the following URL... where the problem was caused by the server miscalculating the size of the msg: <a href="http://stackoverflow.com/questions/12308728/compressed-bit-must-be-0-when-sending-a-message-to-websocket-client" target="_blank">http://stackoverflow.com/questions/12308728/compressed-bit-must-be-0-when-sending-a-message-to-websocket-client</a><br>
<br>
Does anyone have any suggestions as to how I could debug this within Kamailio? It sounds like Kamailio may be sending some incorrect packet information but I am unsure at this point.<br>
<br>
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">
<blockquote type="CITE">
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">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>
<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="CITE">
<blockquote type="CITE">
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">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>
<br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<pre>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a>
<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>
</pre>
</blockquote>
<br>
</div></div><span class="HOEnZb"><font color="#888888"><table cellspacing="0" cellpadding="0" width="100%">
<tbody><tr>
<td>
<pre>--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</pre>
</td>
</tr>
</tbody></table>
</font></span></div>
</blockquote></div><br></div>