Sometimes not working on iOS

[isaackwan]

Sometimes not working on iOS

[isaackwan]

I am able to reproduce in a different scenario, and hopefully these logs are more useful:
Device A: Windows Edge Chrome, h/w encoding for VP8 & H264
Device B: Chromebook, h/w encoding for VP8 & H264
Device C: iOS 15.3.1 Safari

https://gist.github.com/isaackwan/e6a9fd0f7bb49ccb2555643ade6814b4 <- stats.json

I forgot to mention that I am on latest, this is where I am on -

commit e19716489caf1485f862412d3623e906c0c84404 (HEAD -> master, origin/master, origin/HEAD)
Author: Juliusz Chroboczek <[email protected]>
Date:   Mon Feb 21 23:47:39 2022 +0100

    Update CHANGES.

one last thing… on my problematic iOS Safari, I tried to call /renegotiate
However I am not able to get to the chat screen..as you can see from the video, I got directed back to the video screen within seconds of going to the chat screen. It works when I am chatting 1-1.

IMG_7007.MOV

EDIT: sorry two more issues with TURN server

1 - relay test error on startup
I am now on v0.4.4, and I see this on latest (see git log above) as well.
During startup -

root@hk1:~/Programs/galene-v0.4.4# ./galene
2022/03/04 09:15:52 Starting built-in TURN server on :1194
2022/03/04 09:15:52 Relay test successful in 20.764638ms, RTT = 199.86µs
turn ERROR: 2022/03/04 09:15:52 error when handling datagram: failed to handle Refresh-request from $MYIP:51308: write tcp4 $MYIP:1194->$MYIP:51308: write: broken pipe

I am fairly certain that TURN server works, if I go to chat and do /relay-test it works.

root@hk1:~/Programs/galene-v0.4.4# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
root@hk1:~/Programs/galene-v0.4.4# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
root@hk1:~/Programs/galene-v0.4.4# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

2 - I forced a TURN connection by connecting my phone to a restricted NAT VPN.
Assume the phone is talking to another device already. Say if a device #3 joins, my phone would got kicked out. It would display a toast message "Disconnected". I would log in again and it works again.

Sorry for the lack of logs on client side.

Here's what's on the server log at that time:

turn ERROR: 2022/03/03 11:28:11 error when handling datagram: failed to handle Allocate-request from $VPNIP:48998: relay already allocated for 5-TUPLE
turn ERROR: 2022/03/03 11:28:26 error when handling datagram: failed to handle Allocate-request from $VPNIP:47360: relay already allocated for 5-TUPLE
turn ERROR: 2022/03/03 11:28:27 error when handling datagram: failed to handle Allocate-request from $VPNIP:47360: relay already allocated for 5-TUPLE
turn ERROR: 2022/03/03 11:29:19 error when handling datagram: failed to handle Allocate-request from $VPNIP:41812: relay already allocated for 5-TUPLE
turn ERROR: 2022/03/03 11:29:20 error when handling datagram: failed to handle Allocate-request from $VPNIP:41207: relay already allocated for 5-TUPLE
turn ERROR: 2022/03/03 11:29:20 error when handling datagram: failed to handle Allocate-request from $VPNIP:37560: relay already allocated for 5-TUPLE

Unrelated but I actually saw a lot of log noise even when it works:

turn ERROR: 2022/03/03 11:16:39 error when handling datagram: failed to handle Allocate-request from $HOMEIP:38741: relay already allocated for 5-TUPLE
turn ERROR: 2022/03/03 11:16:39 error when handling datagram: failed to handle Allocate-request from $HOMEIP:40167: relay already allocated for 5-TUPLE
turn ERROR: 2022/03/03 11:16:39 error when handling datagram: failed to handle Allocate-request from $HOMEIP:41609: relay already allocated for 5-TUPLE
turn ERROR: 2022/03/03 11:16:39 error when handling datagram: failed to handle Allocate-request from $HOMEIP:38741: relay already allocated for 5-TUPLE
turn ERROR: 2022/03/03 11:16:39 error when handling datagram: failed to handle Allocate-request from $HOMEIP:40167: relay already allocated for 5-TUPLE
turn ERROR: 2022/03/03 11:16:39 error when handling datagram: failed to handle Allocate-request from $HOMEIP:41609: relay already allocated for 5-TUPLE
2022/03/03 11:17:11 client: unknown id
2022/03/03 11:17:32 Replace: file does not exist
2022/03/03 11:17:32 Replace: file does not exist
2022/03/03 11:19:12 client: unknown id
2022/03/03 11:19:12 client: unknown id
2022/03/03 11:19:12 Replace: file does not exist
2022/03/03 11:20:54 ICE: unknown id in ICE
2022/03/03 11:20:54 ICE: unknown id in ICE
2022/03/03 11:20:54 ICE: unknown id in ICE
turn ERROR: 2022/03/03 11:20:56 error when handling datagram: failed to handle Allocate-request from $HOMEIP:33138: relay already allocated for 5-TUPLE
turn ERROR: 2022/03/03 11:20:56 error when handling datagram: failed to handle Allocate-request from $HOMEIP:39240: relay already allocated for 5-TUPLE

[jech]

H264 doesn't work as well on iOS Safari.

This probably implies that iOS doesn't implement the same profiles of H.264 than the other browsers. Could you please apply the patch below, and send me a copy of the offer sent by Safari?

iOS Safari is flaky

Same issue as above -- bad H.264 profile.

However she couldn't hear/see the other 2 devices. At the same time, the other 2 devices didn't see her, not even in the chat sidebar.

That's very strange. Is this reproducible? Is there any chance you could get her to show us the Javascript console output?

Patch for printing the offer:

diff --git a/rtpconn/webclient.go b/rtpconn/webclient.go
index 443089c..d51486f 100644
--- a/rtpconn/webclient.go
+++ b/rtpconn/webclient.go
@@ -571,6 +571,7 @@ func sendICE(c *webClient, id string, candidate *webrtc.ICECandidate) error {
 }
 
 func gotOffer(c *webClient, id, label string, sdp string, replace string) error {
+	println(sdp)
 	up, _, err := addUpConn(c, id, label, sdp)
 	if err != nil {
 		return err

[isaackwan]

I wish I can show you the web console :-( however it's really hard to debug iOS Safari remotely
I am able to capture the server output here -> https://pastebin.com/zAUXPXS3
sorry it's kind of messy, hope that it's easy to tell apart which one is from iOS & which one is from Chrome

BTW in the log file there is this line:

2022/03/10 10:47:41 client: unknown id
2022/03/10 10:47:42 Replace: file does not exist
2022/03/10 10:47:42 Replace: file does not exist

The moment iOS Safari joins, my Android Chrome got kicked out, toast on the UI is "Disconnected", had to rejoin to get it to work.

This is what we got from my Android Chrome console

galene.js:336 Socket close 1011 
gotClose @ galene.js:336
socket.onclose @ protocol.js:293

Interestingly, seems that running release v0.4.4 doesn't have this kick out problem.

Let me restate my case for this log file
Device A: Windows MS Edge Chromium, have H/W acceleration for H264 & VP8 as per chrome://gpu
Device B: Brave 1.35.101 (Chromium 98) on Android, have H/W acceleration for H264 & VP8 as per chrome://gpu
Device C: iOS 15.3.1 Safari

The breakdown is:

• Device A & B connects and talks
• Device C joins, Device B got kicked out, Device A & C see each other
• Device B rejoins, Device A & B sees all devices, Device C only sees itself. Only Device A&B can see that they are sending two video streams: a+b+c under the video stream

[jech]

Thanks for the log. It looks like one of the devices (the third one in the log you posted) doesn't support Baseline profile, but only Constrained Baseline profile.

Could you please let me know whether the following patch fixes the issue?

diff --git a/group/group.go b/group/group.go
index 37d75dc..19fe5ca 100644
--- a/group/group.go
+++ b/group/group.go
@@ -269,11 +269,6 @@ func codecsFromName(name string) ([]webrtc.RTPCodecParameters, error) {
 		}
 	case "h264":
 		codecs = []webrtc.RTPCodecCapability{
-			{
-				"video/H264", 90000, 0,
-				"level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f",
-				fb,
-			},
 			{
 				"video/H264", 90000, 0,
 				"level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f",

[jech]

Applied as fd09564. Please reopen if this doesn't fix your issue.

[isaackwan]

Hello, thanks for checking this! Unfortunately I am still seeing the same on latest (f66cabd)
SDP logs on server: https://pastebin.com/3nyqd359
Stats.json: https://pastebin.com/J3HAdvfz

I am starting to think that this might be a client (UI) problem rather than server problem
The situation is the same even with VP8 codec
At the same time, sometimes I am able to see one of the two other peers in device #3. It's dependent on the sequence of joining.
Unfortunately it's hard to debug without desktop Safari.

[jech]

Hopefully fixed by 1afb3c8.