24 Jan
2013
24 Jan
'13
11:05 a.m.
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 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.
Regards,
Peter
On Thu, 2013-01-24 at 15:46 +0000, Pete Kelly wrote:
This is the ruri:
NOTIFY sips:pete@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(a)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:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
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:
> 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
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd