[SR-Users] Websockets WSS problem with NOTIFY

Thu Jan 24 17:16:37 CET 2013

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

> **
> OK.  It looks like you have a bug in the client SIP over WebSocket stack.
>
> ;transport=wss (as you have on the R-URI) is not correct.  It should be
> ;transport=ws whether it is WS or WSS.  The R-URI in the NOTIFY will be the
> contact that the client stack put into the SUBSCRIBE - so this wss is
> probably coming from the client stack.  See
> draft-ietf-sipcore-sip-websocket section 5.2.2.
>

The transport in the SUBSCRIBE was indeed being set as wss, I've modified
it and the problem has disappeared. I'll double check with a tcp dump,
however it looks like it has done the trick.

Maybe Kamailio could report an error in the logs when the unrecognised
transport type is submitted?

>
> The contents of the domain part of the R-URI here is also unusual - the
> draft recommends a made-up ".invalid" domain - again see
> draft-ietf-sipcore-sip-websocket section A.1.
>
> Also, this NOTIFY R-URI contains no ;alias= parameter - so unless you are
> using the latest git master and have enabled outbound you will probably
> have some routing problems with this.  Basically, you should use the
> nathelper module and call add_contact_alias() for all dialog-forming and
> re-targetting requests (INVITE, NOTIFY, SUBSCRIBE, and UPDATE) that you
> receive from a WebSocket client.  Then you should call handle_ruri_alias()
> for all requests that destined for a WebSocket client.
>

Interesting, I had those routing problems initially, so I added the
add_contact_alias() to my script but only if if (nat_uac_test(64)) passes.
I'll take a look at what is happening here.

I am using the latest 4.0.0 sources, so I guess I could also switch to
outbound.

Thanks for your help (and the websockets module), it is much appreciated.

>
> Regards,
>
> Peter
>
>
> On Thu, 2013-01-24 at 15:46 +0000, Pete Kelly wrote:
>
> 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
>
>
>
>
>   --
> 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/3febf616/attachment-0001.htm>