>
> Maybe Kamailio could report an error in the logs when the unrecognised
> transport type is submitted?
That could be handy. I am not sure how/where to put something like this
though.
> Interesting, I had those routing problems initially, so I added the
> add_contact_alias() to my script b
On 24 January 2013 16:05, Peter Dunkley 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 t
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 probab
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: \r\n
Contact looks suspicious as ws instead of wss?
Does Kamailio use the
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
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 identifie
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:4
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 Janu
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 a
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 Jan
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
Just fyi, tls compression is disabled by default in the tls module:
-
http://kamailio.org/docs/modules/stable/modules/tls.html#tls_disable_compression
But you can try with it set and see what happens.
Cheers,
Daniel
On 1/24/13 10:09 AM, Peter Dunkley wrote:
I shod also add that the Kamailio W
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
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 sa
14 matches
Mail list logo
