Nextcloud talk unable to perform second call

[martinmoreira]

Greeting.

I am having an issue which prevents calls of being performed after a call was already ended.

The error message is:
signaling[1440533]: client.go:303: Error reading from 10.10.10.22: read tcp 127.0.0.1:8090->127.0.0.1:50042: use of closed network connection

The only way of having a new call is closing Nextcloud Talk completely, and reload it.

Thank you very much in advance.!

[solracsf]

I'm having this exact same issue, with same error message:

client.go:303: Error reading from 10.1.0.3: read tcp 127.0.0.1:8081->127.0.0.1:43110: use of closed network connection

I don't know if this is also related to this issue, but i can also observe:

client.go:301: Error reading from client mNZJKLYvtJW..... : websocket: close 1006 (abnormal closure): unexpected EOF

Nextcloud 22.2.3, Talk 12.1.2, using latest master branch

[fancycode]

What are you using as frontend webserver? Could it be this closes the websocket connection between the client / browser and the signaling server?

[solracsf]

Nginx as a frontend. I've increased proxy timeouts to insane levels (like 86400s) but it didn't help here.

[martinmoreira]

Hi.
Nginx here also.

[fancycode]

With nginx the defaults should work without problems. The error message indicates an unclear termination of the websocket connection between the frontend webserver and the signaling server. Which browser are you using and are there any suspicious logs in the browser console at the time this happens?

[martinmoreira]

I am using the android client on both sides.
And the same behavior if I use a web browser.

[fancycode]

This sound more like a problem with the Android app then. Never had similar problems with a browser.

@acsfer are you using the Android app, too?

[solracsf]

No, my users don't use any app (android or ios). Regular browsers, but mixed (chrome, firefox, edge, safari).

[cue108]

I'm having a similar issue:

client.go:303: Error reading from 192.168.123.55: read tcp 192.168.123.31:8085->192.168.123.30:59710: use of closed network connection

I am running Nginx on host 30 and the HPB HTTP listens on host 31. For some reason, the backend wants to connect to the proxy host instead of the HPB host 31.
I couldn't find any configuration parameter to resolve this issue and I guess most have the reverse proxy residing on the same host as the rest of the High-Performance Backend?

Interestingly after starting the HPB via docker-compose the first call via android just works but the second one doesn't.

Any hint is appreciated!

[martinmoreira]

Hi.
I think I may have solved this for me...

I commented 3 lines on nginx configuration and it works now.

location /standalone-signaling/spreed {
proxy_pass http://signaling/spreed;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

[cue108]

Hi. I think I may have solved this for me...

I commented 3 lines on nginx configuration and it works now.

location /standalone-signaling/spreed { proxy_pass http://signaling/spreed; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade";

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Thanx for your swift reply, but I have those settings already. Below is my full Nginx config for the signaling backend.

upstream signaling {
      server 192.168.123.31:8085;
}
server {
      listen 443 ssl http2;
      server_name my.domain.com;

      add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

      location /standalone-signaling/ {
          proxy_pass http://signaling/;
          proxy_http_version 1.1;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      }

      location /standalone-signaling/spreed {
          proxy_pass http://signaling/spreed;
          proxy_http_version 1.1;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "Upgrade";
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      }
}
server {
    if ($host = my.domain.com) {
        return 301 https://$host$request_uri;
    }

    listen 80;
    server_name my.domain.com;
    return 404;
}

[martinmoreira]

Hi.

I actually commented this 3 lines on here:
location /standalone-signaling/spreed {

So, at the end, it is like this:
location /standalone-signaling/spreed {
proxy_pass http://signaling/spreed;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}

[cue108]

Got you. Commented it in the sense of disabling it.
I just checked it out and it didn't work for me.
In fact, it made it worse as a call from one mobile to another within the same wireless network of the signaling server does not get established at all. Meaning, it doesn't even ring on the other side.

[martinmoreira]

@cue108 Actually your description of the problem make me look for other examples of websocket configuration in nginx.

Maybe you can "play" with this options.

I've got "inspired" here:
https://www.nginx.com/blog/websocket-nginx/

[cue108]

@martinmoreira Thanx for the link!
I am not even sure that it has to do with the Nginx proxy config as the error message in my case simply tries to connect to the wrong host from the HTTP service to which the proxy must have successfully upstreamed to already.
There is no and cannot be a port 59710 on host 30 but on host 31 it could be one of the Coturn server ones.
But I have to admit that there is a lot of improvement potential to my knowledge of how those connections are managed during a call...
So it rings on the phone but the final connection and the actual conversation cannot start. It remains ringing until a timeout of 45 seconds. But then sometimes right after starting the whole docker-compose signaling thing, the first video call connection gets established just fine.
But from there no further successful calls mobile to mobile. All calls via a browser do work fine though.

[cue108]

I am using Nextcould 2.2.3, Talk 12.2.2, and the latest Master branch of THIS.
I also did a make clean after a git pull and before a docker-compose build.

[martinmoreira]

Hi.
I am sorry, I am not an expert at all...
But I'll try to reproduce your setup with a second vm and see if I get the same result.

[martinmoreira]

@cue108 : Could you please share your docker-compose.yml ?
Thanks.

[cue108]

@martinmoreira It is the same as you will find in the root folder of this repository enriched with my individual REALM and STATIC_SECRET parameters.

There is one change I did to docker/coturn/Dockerfile by adding the --external-ip=192.168.123.31 to the CMD line as the whole service is running behind a NAT and this parameter worked well already with my former dedicated STUN/TURN server configuration.

It might also be helpful to notice that if I switch off the High-performance backend configuration in the NC admin section and keep the STUN/TURN server still referring to the Coturn service launched by the same docker-compose it works just fine - all of it.

[hboetes]

There is one change I did to docker/coturn/Dockerfile by adding the --external-ip=192.168.123.31 to the CMD line as the whole service is running behind a NAT and this parameter worked well already with my former dedicated STUN/TURN server configuration.

I discovered I had the wrong external IP configured because of this message. :-)

[apg1980]

There is one change I did to docker/coturn/Dockerfile by adding the --external-ip=192.168.123.31 to the CMD line as the whole service is running behind a NAT and this parameter worked well already with my former dedicated STUN/TURN server configuration.

I discovered I had the wrong external IP configured because of this message. :-)

Hello, can you please explain the "--external-ip=xxxxx" parameter on dynamic ip adress? can i configure on this point a dyndns record?

[grickard]

I'm getting the same server-side error with NC 23 and latest stable Talk. I compiled HPB from source on an Ubuntu 21.04 LXC container. Here's my client output:

Uncaught SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data onmessage signaling.js:702 connect signaling.js:759 reconnectTimer signaling.js:619 setTimeout handler*97456/h.Standalone.prototype.reconnect signaling.js:617 onclose signaling.js:696 connect signaling.js:696 reconnectTimer signaling.js:619 setTimeout handler*97456/h.Standalone.prototype.reconnect signaling.js:617 onclose signaling.js:696 connect signaling.js:696 reconnectTimer signaling.js:619 setTimeout handler*97456/h.Standalone.prototype.reconnect signaling.js:617 onclose signaling.js:696 connect signaling.js:696 reconnectTimer signaling.js:619 signaling.js:702:10

Here's an additional piece of server output:

hub.go:813: Invalid message {Id: Type: Hello:<nil> Bye:<nil> Room:<nil> Message:<nil> Control:<nil> Internal:<nil> TransientData:<nil>} from 192.161.79.218: type missing

[fancycode]

Here's an additional piece of server output:

hub.go:813: Invalid message {Id: Type: Hello:<nil> Bye:<nil> Room:<nil> Message:<nil> Control:<nil> Internal:<nil> TransientData:<nil>} from 192.161.79.218: type missing

see #180

[fancycode]

According to some of the comments above, this was fixed by setting a correct external IP in Coturn or changing configuration of the webserver. So most likely not related to the signaling server - closing then. Feel free to reopen with more details if really a problem of the signaling server.