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.dunk...@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.dunk...@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 <pke...@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.dunk...@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.dunk...@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.dunk...@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 <pke...@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@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@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-us...@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 > >
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
