Websocket closed abruptly

Asterisk Asterisk WebRTC
1

Hello. Asterisk 16.13.0 please could somebody help me to understand what’s cause of following issue. Sometimes webrtc client socket connections closed:
[

Dec  1 09:00:48] NOTICE[458451]: res_pjsip/pjsip_transport_management.c:170 idle_sched_cb: Shutting down transport 'WS to 127.0.0.1:37938' since no request was received in 32 seconds
[Dec  1 09:00:48] WARNING[792000]: res_http_websocket.c:559 ws_safe_read: Web socket closed abruptly

I’m using nginx server as proxy for websocket connection with settings

location / {
           proxy_pass http://127.0.0.1:8088/ws;
           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;         
	   proxy_read_timeout 43200000;         
       }

I tried to change pjsip.conf

keep_alive_interval=60
contact_expiration_check_interval=60.

no luck

webrtc enpoint configured as:

[webrtc-aor-template]
type = aor
max_contacts = 1
remove_existing = yes
qualify_frequency = 600

[webrtc-endpoint-template]
type = endpoint
context = webrtc
disallow = all
allow = opus
webrtc = yes
rtp_symmetric = yes
rewrite_contact = yes
force_rport = yes

as well I’ve tried to change http.conf

sessionlimit=1000
session_inactivity=60000

nothing help to resolve. What’s else should I check?

2

There is built in functionality to terminate Websocket connections which open and send nothing. That appears to have happened. Have you confirmed the client actually sent something?

3

I’ll try to check from client side. JS Client must sent ping websocket packets everytime to save connection open? can I increase interval of 32 second using some options?

4

It requires SIP traffic to flow, once that happens then it will not be disconnected. The time is based on SIP timers and I would not recommend modifying that.

5

so, if I’ll change qualify_frequency = 20
and asterisk will send options packets every 20 seconds and receive 200 OK responses from client(it will help to keep SIP interconnection longer time), how do you think is it good solution or not?

6

OPTIONS will only be sent to a registered client, which would require the client to send a REGISTER to Asterisk. That REGISTER would stop this disconnection from occurring in the first place. Only 1 SIP packet has to be sent from the client to stop the disconnection.

7

It’s still not a bad idea to leave the qualify at around 60.

If your connections are disconnecting abruptly after say around 120 seconds, it could be the router. If its totally random, then it’s probably your client internet connections or something on your network (like a congested switch).

I have seen some routers close persistent connections if they consider the connection to be “idle”, make sure this idle timeout is higher than your qualify. Remember what websocket connections are asking routers to do is keep a TCP connection open for a long time regardless of traffic… something that they are traditionally not used to.

The only other place that will close the websocket connection is the browser, check the console for errors there.

8

so, better to change default_expiration or maximum_expiration, so client will be reregister more often?

9

Thank you for your answer. It’s really good idea to check all network equipment settings.
when that happens the value is same 32 seconds.

10

So, the disconnection in question in the original post only occurs if there is a Websocket connection that has NEVER sent a SIP request. If it does send at least one SIP request, then that disconnection timer is terminated indefinitely for the connection.

From a general perspective of keeping the connection open in general - then qualify can potentially help with that, but it can also be browser side as @InnovateAsterisk said.

11

In Chrome, or whatever browser open the developer tools and select the network tab, there you need to find the /ws/ connection (it normally the one open for the longest, or you can filter by WS), then select it. The panel then shows “messages”, check that SIP messages are being sent to and receive from the asterisk server. These messages are the raw SIP messages, the same messages you would normally see in a wireshark trace or SIP history/debug in Asterisk.

1 Like
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.