<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.6.1">
</HEAD>
<BODY>
OK. This sounds like the NOTIFY is not being routed through the WebSocket module then. Instead it is coming out as a raw SIP message.<BR>
<BR>
This would explain a lot. This could well be caused by the routing within Kamailio not being quite right. For example, if the ;transport=ws parameter is missing from some Route/Record-Route/Contact/Request -URI you could see something like this.<BR>
<BR>
It could be a code problem or just a problem with the configuration file that is causing this. I suspect it may also be related to the use of the nathelper stuff and the contact aliasing that needs to be used with WebSocket (unless you are using the latest code and have configured outbound).<BR>
<BR>
Regards,<BR>
<BR>
Peter<BR>
<BR>
On Thu, 2013-01-24 at 15:29 +0000, Pete Kelly wrote:
<BLOCKQUOTE TYPE=CITE>
Hi Peter, thanks for that info.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
It looks like all the packets marked Websocket in Wireshark are coming across OK from Kamailio. The first nibble is always 1000 as expected.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
However I notice now that whenever a NOTIFY is sent out from Kamailio the packet is *not* a Websocket packet, it's identified as HTTP within Wireshark and does not contain the 4 "header" bytes that Websocket packets seem to contain.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
As a result the first byte for the NOTIFY is the letter 'N' represented as 01001110.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
So the browser could be reading the second bit as 1, and interpreting that as meaning the compressed bit set to 1.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Does that sound plausible?
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
On 24 January 2013 14:54, Peter Dunkley <<A HREF="mailto:peter.dunkley@crocodile-rcs.com">peter.dunkley@crocodile-rcs.com</A>> wrote:
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
The RSV1 bit (which is the compressed bit) should be the second bit from the left in the WebSocket frame. The first bit is the FIN (should always be one here), then you have RSV1, RSV2, and RSV3, and the last nibble of the first byte will be the opcode.
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
Regards,
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
Peter
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BR>
<BR>
On 24 Jan 2013, at 14:47, Pete Kelly <<A HREF="mailto:pkelly@gmail.com">pkelly@gmail.com</A>> wrote:<BR>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Chrome 26, 24 and Firefox nightly all exhibit the same behaviour.
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
I've decrypted the packets in wireshark, could you point me at what I am looking for to see the compressed bit?
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Wireshark reports (on what seems to be the problematic frame) "This frame ACKs a segment we have not seen"
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
On 24 January 2013 13:50, Peter Dunkley <<A HREF="mailto:peter.dunkley@crocodile-rcs.com">peter.dunkley@crocodile-rcs.com</A>> wrote:
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
Have you checked to see if there are any known bugs in the browser you are using?<BR>
<BR>
As the WebSocket message compression stuff is still draft the browser implementation probably won't be complete or fully tested yet.<BR>
<BR>
As I said, the Kamailio WebSocket implementation does not support any extensions and all the reserved bits are 0'd. So I don't think it is likely that the compressed bit is set to 1 at all.<BR>
<BR>
The only other thing I can suggest is capturing your TLS traffic with WireShark and importing the certificates into it so you can decode the packets. At that point you should be able to look at the binary of the frame and see if the compressed bit is set or not.<BR>
<BR>
Regards,<BR>
<BR>
Peter
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BR>
<BR>
On Thu, 2013-01-24 at 13:45 +0000, Pete Kelly wrote: <BR>
<BLOCKQUOTE TYPE=CITE>
Hi Peter<BR>
<BR>
<BR>
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.<BR>
<BR>
<BR>
I've tried it with the tls tls_disable_compression flag set to both 0 and 1<BR>
<BR>
<BR>
Pete<BR>
<BR>
<BR>
On 24 January 2013 09:53, Peter Dunkley <<A HREF="mailto:peter.dunkley@crocodile-rcs.com">peter.dunkley@crocodile-rcs.com</A>> wrote:<BR>
<BLOCKQUOTE>
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 <BR>
<BR>
<BR>
On Thu, 2013-01-24 at 09:09 +0000, Peter Dunkley wrote: <BR>
<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.<BR>
<BR>
<BR>
Peter<BR>
<BR>
On 24 Jan 2013, at 09:05, Peter Dunkley <<A HREF="mailto:peter.dunkley@crocodile-rcs.com">peter.dunkley@crocodile-rcs.com</A>> wrote:<BR>
<BR>
<BR>
<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. <BR>
<BR>
<BR>
I did do (a little) WSS testing and saw no problems myself. <BR>
<BR>
<BR>
Regards, <BR>
<BR>
<BR>
Peter<BR>
<BR>
On 23 Jan 2013, at 22:12, Pete Kelly <<A HREF="mailto:pkelly@gmail.com">pkelly@gmail.com</A>> wrote:<BR>
<BR>
<BR>
<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">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>
_______________________________________________<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">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</A><BR>
<BR>
</BLOCKQUOTE>
_______________________________________________<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">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</A><BR>
<BR>
</BLOCKQUOTE>
<PRE>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<A HREF="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</A>
<A HREF="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</A>
</PRE>
</BLOCKQUOTE>
<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</PRE>
</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
<BR>
<BR>
</BLOCKQUOTE>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</PRE>
</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>