[SR-Users] Websockets WSS problem with NOTIFY

[Peter Dunkley]

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 list
>         > sr-users at lists.sip-router.org
>         > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>         
>         
>         
>         
>         -- 
>         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/9dbcc12b/attachment-0001.htm>