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@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@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-se...

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

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@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@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-se...

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 list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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@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@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@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 list
    > sr-users@lists.sip-router.org
    > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




    -- 
    Peter Dunkley
    Technical Director
    Crocodile RCS Ltd

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@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.dunkley@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@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@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@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-se...

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 list sr-users@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

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@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@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.dunkley@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@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@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@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 list
    >         >         > sr-users@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
    > 
    > 
    > 

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@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.dunkley@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@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.dunkley@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@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@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@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 list
    >         >         >         > sr-users@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
    >         > 
    >         > 
    >         > 
    > 
    > 
    > 


    -- 
    Peter Dunkley
    Technical Director
    Crocodile RCS Ltd

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 but only if if (nat_uac_test(64)) passes. I'll take a look at what is happening here.

It just occurred to me that as you are passed the point that handle_ruri() alias is called so you wouldn't see this in the request outside Kamailio. So please ignore my comments on this part.

I am using the latest 4.0.0 sources, so I guess I could also switch to outbound.

That's probably a good idea as long as you have separate edge-proxies and registrars (always a good idea to begin with). Outbound is the recommended method for SIP over WebSocket.

Regards,

Peter