Understanding 'connection closed by client'

[David P]

When I test my coturn using https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ I get srflx and relay candidates that look good. But when I review mp4 recordings of some recent WebRTC calls, it looks like there is no audio reaching the caller. I looked in my coturn log during the same period, and found some entries that might be related:

4503652: session 001000000000008938: refreshed, realm=<mydomain.com>, username=<coturnuser>, lifetime=0
4503652: session 001000000000008938: realm <mydomain.com> user <coturnuser>: incoming packet REFRESH processed, success
4503652: session 001000000000008937: TCP socket closed remotely 999.999.201.244:65248
4503652: session 001000000000008937: closed (2nd stage), user <> realm <mydomain.com> origin <>, local 10.0.0.151:443, remote 999.999.201.244:65248, reason: TCP connection closed by client (callback)
4503652: session 001000000000008938: TCP socket closed remotely 999.999.201.244:65245
4503652: session 001000000000008938: closed (2nd stage), user <coturnuser> realm <mydomain.com> origin <>, local 10.0.0.151:443, remote 999.999.201.244:65245, reason: TCP connection closed by client (callback)
4503652: session 001000000000008938: delete: realm=<mydomain.com>, username=<coturnuser>
4503652: session 001000000000008938: peer 999.999.151.39 deleted
4503652: session 000000000000008924: refreshed, realm=<mydomain.com>, username=<coturnuser>, lifetime=0
4503652: session 000000000000008924: realm <mydomain.com> user <coturnuser>: incoming packet REFRESH processed, success
4503652: session 000000000000008924: TCP socket closed remotely 999.999.201.244:65247
4503652: session 000000000000008924: closed (2nd stage), user <coturnuser> realm <mydomain.com> origin <>, local 10.0.0.151:443, remote 999.999.201.244:65247, reason: TCP connection closed by client (callback)
4503652: session 000000000000008924: delete: realm=<mydomain.com>, username=<coturnuser>
4503652: session 000000000000008924: peer 999.999.151.39 deleted
4503652: session 001000000000008939: TCP socket closed remotely 999.999.201.244:65246
4503652: session 001000000000008939: closed (2nd stage), user <> realm <mydomain.com> origin <>, local 10.0.0.151:443, remote 999.999.201.244:65246, reason: TCP connection closed by client (callback)

Some questions:

1. The 'connection closed by client' first appears in the log following the 'refreshed' line. What is a refresh?
2. Is it typical for a client (in this case, Chrome73/Win10) to reject all ports offered, in this case, 4 of them? Is there anything I can do to avoid that, either in coturn or in my WebRtc page?

[David P]

FWIW, based on info requested in a similar post:

# netstat  -suna

IcmpMsg:

    InType3: 11805

    InType8: 1136

    InType11: 82

    InType13: 16

    OutType0: 1136

    OutType3: 14459

    OutType14: 16

Udp:

    1639229 packets received

    16340 packets to unknown port received

    149 packet receive errors

    1686088 packets sent

    9 receive buffer errors

    0 send buffer errors

    InCsumErrors: 140

UdpLite:

IpExt:

    InOctets: 2789704418

    OutOctets: 2752681395

    InNoECTPkts: 5167280

    InECT1Pkts: 497

    InECT0Pkts: 24308

    InCEPkts: 1435

# ulimit -a

core file size          (blocks, -c) 0

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 3892

max locked memory       (kbytes, -l) 64

max memory size         (kbytes, -m) unlimited

open files                      (-n) 1024

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 3892

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited

[David P]

I would like to re-ask these questions:

1. The 'connection closed by client' first appears in the log following the 'refreshed' line. What is a refresh?
2. Is it typical for a client (in this case, Chrome73/Win10) to reject all ports offered, in this case, 4 of them? Is there anything I can do to avoid that, either in coturn or in my WebRtc page?

Can you point me to any guidance?

[Vladislav]

The same case! On LTE / 3G mobile Internet client connections terminate with the same error

If you solved the problem let me know, thanks

[David P]

Sorry, still a mystery to me.

[Warren McDonald]

The most common reason for this close type on TCP is that the client does not use the session. In normal practise we configure the peerconnection so that it will try 4 protocol/port combinations. If one of these is successfully negotiated, the other 3 will be closed. Frustratingly the message is very different for a UDP session connection close than a TCP session connection close.

Even more common is the case where TURN is not required and the client used a Host or Server Reflex  ICE candidate. In this case all TURN connections are unused by the client and closed eventually. The manner and timing of close varies for different clients. 

To properly test TURN you should ensure that the clients can not make a direct or reflex connection to the peer under test. It will be forced to use at least one TURN connection.
 

Warren    

[Mészáros Mihály]

First of all sorry for the late reply.

2019. 05. 09. 23:48 keltezéssel, David P írta:

I would like to re-ask these questions:

1. The 'connection closed by client' first appears in the log following the 'refreshed' line. What is a refresh?

allocation refresh.

refresh 0 = remove allocation I don't need it.

WebRTC ICE agent (in your browser) cancel an allocation maybe because it has figured out it can connect directly or use reflexive address (server, peer).

1. Is it typical for a client (in this case, Chrome73/Win10) to reject all ports offered, in this case, 4 of them? Is there anything I can do to avoid that, either in coturn or in my WebRtc page?

It depends on your networking setup and your turn server setup and client setup.

Can you point me to any guidance?

I hope it helps...

Sorry again for the late reply...

Misi

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at https://groups.google.com/group/turn-server-project-rfc5766-turn-server.
To view this discussion on the web visit https://groups.google.com/d/msgid/turn-server-project-rfc5766-turn-server/fbd41b6e-5c6f-4d68-b37c-7cb62cf925bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.