Problems with Hello message when connecting to High Performance Backend

Iain · November 24, 2021, 4:56pm

I’ve been attempting to establish a websocket connection via the High Performance Backend, but am unable to get this working.

As covered in the Talk API docs, I’ve been trying to send a Hello message to establish the initial connection:

Standalone Signaling API

I’m running in an environment with no DNS server, so have configured everything using IP addresses. I have NextCloud 22.2.3 running on 192.168.4.56 and the v0.4.0 of the backend on 192.168.4.57, and am simply trying to establish communication from a client machine on 192.168.4.58.

I’m finding the documentation lacking in this area; I’m not sure if I should just be able to use the NextCloud server as the Auth backend, or if this will need a separate authentication server.

The hello message I’ve been trying to send is:

{
  "id": "unique-request-id",
  "type": "hello",
  "hello": {
    "version": "1.0",
    "auth": {
      "type": "client",
      "url": "http://192.168.4.56",
      "params": { }
    }
  }
}

If I add an entry for the NextCloud server in the [backends] section of the server.conf file and send this to the spreed websocket, spreed successfully retrieves the list of capabilities from the NextCloud server:

backend_client.go:199: Capabilities expired for http://192.168.4.56/ocs/v2.php/cloud/capabilities, updating
backend_client.go:262: Received capabilities map[config:map[attachments:map[allowed:false] chat:map[max-length:32000 read-privacy:0] conversations:map[can-create:false] previews:map[max-gif-size:3.145728e+06]] features:[audio video chat-v2 conversation-v4 guest-signaling empty-group-room guest-display-names multi-room-users favorites last-room-activity no-ping system-messages delete-messages mention-flag in-call-flags conversation-call-flags notification-levels invite-groups-and-mails locked-one-to-one-rooms read-only-rooms listable-rooms chat-read-marker webinary-lobby start-call-flag chat-replies circles-support force-mute sip-support chat-read-status phonebook-search raise-hand room-description rich-object-sharing temp-user-avatar-api geo-location-sharing voice-message-sharing signaling-v3 publishing-permissions clear-history chat-reference-id]] from http://192.168.4.56/ocs/v2.php/cloud/capabilities

But I then get an error when the hello message is sent to the NextCloud server:

backend_client.go:371: Received unsupported content-type from http://192.168.4.56: text/html; charset=UTF-8 (200 OK)

The content of the returned HTML appears to be the login page.

Am I simply failing to send the authentication information in hello.auth.params (if so, what’s is the correct format?), or am I doing this completely wrong?

wwe · November 24, 2021, 9:43pm

you have a very specific setup, unlikely many users know the solution… I would recommend you to follow this thread and referenced github issues - maybe it helps you isolate the issue…

in general I’m not really sure HPB can be setup without TLS (which in turn means you need valid fqdn for each system)

Iain · November 25, 2021, 3:00pm

After checking, I don’t think that my setup was the root cause of the issue. I’ve since run up instances of NextCloud and the HPB on Azure, with FQDN using the following script:

nextcloud_install_production.sh

And I’m seeing similar results. The curl request works fine:

curl -i https://my.fqdn.com/api/v1/welcome
HTTP/1.1 200 OK
Date: Thu, 25 Nov 2021 14:13:37 GMT
Server: nextcloud-spreed-signaling/e856c413771dd578dae075319bad8567f4ff9eb9
Content-Type: application/json; charset=utf-8
X-Spreed-Signaling-Features: audio-video-permissions, mcu, simulcast
Content-Length: 94
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Content-Security-Policy: frame-ancestors 'self'

{"nextcloud-spreed-signaling":"Welcome","version":"e856c413771dd578dae075319bad8567f4ff9eb9"}

But I’m unable to send a hello message.

var hello = {
  id: "unique-request-id",
  type: "hello",
  hello: {
    version: "1.0",
    auth: {
      type: "client",
      url: my.fqdn.com,
      params: { }
    }
  }
};

The following is logged by the signaling service:

main.go:311: Listening on 127.0.0.1:8081
client.go:282: Client from 26.255.263.121 has RTT of 30 ms (30.376783ms)
backend_client.go:199: Capabilities expired for https://my.fqdn.com/ocs/v2.php/cloud/capabilities, updating
backend_client.go:262: Received capabilities map[config:map[attachments:map[allowed:false] chat:map[max-length:32000 read-privacy:0] conversations:map[can-create:false] previews:map[max-gif-size:3.145728e+06]] features:[audio video chat-v2 conversation-v4 guest-signaling empty-group-room guest-display-names multi-room-users favorites last-room-activity no-ping system-messages delete-messages mention-flag in-call-flags conversation-call-flags notification-levels invite-groups-and-mails locked-one-to-one-rooms read-only-rooms listable-rooms chat-read-marker webinary-lobby start-call-flag chat-replies circles-support force-mute sip-support chat-read-status phonebook-search raise-hand room-description rich-object-sharing temp-user-avatar-api geo-location-sharing voice-message-sharing signaling-v3 publishing-permissions clear-history chat-reference-id]] from https://my.fqdn.com/ocs/v2.php/cloud/capabilities
backend_client.go:362: Received unsupported content-type from https://my.fqdn.com: text/html; charset=UTF-8 (200 OK)
client.go:303: Error reading from 26.255.263.121: read tcp 127.0.0.1:8081->127.0.0.1:34084: use of closed network connection

So it still looks like the signaling service is able to get the list of capabilities from the NextCloud server, but is unable to follow this up with a connection request. It’s still receiving HTML instead of the expected JSON, which I assume is resulting from a redirect to the login page like in previous attempts.

I guess that my original question is still valid. My hello message is trying to use the NextCloud server for authentication, which I’m not sure is correct.

I looked a the client example; this gives a bad handshake error and exits:

admin@mynextcloud:~/nextcloud-spreed-signaling/nextcloud-spreed-signaling-0.4.0$ ./bin/client --config /etc/signaling/server.conf -addr my.fqdn.com -maxClients 5
2021-11-25 14:41:58.024283 I | Using a maximum of 1 CPUs
2021-11-25 14:41:58.025033 I | Backend server running on http://10.0.0.4:36083
2021-11-25 14:41:58.025135 I | Connecting to [my.fqdn.com/spreed]
2021-11-25 14:41:58.025195 I | Starting 5 clients
2021-11-25 14:41:58.036844 I | websocket: bad handshake

But looking at the source code, the client creates its own authentication service, but it’s not clear whether this is a mandatory requirement for establishing the websocket connection, or if it’s simply stubbing the service to simplify the performance test.

I’ve been asked to investigate this since we want to be able to receive realtime updates when new messages are added by other users as shown by the examples in:

External API - Sending Messages between Clients

wwe · November 25, 2021, 8:09pm

I don’t get what you are trying to achieve. Please follow the thread I referenced, work through the setup process and describe in detail what is wrong…

Iain · November 25, 2021, 10:20pm

Sorry for any confusion, I’ll go back to basics.

We currently have a web service outside of Nextcloud which raises chat messages and forwards these to Nextcloud using the normal REST API.

https://nextcloud-talk.readthedocs.io/en/latest/chat/

It also retrieves the list of current messages by polling the same chat interface.

We’d like to replace the polling mechanism with push notifications, which I’ve assumed would need to be done via WebSockets, so have been trying to establish a connection using the external signalling API:

https://nextcloud-talk.readthedocs.io/en/latest/standalone-signaling-api-v1/

That page states that the first message should always be a hello message, and this is what I’ve been trying to send.

A secondary goal is to see whether it is possible to join a video chat for an existing conversation directly by pressing a single button in the external service rather than logging into the Nextcloud website. And since large scale chat services seem to require the performance signalling server these seem to go hand in hand.

I initially was running all of the services locally with no access to FQDNs, but have since been able to deploy Nextcloud and the signalling service in Azure using the following script:

Sorry for any confusion, I’ll go back to basics.

We currently have a web service outside of Nextcloud which raises chat messages and forwards these to Nextcloud using the normal REST API.

https://nextcloud-talk.readthedocs.io/en/latest/chat/

It also retrieves the list of current messages by polling the same chat interface.

We’d like to replace the polling mechanism with push notifications, which I’ve assumed would need to be done via WebSockets, so have been trying to establish a connection using the external signalling API:

https://nextcloud-talk.readthedocs.io/en/latest/standalone-signaling-api-v1/

That page states that the first message should always be a hello message, and this is what I’ve been trying to send.

A secondary goal is to see whether it is possible to join a video chat for an existing conversation directly by pressing a single button in the external service rather than logging into the Nextcloud website. And since large scale chat services seem to require the performance signalling server these seem to go hand in hand.

I initially was running all of the services locally with no access to FQDNs, but have since been able to deploy Nextcloud and the signalling service in Azure using the following script:

github.com

nextcloud/vm/blob/master/nextcloud_install_production.sh

#!/bin/bash

# T&M Hansson IT AB © - 2021, https://www.hanssonit.se/
# GNU General Public License v3.0
# https://github.com/nextcloud/vm/blob/master/LICENSE

# Prefer IPv4 for apt
echo 'Acquire::ForceIPv4 "true";' >> /etc/apt/apt.conf.d/99force-ipv4

# Fix fancy progress bar for apt-get
# https://askubuntu.com/a/754653
if [ -d /etc/apt/apt.conf.d ]
then
    if ! [ -f /etc/apt/apt.conf.d/99progressbar ]
    then
        echo 'Dpkg::Progress-Fancy "1";' > /etc/apt/apt.conf.d/99progressbar
        echo 'APT::Color "1";' >> /etc/apt/apt.conf.d/99progressbar
        chmod 644 /etc/apt/apt.conf.d/99progressbar
    fi
fi

This file has been truncated. show original

Iain · November 26, 2021, 9:28am

So is the notify_push application needed if we just want to notify a remote service that the messages in a conversation have changed?

When I read the external signaling API, it appeared to suggest that this is supported by the signalling server itself:

https://nextcloud-talk.readthedocs.io/en/latest/standalone-signaling-api-v1/#room-messages

wwe · November 26, 2021, 8:55pm

I’m sorry absolutely no idea. I only setup the “native” clients which are ready to use push notifications out-of-the-box …

This forum is mainly around user side of Nextcloud… don’t expect deep coding expertise here… there is a Dev category as well, sometimes the Devs from Nextcloud reply quickly. but n general I think it’s better to use Github for such kind of question - this is where you meet the Devs…

dolphinscorp · December 10, 2022, 9:42am

@Iain

I am getting similar error. Have setup signaling server getting this error

getting this error :
Capabilities expired for https://mydomain.com/ocs/v2.php/cloud/capabilities,
Dec 10 09:07:45 backup-sso signaling[174888]: backend_client.go:164: Could not send request {“type”:“auth”,“auth”:{“version”:“1.0”,“params”:{“userid”:“User01”,“ticket”:“XXvLPHkrFNBIyJQp:1670662834:User01:c2986a132bc6781adfd0b7e2a690c2de2d48b5c0686a8a61f947580d22e87b67”}}} to https://mydomain.com/ocs/v2.php/apps/spreed/api/v3/signaling/backend: Post “https://mydomain.cloud/ocs/v2.php/apps/spreed/api/v3/signaling/backend”: context deadline exceeded

I have described my issue over here for details

github.com/strukturag/nextcloud-spreed-signaling

Signaling Server Connectivity issue

opened 09:15AM - 10 Dec 22 UTC

dolphinscorp

Hi I have configured nextcloud-spreed-signaling, On first time when we config…ured signaling in Web UI Admin of Nextcloud signaling it was working fine, due to some reason, we just deleted signaling url from Nextcloud and after few hour add it again then we are getting this error : Capabilities expired for https://mydomain.com/ocs/v2.php/cloud/capabilities, Dec 10 09:07:45 backup-sso signaling[174888]: backend_client.go:164: Could not send request {"type":"auth","auth":{"version":"1.0","params":{"userid":"User01","ticket":"XXvLPHkrFNBIyJQp:1670662834:User01:c2986a132bc6781adfd0b7e2a690c2de2d48b5c0686a8a61f947580d22e87b67"}}} to https://dcorp.cloud/ocs/v2.php/apps/spreed/api/v3/signaling/backend: Post "https://mydomain.cloud/ocs/v2.php/apps/spreed/api/v3/signaling/backend": context deadline exceeded server.conf: ![image](https://user-images.githubusercontent.com/115947558/206842630-e64a6efc-3111-4b90-98a7-9603cb723384.png) ![image](https://user-images.githubusercontent.com/115947558/206842694-1bbc6da0-c7bc-4f2d-97d9-ffdcce584781.png) ![image](https://user-images.githubusercontent.com/115947558/206842708-fac518da-ed54-46dd-b040-4e3f51e30d57.png) ![image](https://user-images.githubusercontent.com/115947558/206842775-e037378f-95c7-4e1f-8641-633bba007ed1.png) Pleasee suggest