[SR-Users] Websockets WSS problem with NOTIFY

Thu Jan 24 16:46:56 CET 2013

This is the ruri:
NOTIFY sips:pete at 10.15.20.113:55536;rtcweb-breaker=no;transport=wss
SIP/2.0\r\n

There is only one Via header:
Via: SIP/2.0/TLS 10.15.20.170:443;branch=z9hG4bK8455.12ffc4c6.0\r\n

And the Contact:
Contact: <sip:10.15.20.170:443;transport=ws>\r\n

Contact looks suspicious as ws instead of wss?

Does Kamailio use the usrloc info from the REGISTER to send out a NOTIFY?

On 24 January 2013 15:34, Peter Dunkley <peter.dunkley at crocodile-rcs.com>wrote:

> **
> 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.
>
> 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.
>
> 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).
>
> Regards,
>
> Peter
>
>
> On Thu, 2013-01-24 at 15:29 +0000, Pete Kelly wrote:
>
> Hi Peter, thanks for that info.
>
>
> It looks like all the packets marked Websocket in Wireshark are coming
> across OK from Kamailio. The first nibble is always 1000 as expected.
>
>
>
>  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.
>
>
>
>  As a result the first byte for the NOTIFY is the letter 'N' represented
> as 01001110.
>
>
>
>  So the browser could be reading the second bit as 1, and interpreting
> that as meaning the compressed bit set to 1.
>
>
>
>  Does that sound plausible?
>
>
>
>  On 24 January 2013 14:54, Peter Dunkley <peter.dunkley at crocodile-rcs.com>
> wrote:
>
>  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.
>
>
>
>   Regards,
>
>
>
>   Peter
>
>
>
> On 24 Jan 2013, at 14:47, Pete Kelly <pkelly at gmail.com> wrote:
>
>
>    Chrome 26, 24 and Firefox nightly all exhibit the same behaviour.
>
>
>
>    I've decrypted the packets in wireshark, could you point me at what I
> am looking for to see the compressed bit?
>
>
>
>    Wireshark reports (on what seems to be the problematic frame) "This
> frame ACKs a segment we have not seen"
>
>
>
>    On 24 January 2013 13:50, Peter Dunkley <
> peter.dunkley at crocodile-rcs.com> wrote:
>
>    Have you checked to see if there are any known bugs in the browser you
> are using?
>
> As the WebSocket message compression stuff is still draft the browser
> implementation probably won't be complete or fully tested yet.
>
> 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.
>
> 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.
>
> Regards,
>
> Peter
>
>
>
> On Thu, 2013-01-24 at 13:45 +0000, Pete Kelly wrote:
>
> Hi Peter
>
>
> 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.
>
>
> I've tried it with the tls tls_disable_compression flag set to both 0 and 1
>
>
> Pete
>
>
> On 24 January 2013 09:53, Peter Dunkley <peter.dunkley at crocodile-rcs.com>
> wrote:
>
> Hi,
>
> 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.
>
> As this part of the code is identical for WS and WSS connections can you
> confirm that it works correctly for WS?
>
> Regards,
>
> Peter
>
>
> On Thu, 2013-01-24 at 09:09 +0000, Peter Dunkley wrote:
>
> 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.
>
>
> Peter
>
> On 24 Jan 2013, at 09:05, Peter Dunkley <peter.dunkley at crocodile-rcs.com>
> wrote:
>
>
>  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.
>
>
> I did do (a little) WSS testing and saw no problems myself.
>
>
> Regards,
>
>
> Peter
>
> On 23 Jan 2013, at 22:12, Pete Kelly <pkelly at gmail.com> wrote:
>
>
>  Hi, I am having an issue at the moment with SIP NOTIFY messages being
> sent from Kamailio (latest git master) over wss transport
>
> I am getting reports from the receiving end saying "Compressed bit must be
> 0 if no negotiated deflate-frame extension"
>
> 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:
> http://stackoverflow.com/questions/12308728/compressed-bit-must-be-0-when-sending-a-message-to-websocket-client
>
> 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.
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>  _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>  _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
>   --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>
>
>
>
>   --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>
>
>
>
>
>
>   --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130124/bfa9c80b/attachment.htm>