LiveKit Community

hey William, this should be pretty straight forward to do (for the WebSocket connection and TURN/TLS). We have a deployment generator using caddy: <https://docs.livekit.io/deploy/vm>

You could do something similar with nginx.

I can give little bit more explanation. This is happening if I join first time to the room &amp; share screen. If I share webcam first then I can't see this problem.

Yeah Jibon, there is this Pion issue - <https://github.com/pion/webrtc/issues/2054> which we fixed, but I think there are still corner cases.

Just in the last couple of days, two people have reported issues with this fix also although once we fixed it, our use cases are working fine. There has not been a server release with that fix yet.

Thank you for your quick response Raja. Waiting for new release. Is there any docker release for beta with this fix?

No problem. If <@U01KZ61GV5Z> publish any beta release then I can test.

<@U02LCP104CQ>, I'm planning to get a release out in the next day or so! stay tuned.

<@U02CM28PB4Y> <@U01KZ61GV5Z> I'm facing similar problem in latest version (v0.15.3). The main issue is once it failed to share webcam, after that until I re-connect webcam won't show up for other participants. Log:


```livekit_1        | 2022-01-29T06:59:36.621Z	ERROR	livekit.turn	v2@v2.0.6/server.go:184	error when handling datagram: failed to handle Allocate-request from 103.175.123.62:51953: relay already allocated for 5-TUPLE
livekit_1        | <http://github.com/pion/turn/v2.(*Server).readLoop|github.com/pion/turn/v2.(*Server).readLoop>
livekit_1        | 	/go/pkg/mod/github.com/pion/turn/v2@v2.0.6/server.go:184
livekit_1        | <http://github.com/pion/turn/v2.NewServer.func1|github.com/pion/turn/v2.NewServer.func1>
livekit_1        | 	/go/pkg/mod/github.com/pion/turn/v2@v2.0.6/server.go:85
livekit_1        | 2022-01-29T06:59:36.654Z	ERROR	livekit.turn	v2@v2.0.6/server.go:184	error when handling datagram: failed to handle Allocate-request from 103.175.123.62:64066: relay already allocated for 5-TUPLE
livekit_1        | <http://github.com/pion/turn/v2.(*Server).readLoop|github.com/pion/turn/v2.(*Server).readLoop>
livekit_1        | 	/go/pkg/mod/github.com/pion/turn/v2@v2.0.6/server.go:184
livekit_1        | <http://github.com/pion/turn/v2.NewServer.func1|github.com/pion/turn/v2.NewServer.func1>
livekit_1        | 	/go/pkg/mod/github.com/pion/turn/v2@v2.0.6/server.go:85
livekit_1        | 2022-01-29T06:59:36.708Z	ERROR	livekit.turn	v2@v2.0.6/server.go:184	error when handling datagram: failed to handle Allocate-request from 103.175.123.62:59641: relay already allocated for 5-TUPLE
livekit_1        | <http://github.com/pion/turn/v2.(*Server).readLoop|github.com/pion/turn/v2.(*Server).readLoop>
livekit_1        | 	/go/pkg/mod/github.com/pion/turn/v2@v2.0.6/server.go:184
livekit_1        | <http://github.com/pion/turn/v2.NewServer.func1|github.com/pion/turn/v2.NewServer.func1>
livekit_1        | 	/go/pkg/mod/github.com/pion/turn/v2@v2.0.6/server.go:85
livekit_1        | 2022-01-29T06:59:36.780Z	ERROR	livekit.turn	v2@v2.0.6/server.go:184	error when handling datagram: failed to handle Send-indication from 103.175.123.62:64066: unable to handle send-indication, no permission added: 5.39.59.24:59326
livekit_1        | <http://github.com/pion/turn/v2.(*Server).readLoop|github.com/pion/turn/v2.(*Server).readLoop>
livekit_1        | 	/go/pkg/mod/github.com/pion/turn/v2@v2.0.6/server.go:184
livekit_1        | <http://github.com/pion/turn/v2.NewServer.func1|github.com/pion/turn/v2.NewServer.func1>
livekit_1        | 	/go/pkg/mod/github.com/pion/turn/v2@v2.0.6/server.go:85


livekit_1        | 2022-01-29T06:59:55.701Z	ERROR	livekit.pc	v3@v3.1.16/peerconnection.go:1572	Incoming unhandled RTP ssrc(3773887815), OnTrack will not be fired. stream id RTP Extensions required for Simulcast	{"room": "room06", "roomID": "RM_YNi2NTjoxmGW", "participant": "jibon", "pID": "PA_ANW5VWE5tekV"}
livekit_1        | <http://github.com/pion/webrtc/v3.(*PeerConnection).undeclaredMediaProcessor.func1.1|github.com/pion/webrtc/v3.(*PeerConnection).undeclaredMediaProcessor.func1.1>
livekit_1        | 	/go/pkg/mod/github.com/pion/webrtc/v3@v3.1.16/peerconnection.go:1572
livekit_1        | 2022-01-29T06:59:55.705Z	ERROR	livekit.pc	v3@v3.1.16/peerconnection.go:1572	Incoming unhandled RTP ssrc(3492156953), OnTrack will not be fired. stream id RTP Extensions required for Simulcast	{"room": "room06", "roomID": "RM_YNi2NTjoxmGW", "participant": "jibon", "pID": "PA_ANW5VWE5tekV"}
livekit_1        | <http://github.com/pion/webrtc/v3.(*PeerConnection).undeclaredMediaProcessor.func1.1|github.com/pion/webrtc/v3.(*PeerConnection).undeclaredMediaProcessor.func1.1>
livekit_1        | 	/go/pkg/mod/github.com/pion/webrtc/v3@v3.1.16/peerconnection.go:1572
livekit_1        | 2022-01-29T06:59:55.991Z	ERROR	livekit.pc	v3@v3.1.16/peerconnection.go:1572	Incoming unhandled RTP ssrc(1430248254), OnTrack will not be fired. stream id RTP Extensions required for Simulcast	{"room": "room06", "roomID": "RM_YNi2NTjoxmGW", "participant": "jibon", "pID": "PA_ANW5VWE5tekV"}


livekit_1        | <http://github.com/pion/webrtc/v3.(*PeerConnection).undeclaredMediaProcessor.func1.1|github.com/pion/webrtc/v3.(*PeerConnection).undeclaredMediaProcessor.func1.1>
livekit_1        | 	/go/pkg/mod/github.com/pion/webrtc/v3@v3.1.16/peerconnection.go:1572
livekit_1        | 2022-01-29T07:00:31.890Z	ERROR	livekit.pc	v3@v3.1.16/peerconnection.go:1572	Incoming unhandled RTP ssrc(2788783182), OnTrack will not be fired. stream id RTP Extensions required for Simulcast	{"room": "room06", "roomID": "RM_YNi2NTjoxmGW", "participant": "jibon", "pID": "PA_ANW5VWE5tekV"}
livekit_1        | <http://github.com/pion/webrtc/v3.(*PeerConnection).undeclaredMediaProcessor.func1.1|github.com/pion/webrtc/v3.(*PeerConnection).undeclaredMediaProcessor.func1.1>
livekit_1        | 	/go/pkg/mod/github.com/pion/webrtc/v3@v3.1.16/peerconnection.go:1572
livekit_1        | 2022-01-29T07:00:31.894Z	ERROR	livekit.pc	v3@v3.1.16/peerconnection.go:1572	Incoming unhandled RTP ssrc(3391157935), OnTrack will not be fired. stream id RTP Extensions required for Simulcast	{"room": "room06", "roomID": "RM_YNi2NTjoxmGW", "participant": "jibon", "pID": "PA_ANW5VWE5tekV"}
livekit_1        | <http://github.com/pion/webrtc/v3.(*PeerConnection).undeclaredMediaProcessor.func1.1|github.com/pion/webrtc/v3.(*PeerConnection).undeclaredMediaProcessor.func1.1>
livekit_1        | 	/go/pkg/mod/github.com/pion/webrtc/v3@v3.1.16/peerconnection.go:1572```

<@U02LCP104CQ> Can you post the sequence of your SDP offers?

Thanks for reply <@U02CM28PB4Y>. I think you're asking for this logs:


```SDP
Local SDP (Answer)

v=0
o=mozilla...THIS_IS_SDPARTA-96.0.2 8879967888639809662 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 D6:66:6E:C2:BE:4F:E8:0B:23:F6:70:E7:63:50:13:FE:00:56:74:C1:9F:76:74:19:0D:9D:BD:02:D9:C9:DE:45
a=group:BUNDLE 0
a=ice-options:trickle
a=msid-semantic:WMS *
m=application 20369 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 5.39.59.24
a=candidate:0 1 UDP 2122252543 192.168.0.5 49354 typ host
a=candidate:4 1 TCP 2105524479 192.168.0.5 9 typ host tcptype active
a=candidate:1 1 UDP 1686052863 103.175.123.62 49354 typ srflx raddr 192.168.0.5 rport 49354
a=candidate:3 1 UDP 92216831 5.39.59.24 20369 typ relay raddr 5.39.59.24 rport 20369
a=sendrecv
a=ice-pwd:3abb05b5da2fdb00ede8cabc225ff118
a=ice-ufrag:43ed0d87
a=mid:0
a=setup:active
a=sctp-port:5000
a=max-message-size:1073741823

Remote SDP (Offer)

v=0
o=- 5045255558026686653 1643440943 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 7C:43:1A:62:51:12:72:AD:B1:10:B0:44:2B:7F:3F:BD:B8:EF:A8:1A:72:FA:C3:94:A2:32:6A:7C:03:5B:91:34
a=group:BUNDLE 0
a=ice-lite
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=candidate:2205368935 1 tcp 2124414975 5.39.59.24 7881 typ host tcptype passive
a=candidate:1048589191 1 udp 2130706431 5.39.59.24 51764 typ host
a=candidate:1048589191 1 udp 2130706431 5.39.59.24 51101 typ host
a=candidate:1048589191 1 udp 2130706431 5.39.59.24 55250 typ host
a=sendrecv
a=ice-pwd:QKIsbzIlJeEcxfDoLEQomJLteimwTXSd
a=ice-ufrag:dralvVxxhMhNzjDb
a=mid:0
a=setup:actpass
a=sctp-port:5000```

```SDP
Local SDP (Offer)

v=0
o=mozilla...THIS_IS_SDPARTA-96.0.2 8185826412878002324 1 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 D8:E3:8E:7C:51:77:3C:2E:D0:38:00:B8:61:B4:F3:95:37:CB:34:CC:75:FF:29:EE:B5:36:F2:A1:1F:6D:1E:E5
a=group:BUNDLE 0 1 2
a=ice-options:trickle
a=msid-semantic:WMS *
m=video 1397 UDP/TLS/RTP/SAVPF 120 124 126 127 121 125 97 98
c=IN IP4 5.39.59.24
a=candidate:0 1 UDP 2122252543 192.168.0.5 58696 typ host
a=candidate:4 1 TCP 2105524479 192.168.0.5 9 typ host tcptype active
a=candidate:1 1 UDP 1686052863 103.175.123.62 58696 typ srflx raddr 192.168.0.5 rport 58696
a=candidate:3 1 UDP 92216831 5.39.59.24 1397 typ relay raddr 5.39.59.24 rport 1397
a=sendonly
a=end-of-candidates
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 <http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time>
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:6/recvonly <http://www.webrtc.org/experiments/rtp-hdrext/playout-delay>
a=extmap:7 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:124 apt=120
a=fmtp:127 apt=126
a=fmtp:121 max-fs=12288;max-fr=60
a=fmtp:125 apt=121
a=fmtp:98 apt=97
a=ice-pwd:b4cc725a12a8f1fd0f55dd5b258f8f05
a=ice-ufrag:810c53e6
a=mid:0
a=msid:- {39fafc9d-c327-463e-8dc2-8a9ba6a8926b}
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:121 transport-cc
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-fb:97 transport-cc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:126 H264/90000
a=rtpmap:127 rtx/90000
a=rtpmap:121 VP9/90000
a=rtpmap:125 rtx/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 rtx/90000
a=setup:actpass
a=ssrc:3198977518 cname:{20bd6d8c-af35-446e-9532-2f193fe12976}
a=ssrc:3532857185 cname:{20bd6d8c-af35-446e-9532-2f193fe12976}
a=ssrc-group:FID 3198977518 3532857185
m=application 8260 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 5.39.59.24
a=candidate:0 1 UDP 2122252543 192.168.0.5 55329 typ host
a=candidate:4 1 TCP 2105524479 192.168.0.5 9 typ host tcptype active
a=candidate:1 1 UDP 1686052863 103.175.123.62 55329 typ srflx raddr 192.168.0.5 rport 55329
a=candidate:3 1 UDP 92216831 5.39.59.24 8260 typ relay raddr 5.39.59.24 rport 8260
a=sendrecv
a=end-of-candidates
a=ice-pwd:b4cc725a12a8f1fd0f55dd5b258f8f05
a=ice-ufrag:810c53e6
a=mid:1
a=setup:actpass
a=sctp-port:5000
a=max-message-size:1073741823
m=video 0 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 0.0.0.0
a=bundle-only
a=sendonly
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 <http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time>
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:6/recvonly <http://www.webrtc.org/experiments/rtp-hdrext/playout-delay>
a=extmap:7 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>
a=extmap:8/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:9/sendonly urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:124 apt=120
a=fmtp:121 max-fs=12288;max-fr=60
a=fmtp:125 apt=121
a=fmtp:127 apt=126
a=fmtp:98 apt=97
a=ice-pwd:b4cc725a12a8f1fd0f55dd5b258f8f05
a=ice-ufrag:810c53e6
a=mid:2
a=msid:- {e05e8a15-5364-4c70-8984-6dcc4a17e347}
a=rid:q send
a=rid:h send
a=rid:f send
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:121 transport-cc
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-fb:97 transport-cc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:121 VP9/90000
a=rtpmap:125 rtx/90000
a=rtpmap:126 H264/90000
a=rtpmap:127 rtx/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 rtx/90000
a=setup:actpass
a=simulcast:send q;h;f
a=ssrc:470267524 cname:{20bd6d8c-af35-446e-9532-2f193fe12976}
a=ssrc:624114152 cname:{20bd6d8c-af35-446e-9532-2f193fe12976}
a=ssrc:2038673259 cname:{20bd6d8c-af35-446e-9532-2f193fe12976}
a=ssrc:1182823803 cname:{20bd6d8c-af35-446e-9532-2f193fe12976}
a=ssrc:2395250276 cname:{20bd6d8c-af35-446e-9532-2f193fe12976}
a=ssrc:902774350 cname:{20bd6d8c-af35-446e-9532-2f193fe12976}
a=ssrc-group:FID 470267524 624114152
a=ssrc-group:FID 2038673259 1182823803
a=ssrc-group:FID 2395250276 902774350

Remote SDP (Answer)

v=0
o=- 4752180032161829120 1643440993 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 C7:1D:C9:3B:53:8B:F3:9E:7B:2F:C9:A5:64:59:3E:1B:F0:AC:A4:A7:98:60:72:46:86:60:C8:44:28:AC:85:9B
a=group:BUNDLE 0 1
a=ice-lite
m=video 9 UDP/TLS/RTP/SAVPF 120 126
c=IN IP4 0.0.0.0
a=candidate:1048589191 1 udp 2130706431 5.39.59.24 57884 typ host
a=candidate:2205368935 1 tcp 2124414975 5.39.59.24 7881 typ host tcptype passive
a=candidate:1048589191 1 udp 2130706431 5.39.59.24 54251 typ host
a=candidate:1048589191 1 udp 2130706431 5.39.59.24 52525 typ host
a=recvonly
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:7 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=ice-pwd:OMOmiYMnFyhEEsXcDAumNxnFcHMQKUEW
a=ice-ufrag:OfKwbNMGYsLyjMLz
a=mid:0
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:126 H264/90000
a=setup:passive
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=sendrecv
a=ice-pwd:OMOmiYMnFyhEEsXcDAumNxnFcHMQKUEW
a=ice-ufrag:OfKwbNMGYsLyjMLz
a=mid:1
a=setup:passive
a=sctp-port:5000```

```SDP
Local SDP (Offer)

v=0
o=mozilla...THIS_IS_SDPARTA-96.0.2 1990112110973192701 1 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 AD:4E:3E:0A:51:26:53:6E:37:23:FC:AF:87:A8:73:60:17:F0:B5:1E:36:C4:5E:93:BD:E3:DB:36:1E:C7:52:78
a=group:BUNDLE 0 1 2
a=ice-options:trickle
a=msid-semantic:WMS *
m=video 14744 UDP/TLS/RTP/SAVPF 120 124 126 127 121 125 97 98
c=IN IP4 5.39.59.24
a=candidate:0 1 UDP 2122252543 192.168.0.5 65380 typ host
a=candidate:4 1 TCP 2105524479 192.168.0.5 9 typ host tcptype active
a=candidate:1 1 UDP 1686052863 103.175.123.62 65380 typ srflx raddr 192.168.0.5 rport 65380
a=candidate:3 1 UDP 92216831 5.39.59.24 14744 typ relay raddr 5.39.59.24 rport 14744
a=sendonly
a=end-of-candidates
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 <http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time>
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:6/recvonly <http://www.webrtc.org/experiments/rtp-hdrext/playout-delay>
a=extmap:7 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:124 apt=120
a=fmtp:127 apt=126
a=fmtp:121 max-fs=12288;max-fr=60
a=fmtp:125 apt=121
a=fmtp:98 apt=97
a=ice-pwd:269b67eac68bcf070792665bdbb41fba
a=ice-ufrag:f9a67eb5
a=mid:0
a=msid:- {3c70c2cf-ad00-4e68-8407-12b706bbaf00}
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:121 transport-cc
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-fb:97 transport-cc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:126 H264/90000
a=rtpmap:127 rtx/90000
a=rtpmap:121 VP9/90000
a=rtpmap:125 rtx/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 rtx/90000
a=setup:actpass
a=ssrc:2572696594 cname:{f67a7867-8e21-4bf8-9ac5-90afd20637ea}
a=ssrc:170425545 cname:{f67a7867-8e21-4bf8-9ac5-90afd20637ea}
a=ssrc-group:FID 2572696594 170425545
m=application 63486 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 103.175.123.62
a=candidate:0 1 UDP 2122252543 192.168.0.5 63486 typ host
a=candidate:4 1 TCP 2105524479 192.168.0.5 9 typ host tcptype active
a=candidate:1 1 UDP 1686052863 103.175.123.62 63486 typ srflx raddr 192.168.0.5 rport 63486
a=sendrecv
a=ice-pwd:269b67eac68bcf070792665bdbb41fba
a=ice-ufrag:f9a67eb5
a=mid:1
a=setup:actpass
a=sctp-port:5000
a=max-message-size:1073741823
m=video 0 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 0.0.0.0
a=bundle-only
a=sendonly
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 <http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time>
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:6/recvonly <http://www.webrtc.org/experiments/rtp-hdrext/playout-delay>
a=extmap:7 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>
a=extmap:8/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:9/sendonly urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:124 apt=120
a=fmtp:121 max-fs=12288;max-fr=60
a=fmtp:125 apt=121
a=fmtp:127 apt=126
a=fmtp:98 apt=97
a=ice-pwd:269b67eac68bcf070792665bdbb41fba
a=ice-ufrag:f9a67eb5
a=mid:2
a=msid:- {63c78024-78ac-4e52-8a8f-614985e257d3}
a=rid:q send
a=rid:h send
a=rid:f send
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:121 transport-cc
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-fb:97 transport-cc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:121 VP9/90000
a=rtpmap:125 rtx/90000
a=rtpmap:126 H264/90000
a=rtpmap:127 rtx/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 rtx/90000
a=setup:actpass
a=simulcast:send q;h;f
a=ssrc:3441608811 cname:{f67a7867-8e21-4bf8-9ac5-90afd20637ea}
a=ssrc:3392232184 cname:{f67a7867-8e21-4bf8-9ac5-90afd20637ea}
a=ssrc:4288062375 cname:{f67a7867-8e21-4bf8-9ac5-90afd20637ea}
a=ssrc:3069895670 cname:{f67a7867-8e21-4bf8-9ac5-90afd20637ea}
a=ssrc:1056196606 cname:{f67a7867-8e21-4bf8-9ac5-90afd20637ea}
a=ssrc:3940440004 cname:{f67a7867-8e21-4bf8-9ac5-90afd20637ea}
a=ssrc-group:FID 3441608811 3392232184
a=ssrc-group:FID 4288062375 3069895670
a=ssrc-group:FID 1056196606 3940440004

Remote SDP (Answer)

v=0
o=- 6701284935117595057 1643441042 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 1E:BD:68:E4:8A:94:2A:8F:04:98:B2:C4:29:91:15:AE:35:C7:10:EB:7B:7F:24:C0:C2:F2:8F:C4:A6:A9:B5:30
a=group:BUNDLE 0 1 2
a=ice-lite
m=video 9 UDP/TLS/RTP/SAVPF 120 126
c=IN IP4 0.0.0.0
a=candidate:1048589191 1 udp 2130706431 5.39.59.24 58784 typ host
a=candidate:1048589191 2 udp 2130706431 5.39.59.24 58784 typ host
a=candidate:1048589191 1 udp 2130706431 5.39.59.24 50734 typ host
a=candidate:1048589191 2 udp 2130706431 5.39.59.24 50734 typ host
a=candidate:1048589191 1 udp 2130706431 5.39.59.24 59395 typ host
a=candidate:1048589191 2 udp 2130706431 5.39.59.24 59395 typ host
a=candidate:2205368935 1 tcp 2124414975 5.39.59.24 7881 typ host tcptype passive
a=candidate:2205368935 2 tcp 2124414975 5.39.59.24 7881 typ host tcptype passive
a=recvonly
a=end-of-candidates
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:7 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=ice-pwd:kHXZObVMrUrQiznGAUNFLEBmaNXvIBjE
a=ice-ufrag:VTQGRSJkwyNLnoQc
a=mid:0
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:126 H264/90000
a=setup:passive
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=sendrecv
a=ice-pwd:kHXZObVMrUrQiznGAUNFLEBmaNXvIBjE
a=ice-ufrag:VTQGRSJkwyNLnoQc
a=mid:1
a=setup:passive
a=sctp-port:5000
m=video 9 UDP/TLS/RTP/SAVPF 120 126
c=IN IP4 0.0.0.0
a=recvonly
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:7 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=ice-pwd:kHXZObVMrUrQiznGAUNFLEBmaNXvIBjE
a=ice-ufrag:VTQGRSJkwyNLnoQc
a=mid:2
a=rid:q recv
a=rid:h recv
a=rid:f recv
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:126 H264/90000
a=setup:passive
a=simulcast:recv q;h;f```

<@U02LCP104CQ> Something puzzling here is that the first `Local SDP (offer)` has three sections. But, the answer has only two sections. That is puzzling. Need to find a way to repro this.

image.png

<@U02CM28PB4Y> thank you. Let me know if need more information from me. I'm noticing another problem not sure if this is related or not. In previous version I was able to use livekit from localhost but from this version it's no longer working.  Status remain like screenshot. I'm using docker to run livekit. I tested from both firefox &amp; chrome.

For the last issue, <@U01KZ61GV5Z> might be more familiar. I am not aware of any changes there.

For the previous issue with screenshare + camera at the same time, would you be able to test it on Chrome? If Chrome also does not work, can you please send the SDPs just like you did for the Firefox case :point_up::skin-tone-4:

<@U02CM28PB4Y> thank you. From Chrome I didn't notice this problem! I tested several time but wasn't able to reproduce :grinning: except this error:

```livekit_1        | 2022-01-29T17:29:45.356Z	ERROR	livekit.turn	v2@v2.0.6/server.go:184	error when handling datagram: failed to handle Allocate-request from 103.175.123.62:53274: relay already allocated for 5-TUPLE
livekit_1        | <http://github.com/pion/turn/v2.(*Server).readLoop|github.com/pion/turn/v2.(*Server).readLoop>
livekit_1        | 	/go/pkg/mod/github.com/pion/turn/v2@v2.0.6/server.go:184
livekit_1        | <http://github.com/pion/turn/v2.NewServer.func1|github.com/pion/turn/v2.NewServer.func1>
livekit_1        | 	/go/pkg/mod/github.com/pion/turn/v2@v2.0.6/server.go:85```

Sounds good <@U02LCP104CQ>. Thank you. Will look at the Firefox case.

<@U02LCP104CQ> I was able to reproduce this with Firefox.

Looks like a combination of Pion + Firefox.

If I set up a branch of `livekit-server`, would you be able to try that branch?

Thank you <@U02LCP104CQ>. I have been trying to set up a branch and I am running into my limited understanding of `golang`. I am not able to point to the Pion PR I did for fixing this from lk-server build :disappointed: Something about versions not lining up. Will let you know when I have a branch ready to test.

No problem <@U02CM28PB4Y>. I'll be waiting for your update.

<@U02LCP104CQ> Can you please try this branch of `livekit-server` when you get a chance? - <https://github.com/livekit/livekit-server/tree/raja_firefox_try>

If you don't mind, if you can run it through your other use cases also, that would be great. Just in case the Firefox use case works, I just want to make sure that I did not break anything else :slightly_smiling_face:

Thank you <@U02CM28PB4Y>! I wasn't able to reproduce above problem this time :grinning:

Regarding other use case, I tested around 10 minutes but didn't notice any other problem. I mean audio, video &amp; screen share is working as before.

Thank you <@U02LCP104CQ> . That’s great! 

I'm not a 100% on this, but from what I see in the caddy.go file, caddy is used as a reverse proxy to connect to 7880 internally already.
have you tried pointing your `wss://` url to port `443`?

Thank you for answering.
I tried this already and got the same result.

I'm still asking myself if a TLS terminination via load balancer on 7880 is necessary in this generated setup <https://docs.livekit.io/deploy/vm>
as mentioned in here
<https://docs.livekit.io/deploy/ports-firewall>

Hey Jonathan, have you tried using the generated files? it should set up Caddy on 443, as a reverse proxy to both LiveKit WSS as well as TURN/TLS.

if you are not using caddy, then another reverse proxy/load balancer will need to be used in front of 7880 that can terminate TLS

Thank you so much guys!

Your answer helped me to understand the idea.
And yes: I did generate a setup with your new *caddyl4* concept.

Although `curl https://&lt;mydomain&gt;` gives back an *"OK"* from Caddy, `curl http://&lt;mydomain&gt;` says `(56) Recv failure: Connection reset by peer`

I will continue to try and figure out what's wrong with it.

How do you guys *debug* Caddy routing?
With `docker log`, `netcat` or something better?

I think this is expected, with our caddy set up, the install is secure behind HTTPS. It does not listen to plain HTTP traffic. The `OK` response is returned by livekit server

hey <@U02SGSET1RT>, we will be handling this automatically in the next version of server &amp; client SDKs

the server will automatically re-issue updated tokens periodically to all connected clients

<@U01KZ61GV5Z> that’s good! I’m interested to contribute to speed things up :grin:

awesome! would be good if you can give it a run and see if it's working to your expectations.

The PR that added this capability is in <https://github.com/livekit/livekit-server/pull/365>

All of our SDKs should have this capability in `main`

So the feature is currently implemented, just that there’s more testing needed before it can be released ?

it'll be released soon :slightly_smiling_face: but as with all new features, it's possible there are edge cases that it doesn't cover.

That’s good to hear. We’ll test this out early next week and let you know

metadata is read-only from the client because they are considered privileged data. (i.e. someone may use it to encode application-level permissions).

we'll leave updates to the server APIs, where you can control permissions within your own app.

That's how I'm doing it now and that works for me! Thanks!

we were just talking about how we'd enable this! It'd be great to understand your use case better?
• what type of data would you be sending? are they like files (where you need the beginning of it to make sense) or streams where each packet would make sense independently?
• is this something that you would want to broadcast to the entire room? would a subscriber have control over if they would get the tracks?

I most probably don't get the question, still will try to answer,  isn't the data API in client and server SDKs sufficient for sending data/messages to all/specific participants?

I was looking into synchronizing YJS datastructures over the already-opened LiveKit webrtc connection between all participants.

YJS protocol sends messages as raw Uint8Arrays. It doesn’t need to be ordered, but delivery guarantees are nice. With raw DataTracks, you can do that.

There’s also the matter of sorting traffic at both ends. With only 1 data channel (or 2 - ordered/unordered), you’d need to do something to distinguish between YJS message traffic and other kinds of messages… like prepending a flag into the Uint8Array to signify what kind of message it is. Kind of a pain for something the browser has already solved with opening separate DataTrack streams.

The Twilio client SDK has this feature, might be a source for API design. They just let you publish a DataTrack like any other kind of track.

<@U02EN4Y8DCM> Thanks for the explanation, I guess you are working on a deeper level than i do, for my case, i’m using _`room.localParticipant.publishData()`_ to send chat, notifications and system events and it’s working fine for my use case

Screen Shot 2022-01-29 at 11.55.55 AM.png

yes! there's definitely a case for using WebRTC as the protocol for delivery for live streams. It will require fanning out one stream to multiple. (i.e. what SFUs are good at already :wink: )

<@U01KZ61GV5Z> Thanks so much , can you expand a bit on this and if we can use Livekit in this distributed SFU setup ?

it has all the building blocks for it, but would require some work to piece it together. The idea is each SFU could act as a media subscriber in the room hosted by another SFU instance.

We are looking at enabling this capability in the cloud offering that we are working on (that makes full use of livekit-server). Will share more information about it as we get closer!

Super cool, looking forward to learn more about the cloud offering

I'm noticing these candidates are from Dockers private network. did you pass --node-ip when running it?

No, I didn't. Will that be docker IP? I was using docker-composer to boot up.

I'm using like this:
`docker-compose.yaml`
```version: "3"
services:
  redis:
    image: redis
    ports:
      - "6379:6379/tcp"
  livekit:
    image: livekit/livekit-server
    ports:
      - "7880:7880/tcp"
      - "7881:7881/tcp"
      - "7882:7882/udp"
    volumes:
      - .:/app
    command: --config "/app/livekit.yaml" --dev
    depends_on:
      - redis```

the command should pass <https://docs.livekit.io/guides/getting-started/#starting-with-docker|--node-ip> to get around docker's private IP

Thank you <@U01KZ61GV5Z>. It's working but always need to update IP if it's dynamic.

I'm not sure why it worked before.. it's always given me problems when it used docker's internal IP previously.

:wave: Thanks to the team for producing such an exciting project!

:wave: 

You can certainly do 1:1 video calls with LiveKit, but it currently does not support a p2p mode. That is, all communication passes through the SFU.

Most probably you'll require to set content header type to `application/protobuf`  although I never used ruby :grin:

it sounds like it didn't hit the right endpoint.. how was `room_client` created?

Thanks that helped me already - I didnt see that the new ruby sdk needed a different url than the manuell created protobuffers. I ended my url with '/twirp' which is not necessary in the ruby sdk.

hey alex, this isn't supported today, but we are looking at it! we have a customer who's doing this with GStreamer appsrc and our Go SDK.

My guess would be your CPU was not able to process all the simultaneous encoding/decoding at the same time. I’m sure when you deploy to a dedicated server in production, it’ll be able to handle way more than 8 :wink: the livekit team has run some tests, see <https://docs.livekit.io/deploy/benchmark>

Another thing to note, the docker quick-start steps are using a single-port UDP mux (for ease of getting started). sharing a single udp port is not the most performant.

There's no one-fit-all answer to this question. Take a look at the benchmark results here. <https://docs.livekit.io/deploy/benchmark>

by the way, what I’m doing is calling `LiveKit.connect(this@CallService, gatewayUrl, token, connectOptions, null)`  and then doing
```val localParticipant = callRoom!!.localParticipant
localParticipant.setMicrophoneEnabled(true)
localParticipant.setCameraEnabled(true)```
the crash happens in that last call, it’s the `setCameraEnabled`  method call

hey <@U02KJGV339S>, which version are you on? this should be fixed in 0.8.1

hello there! I’m also seeing this and I’m on `livekit-android:1.0.0`

what’s the proper way to access `Room.localParticipant`?
I’m creating a room within a suspend function through `LiveKit.connect()` and accessing `localParticipant` immediately after, but sometimes I get that exception

hmm, `localParticipant` should be valid if it connected, do you have any logs for this?

hey,
if it's down to handling the room state it should be enough to subscribe to `RoomEvent.Reconnecting` and `RoomEvent.Disconnected` after storing the initial Connected state on the first successful connection to get updates for the roomstate.

Hey, thanks for the reply, appreciate it.

My problem is not listening for the change of state.  What I mean is the instanciation of the object.  My bad on the wording.

For whatever reason, when I try to save it.  It's getting mangled.

Are you trying to save the room object itself ?

maybe it would help you to use a helper file as a workaround that holds the only reference to your room? pseudo:
```// roomHelper.ts
let room: Room;

export default function getRoom = () =&gt; {
 if(!room) room = new Room(opts);
 return room;
}

// other files
function doSomethingWithRoom() {
  getRoom().connect(...)
}```
or any other kind of singleton approach

Thanks for the suggestion.  I've been trying to keep to the react lib.  If if I hit a dead end, I'll look at the js lib then.

ah! i didn't know.
would it be an option to set the room globally on the window object like in the example ?
<https://github.com/livekit/livekit-react/blob/98745540341654c279ded0e9abdd217b628d201b/example/src/RoomPage.tsx#L121>

Great find!

That works.

From the livekit server console:

```{"level":"debug","ts":1643807820.946342,"logger":"sfu","caller":"buffer/buffer.go:155","msg":"Setting feedback","type":"webrtc.TypeRTCPFBGoogREMB"}```


Sigh, this is a bother.  I tried saving it into state using valtio again and it's no longer showing the previous issue.  It's now working just fine.

So I no longer have this issue.  :thinking_face:

Thanks for your help though, much appreciated!

try listening to `TrackEvent.Ended` on `screenSharePublication` of useParticipant

Thanks for the reply again.  Ok, let me look into that.

So I'm using the localParticipant from the room instance.

```const participant = useParticipant(useStore.livekit.participant as Participant)

participant.screenSharePublication?.track?.on(TrackEvent.Ended, () =&gt; {
   console.log("YOLO")
})```
Unfortunately nothing seems to remotely toggle when I hit the button.

hmm. are you subscribing to the event after the screensharing has started or already before? I guess you would have to do it once the screensharing has already started.

another thing to try would be to subscribe directly to the underlying mediastreamtrack: `screenSharePublication.track.mediastreamTrack.on('ended')`

I actually got it to fire, but after I saved the page and it re-hydrated.  So the underlying logic works.  I just now have to figure out how to make it work with the logic i have.

I'm going to bail on the react lib and do this using the js lib.

If I'm getting this much resistance, the universe is telling me something.  :smile:

Thanks for your help though!

Hey <@U02S1919YLB>, your needs may be different, but a little thing I built handles the “Stop Sharing” button in chrome using the React lib, here:
<https://github.com/livekit/hq/blob/23a9f1c3ef139f5b795443b529e21a60f4bba175/client/src/components/LocalUserMedia.tsx#L33>

What I do is let the `useParticipant` hook handle the state for me:
<https://github.com/livekit/livekit-react/blob/master/src/useParticipant.ts>

hey <@U02S1919YLB>, which version of the react SDK are you using? It should fire `LocalTrackUnpublished` when screenshare is disabled

<@U01KZ61GV5Z> "livekit-react": "0.5.3",

Been so focused.  It didn't occur to me to check out if another version was available. :sweat_smile:

Ah there is <https://github.com/livekit/livekit-react/releases/tag/v0.6.2|v0.6.2>.  I will check it out in the morning then.  Thanks

Lots of helpful fixes in between those two versions :slightly_smiling_face:

Awesome, that's great to hear.  I'd rather use the react-lib to be honest.

As you work with it, definitely let us know how we can make it easier/better for you! :pray:

Screenshot 2022-02-03 at 13.59.04.png

<@U01KZ61GV5Z> <@U01KZ0SCDKL> Thank you so much for pointing me in the right direction.  As a result of upgrading, all the issues I encountered yesterday were not there.  And was I able to very quickly implement screen sharing:

very happy to hear <@U02S1919YLB>! Looking forward to trying your Discord alternative! :slightly_smiling_face:

Screenshot from 2022-02-02 16-33-21.png

Screenshot from 2022-02-02 16-31-49.png

hey, from the screenshot it looks like you are connecting to `ws://` instead of `wss://` . that would explain the error messages that you are seeing

That's it!!
Merci :partying_face: <@U02EU2ZPTQU>

Still wondering about this failed connection attempts from Google servers in the beginning.

yes, you can do this today. connect to the room with `autosubscribe=false` and it should be able to send and receive data packets

oh great, wasn’t aware of it, thanks for the clarification

livekit_sigsegv.txt

Hey <@U02UKGBNK27> which version of the server are you running? <https://github.com/livekit/livekit-server/releases/tag/v0.15.3|v0.15.3> has a fix that is related to this

basically the video decoder crashes sometimes when we send it a blank pixel between subscriptions.

<@U01KZ61GV5Z> We are indeed using 0.15.3

got it, it might be something else. I'll file an issue and we'll investigate.

<@U02UKGBNK27> looks like this crash might have gone away with some webrtc updates. after updating to m97, I can't seem to repro this crash any more

tracking the issue here: <https://github.com/livekit/client-sdk-android/issues/52>

livekit-abc5727e537-m97debug.aar

if it's possible, could you try this build and see if it still crashes for you? <https://livekit-users.slack.com/files/U01NZKTNE1H/F0323J0M49M/livekit-abc5727e537-m97debug.aar>

sorry, the above aar won't work when included directly. I've published the m97 build on <https://jitpack.io/#davidliu/livekit-custom-builds/abc5727e537-m97debug-SNAPSHOT|jitpack>. replace livekit-sdk dependency line in your gradle file with:
```implementation 'com.github.davidliu:livekit-custom-builds:abc5727e537-m97debug-SNAPSHOT'```

<@U01NZKTNE1H> Thanks! Will test and get back to you!

Sorry for the delay on this, but this fix has been working great for us, thanks so much !

great to hear! v0.9.0 onwards has m97 in it, so you can use that instead of the test build if you haven't already changed to that

Screen Shot 2022-02-02 at 8.31.47 PM.png

<@U02UMFKPC6Q> that is really strange.. this means that the server didn't think it was a new connection. Do you have any repro steps for this? Do you have any server logs when this does happen?

Hello David, Yup, I have both, will share shortly

Hey <@U028SSAKLQ1>, is that particular participant `XYZ` seeing any video/audio issues during the session?

we've discovered an issue in pion (the underlying webrtc lib) that would get into this state occasionally with FF.

there's a fix for this issue in `master`, and we'll validate &amp; release

Hey @david, XYZ was the other participant and I stopped receiving video and audio signals from them. They continued to receive my stream. No FF involved though, we were both using Chrome on macos. (Edit: XYZ was not me as originally written)

Are you positive that the issue you observed is restricted to FF?

I see. that might be a different issue.. are there any logs prior to this packetio.Buffer warning?

Unfortunately nothing immediately prior, but somewhat near:
```
Feb 03 14:23:58 livekit[663]: 2022-02-03T14:23:58.291+0100        DEBUG        livekit        sfu/streamallocator.go:876        streamed tracks changed        {"room": "73741964-bd91-4652-803e-e1b8b7a293ef", "roomID": "RM_tNbUBZLRCCE2", "participant": "XYZ", "pID": "PA_vQ83QWbB3HVP", "update": {"StreamStates":[{"ParticipantID":"PA_vQ83QWbB3HVP","TrackID":"TR_56LYosKUyLPk","State":0}]}}
Feb 03 14:23:58 livekit[663]: 2022-02-03T14:23:58.291+0100        DEBUG        livekit        rtc/signalhandler.go:67        updated subscribed track settings        {"room": "73741964-bd91-4652-803e-e1b8b7a293ef", "roomID": "RM_tNbUBZLRCCE2", "participant": "XYZ", "pID": "PA_vQ83QWbB3HVP", "trackID": "TR_56LYosKUyLPk", "settings": "track_sids:\"TR_56LYosKUyLPk\" width:1147 height:645"}
Feb 03 14:23:58 livekit[663]: 2022-02-03T14:23:58.316+0100        DEBUG        livekit        rtc/participant.go:1537        send pli        {"room": "73741964-bd91-4652-803e-e1b8b7a293ef", "roomID": "RM_tNbUBZLRCCE2", "participant": "_ME", "pID": "PA_XCoMXdqPRMU4", "ssrc": 3269817972}
Feb 03 14:23:58 livekit[663]: 2022-02-03T14:23:58.370+0100        DEBUG        livekit        rtc/signalhandler.go:67        updated subscribed track settings        {"room": "73741964-bd91-4652-803e-e1b8b7a293ef", "roomID": "RM_tNbUBZLRCCE2", "participant": "XYZ", "pID": "PA_vQ83QWbB3HVP", "trackID": "TR_56LYosKUyLPk", "settings": "track_sids:\"TR_56LYosKUyLPk\" width:1096 height:617"}```

Thank you so much, ping me if I can help! :pray:

filed: <https://github.com/livekit/livekit-server/issues/401>

any redis instance would work there! I've tried Google's managed redis and that worked well too

I am currently using the LiveKit-Server v0.15.3. When I received that error I had problems with receiving and sending data

Moreover my go-server switches the state ever 10-20 second and gives me the following Info:

`2022-02-04T09:53:42.006Z        INFO    livekit sfu/streamallocator.go:638      state change    {"room": "webcom-64d92b90a4", "roomID": "RM_TuRABWzbHKei", "participant": "TestA", "pID": "PA_8msFuts2sqCd", "from": "STABLE", "to": "DEFICIENT"}`
`2022-02-04T09:53:50.566Z        DEBUG   livekit sfu/streamallocator.go:876      streamed tracks changed {"room": "webcom-64d92b90a4", "roomID": "RM_TuRABWzbHKei", "participant": "TestA", "pID": "PA_8msFuts2sqCd", "update": {"StreamStates":[{"ParticipantID":"PA_8msFuts2sqCd","TrackID":"TR_jjVe58Ve6F6P","State":0}]}}`
`2022-02-04T09:53:50.567Z        INFO    livekit sfu/streamallocator.go:638      state change    {"room": "webcom-64d92b90a4", "roomID": "RM_TuRABWzbHKei", "participant": "TestA", "pID": "PA_8msFuts2sqCd", "from": "DEFICIENT", "to": "STABLE"}`
`2022-02-04T09:53:50.571Z        DEBUG   livekit rtc/participant.go:1537 send pli        {"room": "webcom-64d92b90a4", "roomID": "RM_TuRABWzbHKei", "participant": "test123 (Guest)", "pID": "PA_LTHpGfx2KQ9W", "ssrc": 1584639281}`

During the status "deficient" the streams will pause.

there have been cases where the error would print without an actual impact. So just having the message isn't alone a cause for concern.

the bandwidth messages are due to congestion controller not detecting sufficient bandwidth, you can play with the <https://github.com/livekit/livekit-server/blob/master/config-sample.yaml#L44|config options here>

hey <@U029B2U17RQ>, it is based off of caddy-l4! Our Dockerfile is here: <https://github.com/livekit/deploy/tree/main/caddyl4>

Ah, perfect! It looks very straight forward. I'm experiencing an odd behavior where ca. 10% of the `fetch` requests from Chrome take ~10min. From `curl` everything is fine. So I will need to investigate here . . .

FYI: Fixed my issues by not using L4 routing anymore. Turned off TURN (for which L4 seems to be needed) and now all backends respond in a very reasonable time :slightly_smiling_face:

<@U029B2U17RQ>, are you running off of the VM deployed with our generator/caddy config? Or is this a different configuration?

this is strange that SNI isn't doing it there.. Just to be sure, do you have a different TURN domain than primary?

Yes, I used the generated caddy config and added two extra http endpoints for livekit/hq:

```apps:
  tls:
    certificates:
      automate:
        - <http://office.example.com|office.example.com>
        - <http://backend.office.example.com|backend.office.example.com>
        - <http://livekit.office.example.com|livekit.office.example.com>
        - <http://livekit-turn.office.example.com|livekit-turn.office.example.com>
  layer4:
    servers:
      main:
        listen: [":443"]
        routes:
          - match:
            - tls:
                sni:
                  - "<http://livekit-turn.office.example.com|livekit-turn.office.example.com>"
            handle:
              - handler: tls
              - handler: proxy
                upstreams:
                  - dial: ["localhost:5349"]

          - match:
              - tls:
                  sni:
                    - "<http://livekit.office.example.com|livekit.office.example.com>"
            handle:
              - handler: tls
                connection_policies:
                  - alpn: ["http/1.1"]
              - handler: proxy
                upstreams:
                  - dial: ["localhost:7880"]

          - match:
              - tls:
                  sni:
                    - "<http://office.example.com|office.example.com>"
            handle:
              - handler: tls
                connection_policies:
                  - alpn: ["http/1.1"]
              - handler: proxy
                upstreams:
                  - dial: ["localhost:3000"]
          
          - match:
              - tls:
                  sni:
                    - "<http://backend.office.example.com|backend.office.example.com>"
            handle:
              - handler: tls
                connection_policies:
                  - alpn: ["http/1.1"]
              - handler: proxy
                upstreams:
                  - dial: ["localhost:2567"]```

I think this is because it's expecting permissions to be a ruby object (from protobuf), instead of hash.

Screen Shot 2022-02-05 at 1.26.14 AM.png

Screen Shot 2022-02-05 at 11.10.19 AM.png

also for the pods i see there is one pending, i guess that contributes to the issue?

Hi <@U02UMFKPC6Q>, I would suggest you to have a subdomain for webrtc and one for turn as an example if your domain is <http://abc.com|abc.com>,  have something like <http://webrtc.abc.com|webrtc.abc.com> and <http://stun.webrtc.com|stun.webrtc.com>. Make sure that the <http://webrtc.com|webrtc.com> is specified in your values file in the loadbalancer section.
Create a A record in your DNS that point <http://webrtc.com|webrtc.com> to the IP address of your ingress controller.

Hi <@U03134XL1M2> I have already a sub domain for livekit and another for turn with correct DNS , will redo the deployment and see

Did you configure SSL? Also try to add a stun server.

Screenshot 2022-02-05 124311.png

I have another laptop, that does the following:

You're trying from a non ssl domain. This won't work in latest version of browsers. You'll require to work either a SSL enabled domain or localhost

<@U02LCP104CQ> No, I have not configured ssl.  Because for me it's a huge pain.  I'm developing locally.  So I am hitting the main server at port 8080.  So the camera and mic are accessible.  When I try to use SSL.  Then I get the self certification error message.

In that case you can use docker to setup livekit locally &amp; later try from localhost.

I can't do that I've got an old laptop and running docker livekit and screensharing overloads it.

As I mentioned before in latest browser it won't work. You can easily setup livekit in cloud &amp; later can use.

You can also try to add stun server in livekit config file:

```rtc:
  tcp_port: 7881
  udp_port: 7882
  stun_servers:
    - <http://stun.l.google.com:19302|stun.l.google.com:19302>```

I know this sucks.  In a few months I will be getting a new laptop and then I'll have everything running in docker and dev will be much better.  But I'm not there yet :confused:

Still if your development environment isn't in localhost then you'll face problem.

As I say, my primary machine is running localhost and I have no issue at all.

Alright, unfortunately still the same.  Thanks for replying to question.  I'll pause development until I get a new laptop.

Got round it in the end.  Had to install the dev env and app onto the device to get around localhost restrictions.  Now works fine!

Full error: <https://livekit-users.slack.com/files/T01KVSV78P7/F0327SK44KB>

I did upgrade to flutter 2.10.0 recently and I suspect this is the cause.

I've done some debugging in the build.gradle and changed the min and target version to 21 and received the same errors.

hey, william, I think this might just be due to using the wrong jdk for java compilation

if you're using android studio, this might help: <https://stackoverflow.com/a/69250502/295675>

I'm using VSCode but I'm taking a look now. Thanks!

Ah, yeah that makes sense. I think openjdk 11 is what android studio uses, try replacing your java with that