24 Jan
2013
24 Jan
'13
10:34 a.m.
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(a)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(a)gmail.com> wrote:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
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(a)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(a)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:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
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(a)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(a)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-s…
> >
> > 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(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd