On 24 January 2013 16:05, Peter Dunkley <peter.dunk...@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@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 > > > > > -- > 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
