LiveKit Community

~Are datachannels on the client-android-sdk working ?~

Is this possible to send data to a specific participant and not the whole room ? (Client side)

sure, you can create a PR as well. it should be straightforward to implement

Ok nice, I have another question, I saw that in the Android client SDK, the room listener doesn't have an OnJoin event so how can we now when the LocalParticipant has been initialized ?

yeah, it should be connected right after the function returns

to implement selective forwarding for data packets, you can make the protocol take in a list of destination sids:
```<https://github.com/livekit/protocol/blob/main/livekit_rtc.proto#L149>```

modify the server to use that field to filter: <https://github.com/livekit/livekit-server/blob/master/pkg/rtc/room.go#L393>

then add this capability to the clients as a parameter when publishing data: <https://github.com/livekit/client-sdk-android/blob/master/livekit-android-sdk/src/main/java/io/livekit/android/room/participant/LocalParticipant.kt#L155|https://github.com/livekit/client-sdk-android/blob/master/livekit-android-sdk/src/[…]in/java/io/livekit/android/room/participant/LocalParticipant.kt>

for now, I guess you could encode the desired receipient in the payload itself?

Is there already a test for DataChannels in livekit-server ?

yes, but not directly.. the test only covers active speaker updates (which uses data channels)

the best place to add one would be in room_test: <https://github.com/livekit/livekit-server/blob/master/pkg/rtc/room_test.go>

there are helpers to create a room with N mock participants, and you could look at both the number of times `SendDataPacket` had been called with the mock participant

ahh ok I see the issue.. p is a mock object, and will not be able to `SendDataPacket`

this is a bit tricky.. do you want to push this up to the branch? I can take a look at wiring it together

Yes I want to have a test that verify if the destination filter works

try something like this:
```func TestDataChannel(t *testing.T) {
	t.Run("participants are receiving data", func(t *testing.T) {
		rm := newRoomWithParticipants(t, testRoomOpts{num: 3})
		participants := rm.GetParticipants()
		p := participants[0].(*typesfakes.FakeParticipant)
		//p2 := participants[1].(*typesfakes.FakeParticipant)

		packet := livekit.DataPacket{
			Kind: livekit.DataPacket_RELIABLE,
			Value: &amp;livekit.DataPacket_User{
				User: &amp;livekit.UserPacket{
					ParticipantSid: p.ID(),
					Payload:        []byte("Some text..."),
				},
			},
		}
		p.OnDataPacketArgsForCall(0)(p, &amp;packet)

		// ensure everyone has received the packet
		for _, op := range participants {
			fp := op.(*typesfakes.FakeParticipant)
			if fp == p {
				require.Zero(t, fp.SendDataPacketCallCount())
				continue
			}
			require.Equal(t, 1, fp.SendDataPacketCallCount())
			require.Equal(t, packet.Value, fp.SendDataPacketArgsForCall(0).Value)
		}
	})
}```

ah this is due to some flakiness in the tests..

I fixed it in master, let me re-run it on your PR

Because I saw that in the Room class, we're waiting connectContinuation

yes, once connect() returns, (assuming the disconnected callback wasn't called)

That’s strange, I’m doing exactly the same on my unity implementation but Datachannels aren’t directly ready 

are you establishing `_lossy` and `_reliable` channels? those are the only channels that the server would know how to handle

Yes, they are working If I wait like 2 seconds 

Maybe something wrong with WebRTC of Unity 

hmm, that's strange.. it should be ready then as ICE connection happens after negotiation

Does the backend assign the sids to the tracks? I'm stumped as to why the second time around the old sid is showing up

in step 3.. what do you mean "gets the new track but still shows sid_1?"

is it by looking at a specific callback, or iterating through the participant's tracks?

are you updating those when server sends `ParticipantUpdate` messages?

so basically, the second time client_1 publishes, client_2 sees the original sid on the track

this is what JS client does, as a reference: <https://github.com/livekit/client-sdk-js/blob/main/src/room/Room.ts#L83>

sorry, on the subscriber side I'm using the js client at the moment

publish from unity,  subscribe from web. Subscribe seems to have the old sid. I'm assuming I don't need to do anything with the sid on the publish side?

oh i see what you mean. right, publisher doesn't need to worry about SIDs

in this function:
```func (p *ParticipantImpl) getPendingTrack(clientId string, kind livekit.TrackType, deleteAfter bool) *livekit.TrackInfo {
	p.lock.Lock()
	defer p.lock.Unlock()
	ti := p.pendingTracks[clientId]

	// then find the first one that matches type. with MediaStreamTrack, it's possible for the client id to
	// change after being added to SubscriberPC
	if ti == nil {
		for cid, info := range p.pendingTracks {
			if info.Type == kind {
				ti = info
				clientId = cid
				break
			}
		}
	}

	// if still not found, we are done
	if ti == nil {
		logger.Errorw("track info not published prior to track", nil, "clientId", clientId)
	} else if deleteAfter {
		delete(p.pendingTracks, clientId)
	}
	return ti
}```
when would ti == nil?

FWIW, i've tried my test by reusing the client-id and also by changing the client-id on the publisher side

ok, so here's how it works.. publisher generates a unique cid for the track, tells server desire to add a track

then the track's cid must match that.. so we know which track is which

makes sense, I bet my track cid is unset or incorred or something

on some platforms, the actual webrtc track's id changes between when we read the data and when it gets sent.. so in that case we just assume it's the right track and grab the first one of type

I think the scenario you described could happen *if* the first publish didn't complete successfully

i.e. so that `delete(p.pendingTracks, clientId)` didn't get called

unity doesn't have an API for setting it, I was using something called a `label` but I bet it's different

i'll try something real quick - this was helpful

oh... you don't have to set it.. it'd be better to grab the MediaStreamTrack's id

ok great, yeah that's most likely my problem here

i bet unity is also reusing the same id twice...

hrmm, so even after changing that, it's the same problem :thinking_face:

do the client ids need to be of a particular format? or any string?

after add track.. are you actually publishing the track on the peer connection?

also, in that server code, if we do hit the first ti == nil condition, the deleteAfter would not work right?

you could print out on the server side ( in the above function) what is the track that's received

so one thing that might be happening is that I add a DataChannel to the peerconnections on the unity side so that it will go through the ice flow (because of <https://github.com/Unity-Technologies/com.unity.webrtc/pull/115>)

I don't do anything with these data channels though and I do see errors server-side because of it:
```{"level":"error","ts":1623713809.9652486,"caller":"rtc/participant.go:789","msg":"track info not published prior to track","clientId":"data","stacktrace":"<http://github.com/livekit/livekit-server/pkg/rtc.(*ParticipantImpl).getPendingTrack\n\t/workspace/pkg/rtc/participant.go:789\ngithub.com/livekit/livekit-server/pkg/rtc.(*ParticipantImpl).onDataChannel\n\t/workspace/pkg/rtc/participant.go:758\ngithub.com/pion/webrtc/v3.(*API).NewPeerConnection.func1\n\t/go/pkg/mod/github.com/pion/webrtc/v3@v3.0.29/peerconnection.go:176\ngithub.com/pion/webrtc/v3.(*SCTPTransport).onDataChannel.func1\n\t/go/pkg/mod/github.com/pion/webrtc/v3@v3.0.29/sctptransport.go:261|github.com/livekit/livekit-server/pkg/rtc.(*ParticipantImpl).getPendingTrack\n\t/workspace/pkg/rtc/participant.go:789\ngithub.com/livekit/livekit-server/pkg/rtc.(*ParticipantImpl).onDataChannel\n\t/workspace/pkg/rtc/participant.go:758\ngithub.com/pion/webrtc/v3.(*API).NewPeerConnection.func1\n\t/go/pkg/mod/github.com/pion/webrtc/v3@v3.0.29/peerconnection.go:176\ngithub.com/pion/webrtc/v3.(*SCTPTransport).onDataChannel.func1\n\t/go/pkg/mod/github.com/pion/webrtc/v3@v3.0.29/sctptransport.go:261>"}```
I wonder if this could be putting things in a bad state

so with LK, we should be adding two data tracks to facilitate sending data packets.. but that's unrelated to your problem

ah ha.. so this looks like an order of ops issue

i see, so I need to wait to get the sid until after all of the webrtc stuff?

the flow should be like this:
1. client sends `AddTrack` (with cid and etc)
2. server responds with a `TrackPublished` 

3. client then adds the track to peerconnection, then negotiate

if 3 arrives before server gets 1, it won't know how to account for the track..

(so we're looking at the same code): <https://github.com/livekit/client-sdk-unity/blob/main/Packages/com.livekit.livekitclient/Runtime/Scripts/RTCEngine.cs#L97>

step 3, I add the track to the transceiver

something else is happening then.. but it's def abnormal for server to print that error

so i'm trusting that it's not related :slightly_smiling_face: but something i'll look at later

no worries, I was confusing - I think i'll just need to get this running locally to make any progress on debugging this

possibly related to the simulcast code that doesn't remove the pending track + maybe my client id changes after the fact?

only thing i see that could keep an old sid around

doing some digging here, first time when it works
```{"level":"debug","ts":1623723106.4971914,"caller":"service/roommanager.go:368","msg":"add track request","participant":"neil","track":"23c57ef7-096f-4c9e-9cf8-5481b50d62cd"}
{"level":"debug","ts":1623723106.6973565,"caller":"rtc/participant.go:237","msg":"answering pub offer","state":"ACTIVE","participant":"neil"}
{"level":"debug","ts":1623723106.6981328,"caller":"rtc/participant.go:257","msg":"sending answer to client","participant":"neil"}
{"level":"debug","ts":1623723106.775419,"caller":"rtc/participant.go:682","msg":"mediaTrack added","participant":"neil","remoteTrack":"23c57ef7-096f-4c9e-9cf8-5481b50d62cd","rid":""}```
second time when the incorrect sid is on the track:
```{"level":"debug","ts":1623723476.5189552,"caller":"service/roommanager.go:368","msg":"add track request","participant":"neil","track":"90315c0d-ad57-4770-83d4-ff95cfb0cd47"}
{"level":"debug","ts":1623723476.6283615,"caller":"rtc/participant.go:237","msg":"answering pub offer","state":"ACTIVE","participant":"neil"}
{"level":"debug","ts":1623723476.628942,"caller":"rtc/participant.go:257","msg":"sending answer to client","participant":"neil"}```
It appears as if the mediaTrack added part doesn't happen the second time

but the negotiation process def completed

you could modify the server in <https://github.com/livekit/livekit-server/blob/master/pkg/rtc/participant.go#L237>

and print out the offer itself.. we could debug from there..

going try something else first - I'm not convinced that I'm cleaning up the original track correctly

ok, oh so another thing.. with webrtc.. you can't really "remove" a track

unpublish will sort of hide it.. but the transceiver is still around

I'm not sure you can fully. webrtc protocol limitation.

ok got it working, it was indeed a cleanup issue. I had to a) remove the sender instead of stopping the tranceiver, I also had to call a track.Dispose() to cleanup the track. I guess tracks get reused in webrtc internally so there was some state hanging around

I wanted to share this library with you but wasn't sure which channel it should go in because its not "helpdesk" or "general" really::

<https://github.com/daily-co/react-native-webrtc>

looks like daily forked the official react native webrtc library and improved it quite a bit

is this with one of the existing client SDKs? or are you creating a new SDK?

ah ok, so the first thing to check, is if the server has received the track

if you turn on debugging logs, it should print something like:
```rtc/participant.go:699	mediaTrack added	{"participant": "me", "remoteTrack": "109dde0e-f0bf-45ab-a8f5-9c5903f0479f", "rid": "h"}```

No I don't have that, I only have the add track request message

ok, then it means the track isn't published correctly

what values are you sending as cid? it should be a unique value for each publication

and after you addTrack to the peer connection, it will need to trigger a renegotiation.

Yes, I'm generating a random cid and I'm using AddTransceiver and not AddTrack

add transceiver should be ok too.. just to make sure the negotiation is completed on the subscriber PC connection afterwards

Yes, the negotiation is called, i'm probably doing something wrong ...

Oh I just found the error, hardware encoder wasn’t working so I used the software encoder in the WebRTC settings of Unity. 

H264 with hardware encoder and now I’m using VP8

ah gotcha, so the h264 encoder was failing huh? interesting..

Hey! By "never used", do you mean never called?

 Not never called but we don’t have access to it ?

you should be able to set `participant.listener = yourlistener`

this may not work for your use case, but you can also optionally access `participant.isSpeaking`

what kind of network issues are you seeing?

timeout on the initial connect, ws connection happens fine, but the peer connections don't finish

so Single port mode means instead of having each participant use up a few ports, everything will be muxed through a single UDP port

interesting, what are the advantages/disadvantages to that?

it removes the limit on # of participants in room as it relates to ports that you've made available

since these ports have to be open on the firewall, it means a single port to open instead of a potentially large range

<https://docs.livekit.io/guides/deploy> has some docs around this

would you expect it to help on the initial network setup? I'm not close to the limit of ports

(unless ports are not being recycled but then it wouldn't work on my home network)

it's hard to say what the issue is.. are the port ranges fully open on the server side?

an issue could occur, for example, when the server is advertising a port, but it's actually closed on the firewall

yeah, server side I think things look normal. Port range set in the configuraton + exposed publicly

I see.. it's worth a shot.. it's hard to say if it'll fix the specific problem you are having

is it possible to configure this initial connect timeout btw? It could just be that it takes longer to negotiate at the offfice

if you have client logs, and/or chrome webrtc-internals data.. that'd be helpful.

yeah i'll see if I can get the candidates tomorrow

regardless, i would give single port mode a try.. it simplifies things a lot

ok great will do, yeah I was incorrectly thinking it would force TCP

so how would it work if one of the clients needs TURN?

if the server ports are exposed.. the only cases when it would need TURN is if firewalls block UDP traffic

see: <https://docs.livekit.io/guides/room/connect#connectivity>

<@U01UB0LHTTQ> just added #3, TURN over TLS for corporate firewalls that block non-HTTPS traffic

ok great, i'll give this a try and see if it fixes it. I've added a udp_port and a tcp_port to my config and removed the port ranges

i've also updated my client lib to the latest, it was 0.8.1 so this is an imperfect experiment :slightly_smiling_face:

so I was unable to get this to work on 0.9.4 on firefox. There is a js error:

```Uncaught (in promise) TypeError: e.sendEncodings is undefined
    addTransceiver &lt;unknown&gt; line 0 &gt; Function:3
    publishTrack &lt;unknown&gt; line 0 &gt; Function:3
    o ```
Worked on chrome

(but I need firefox becuase the android build uses firefox)

not sure if it corresponds, but the geckoview version is 82.0

ok i've dug in a little bit. For the audio, I had to specify a bitrate to get it to work.

For video, i'm unable to get it to work. I have confirmed that here: <https://github.com/livekit/client-sdk-js/blob/478381dee6efcc4abe54bdff328e3966ba3c7285/src/room/participant/LocalParticipant.ts#L97>

getSettings() returns an object with no width or height values which ultimately leads to undefined for `encodings`

note that in my setup, I'm restreaming an incoming mediastream track. Not streaming a camera

ah I see, that makes sense.. let me investigate

so the strange thing is FF 82 seems to complain when sendEncodings is set to undefined. I pushed a fix for that and tagged it 0.9.5.

ok onto the next issue :slightly_smiling_face:

So it seems like the js client on firefox is sending an H264 offer which is not supported in my GeckoView AFAIK

On the receiving end in chrome, this is the offer I get from livekit:
```{"type":"offer","sdp":"v=0\r\no=- 3666959877448244447 1625252361 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 09:FB:F5:C8:BD:4B:28:26:A7:F8:D3:B2:E9:61:25:EE:B7:C6:D9:EE:ED:F3:55:59:3F:F8:60:4E:6D:8C:6A:F7\r\na=group:BUNDLE 0\r\nm=video 9 UDP/TLS/RTP/SAVPF 126\r\nc=IN IP4 0.0.0.0\r\na=setup:actpass\r\na=mid:0\r\na=ice-ufrag:aHdypAWnBKEbRoyO\r\na=ice-pwd:gFaPMdcofZRFWlmsuOrtVGJWabsgpxZe\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:126 H264/90000\r\na=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1\r\na=rtcp-fb:126 nack \r\na=rtcp-fb:126 nack pli\r\na=rtcp-fb:126 ccm fir\r\na=rtcp-fb:126 goog-remb \r\na=rtcp-fb:126 transport-cc \r\na=ssrc:3435814857 cname:PA_N26682WLiM8x|TR_8rLgDmVpVmZ7\r\na=ssrc:3435814857 msid:PA_N26682WLiM8x|TR_8rLgDmVpVmZ7 TR_8rLgDmVpVmZ7\r\na=ssrc:3435814857 mslabel:PA_N26682WLiM8x|TR_8rLgDmVpVmZ7\r\na=ssrc:3435814857 label:TR_8rLgDmVpVmZ7\r\na=msid:PA_N26682WLiM8x|TR_8rLgDmVpVmZ7 TR_8rLgDmVpVmZ7\r\na=sendonly\r\n"}```

even when specifying the videoCodec as vp8 it's sending this

yeah, i don't think I have getCapabilities on my transceiver:

```    if (!('getCapabilities' in RTCRtpSender)) {
      return;
    }
    const cap = RTCRtpSender.getCapabilities(kind);
    if (!cap) return;```

ah I see... so.. I guess we could do something on the livekit server side

it's so weird that this was working in 0.8.1 though with my port range

have there been large changes in this area?

I don't believe so.. JS client hasn't changed much in this area

do you have `setCodecPreferences` on the transceiver?

if so.. we could try to force it to h264 regardless...

yeah so weird, I confirm that the Unity --&gt; local web view connection comes in as vp8. It's just the web view to livekit server wants h264

wait.. is this the offer that firefox sent to the server? or offer from livekit to your other client?

ohhh hrmm good point, yeah this is server to other client (currently chrome)

but I assumed the server doesn't transcode right?

no it doesn't.. but it will negotiate the capability with firefox

so firefox sends it an offer, stating the codecs it supports.. and server responds with what it accepts

the only change may have been here:
```      encodings = this.computeVideoEncodings(
        settings.width,
        settings.height,
        options,
      );```

i see, perhaps there is something failing sooner then

before computeVideoEncodings always returned an encoding.. in the later version, we don't send the encoding unless `videoEncoding` is present, and width/height are accessible

maybe FF goes to h264 unless bitrate is specified

interesing, i'll try that. For what it's worth, on the receiving end I am receiving data. Just no frames are being decoded

can you try something? remove the width and height checks here: <https://github.com/livekit/client-sdk-js/blob/main/src/room/participant/LocalParticipant.ts#L353>

and set an explicit bitrate.. see if it'll get FF to send VP8

then I'll just do this if it's all the same:
```      track.getSettings = () =&gt; {
        return { width: 1280, height: 720 }
      }```
I don't at the moment have a quick flow for using a custom livekit client

it should be in the node_modules dir.. was thinking just changing the .js to bypass that check

can you dump the offer and answer on the server for the stream published?

you can uncomment this line: <https://github.com/livekit/livekit-server/blob/master/pkg/rtc/participant.go#L248>

can I print it client side? I'm just using the provided docker image

offer:
```{
  "type": "offer",
  "sdp": "v=0\r\no=mozilla...THIS_IS_SDPARTA-82.0.3 3503123922649730818 1 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 72:E5:82:54:53:A2:BB:B8:6C:99:58:BB:E2:89:3B:33:8C:12:89:25:11:44:64:49:CA:72:4D:0D:CB:97:AE:4E\r\na=group:BUNDLE 0 1\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=application 33015 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 64.71.10.66\r\na=candidate:0 1 UDP 2122252543 172.16.31.15 33015 typ host\r\na=candidate:3 1 TCP 2105524479 172.16.31.15 9 typ host tcptype active\r\na=candidate:1 1 UDP 1686052863 64.71.10.66 33015 typ srflx raddr 172.16.31.15 rport 33015\r\na=sendrecv\r\na=end-of-candidates\r\na=ice-pwd:48515590533be6aef776105dfaed7c6d\r\na=ice-ufrag:02263ce6\r\na=mid:0\r\na=setup:actpass\r\na=sctp-port:5000\r\na=max-message-size:1073741823\r\nm=video 9 UDP/TLS/RTP/SAVPF 126 127 120 124 121 125\r\nc=IN IP4 0.0.0.0\r\na=sendonly\r\na=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:4 <http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time>\r\na=extmap:5 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:6/recvonly <http://www.webrtc.org/experiments/rtp-hdrext/playout-delay>\r\na=extmap:7 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>\r\na=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1\r\na=fmtp:127 apt=126\r\na=fmtp:120 max-fs=12288;max-fr=60\r\na=fmtp:124 apt=120\r\na=fmtp:121 max-fs=12288;max-fr=60\r\na=fmtp:125 apt=121\r\na=ice-pwd:48515590533be6aef776105dfaed7c6d\r\na=ice-ufrag:02263ce6\r\na=mid:1\r\na=msid:- {ca202c0e-2743-42b8-9aeb-31894b3f2544}\r\na=rtcp-fb:126 nack\r\na=rtcp-fb:126 nack pli\r\na=rtcp-fb:126 ccm fir\r\na=rtcp-fb:126 goog-remb\r\na=rtcp-fb:126 transport-cc\r\na=rtcp-fb:120 nack\r\na=rtcp-fb:120 nack pli\r\na=rtcp-fb:120 ccm fir\r\na=rtcp-fb:120 goog-remb\r\na=rtcp-fb:120 transport-cc\r\na=rtcp-fb:121 nack\r\na=rtcp-fb:121 nack pli\r\na=rtcp-fb:121 ccm fir\r\na=rtcp-fb:121 goog-remb\r\na=rtcp-fb:121 transport-cc\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:126 H264/90000\r\na=rtpmap:127 rtx/90000\r\na=rtpmap:120 VP8/90000\r\na=rtpmap:124 rtx/90000\r\na=rtpmap:121 VP9/90000\r\na=rtpmap:125 rtx/90000\r\na=setup:actpass\r\na=ssrc:1372949362 cname:{909d6208-63c5-44b7-900c-c875f6e0ff63}\r\n"
}```

answer:
```{
  "type": "answer",
  "sdp": "v=0\r\no=- 7685509054343551408 1625255260 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 4E:1E:E5:14:82:66:9E:5D:5F:E0:65:61:26:57:F7:62:E0:C0:88:D5:B6:8B:41:BF:6A:85:F4:C6:E8:78:CF:7F\r\na=group:BUNDLE 0 1\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 0.0.0.0\r\na=setup:active\r\na=mid:0\r\na=sendrecv\r\na=sctp-port:5000\r\na=ice-ufrag:gpuaxcWiyDoDFxxt\r\na=ice-pwd:nTxeAWEynJXIesXGAqlgcbitUvPBMTsY\r\na=candidate:256439194 1 udp 2130706431 35.165.237.43 7882 typ host\r\na=candidate:256439194 2 udp 2130706431 35.165.237.43 7882 typ host\r\na=candidate:175239721 1 udp 1694498815 35.165.237.43 58699 typ srflx raddr 0.0.0.0 rport 58699\r\na=candidate:175239721 2 udp 1694498815 35.165.237.43 58699 typ srflx raddr 0.0.0.0 rport 58699\r\na=candidate:175239721 1 udp 1694498815 35.165.237.43 53265 typ srflx raddr 0.0.0.0 rport 53265\r\na=candidate:175239721 2 udp 1694498815 35.165.237.43 53265 typ srflx raddr 0.0.0.0 rport 53265\r\na=candidate:2998633082 1 tcp 2124414975 35.165.237.43 7881 typ host tcptype passive\r\na=candidate:2998633082 2 tcp 2124414975 35.165.237.43 7881 typ host tcptype passive\r\na=end-of-candidates\r\nm=video 9 UDP/TLS/RTP/SAVPF 126 120 121\r\nc=IN IP4 0.0.0.0\r\na=setup:active\r\na=mid:1\r\na=ice-ufrag:gpuaxcWiyDoDFxxt\r\na=ice-pwd:nTxeAWEynJXIesXGAqlgcbitUvPBMTsY\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:126 H264/90000\r\na=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1\r\na=rtcp-fb:126 nack \r\na=rtcp-fb:126 nack pli\r\na=rtcp-fb:126 ccm fir\r\na=rtcp-fb:126 goog-remb \r\na=rtcp-fb:126 transport-cc \r\na=rtpmap:120 VP8/90000\r\na=fmtp:120 max-fs=12288;max-fr=60\r\na=rtcp-fb:120 nack \r\na=rtcp-fb:120 nack pli\r\na=rtcp-fb:120 ccm fir\r\na=rtcp-fb:120 goog-remb \r\na=rtcp-fb:120 transport-cc \r\na=rtpmap:121 VP9/90000\r\na=fmtp:121 max-fs=12288;max-fr=60\r\na=rtcp-fb:121 nack \r\na=rtcp-fb:121 nack pli\r\na=rtcp-fb:121 ccm fir\r\na=rtcp-fb:121 goog-remb \r\na=rtcp-fb:121 transport-cc \r\na=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:7 <http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01>\r\na=recvonly\r\n"
}```

so yeah looks like h264 is first priority :thinking_face:

it might be better to restrict this on the server.. was thinking that it could be a per instance or per room config

FWIW, we have no control over this process... since browser is the one publishing.. but if we responded in the answer that we only support VP8, browser would behave correctly

yeah a server-side setting would make sense. What should I do in the meantime? Munge the offer's sdp?

i guess I can take a closer look at what may have changed between versions to where this would have stopped working

we can probably get this added today on the server side. It's something we've talked before to ensure that different clients can speak the same protocol..

ok got it to use vp8 by disabling h264 in `about:config`

Now I get:
```ICE failed, add a TURN server and see about:webrtc for more details```
Maybe I've messed up a setting server-side?

my config:
```{"port":7880,"log_level":"debug","redis":{"address":"chef-studios-livekit-redis-production:6379"},"multi_node":true,"keys":{........},"rtc":{"udp_port":7882,"tcp_port": 7881,"use_external_ip":true}}```

ICE failure means it couldn't connect to the port

The wire_gen.go change is because we used an older version - should be ok to leave that in <https://github.com/google/wire/commit/a58291c0b81576a6abe9702e597508e3be8bc80e>

We can also lock the protobuf and twirp versions in `bootstrap` so this doesn’t happen each time they release a new version

Just pushed it in, feel free to pull &amp; move back to main branch. Let us know if you have any more questions!

Thanks, you are so fast! I tried to "git reset --hard HEAD" after running boostrap.sh and mage in livekit-server, but it would show the error above (since go.mod is reverted). Nice that commit is reproducible locally now

Does this point towards some kind of port issue?

I'm not seeing any errors in the server or client otherwise, and nothing has changed infrastructure-wise

We changed the defaults so it no longer runs in single-port mode by default, it was capping the number of participants that could join a room

Do you have the initial log (`starting Livekit server`)?

do you have your configuration / port settings? it's what <@U01UB0LHTTQ> mentioned regarding default port changes if they aren't specified in the config

Ah yes likely default port changes. Let me check the updated config

How many participants does it limit per room? Single port might work best for us still, we don't need more than ~8 max I'd imagine

each participant uses about two ports. single port is still better if your use case doesn't require hundreds of users per server

we found that eventually we run into a bottleneck that exceeds a single thread's ability to send

Still not working... Verified my config here:

<https://docs.livekit.io/guides/deploy>

Using the udp ports 50000-60000, which have firewall rules in place to allow

I'm thinking the ports might not be properly forwarded because `nmap` says `STATE: filtered`...

No wait that just means the probe was dropped before it reached the host. So not necessarily closed, just that it can't be determined

If I SSH into it and run `livekit-server ports` I get
```/ # ./livekit-server ports
TCP Ports
80 - HTTP service
7881 - ICE/TCP
UDP Ports
9000 - ICE/UDP```
Which is lacking the `50000-60000` defaults :thinking_face:

Hey Angel, could you share the configuration the server is using? (without the keys)

it *feels* like some sort of misconfiguration where the server is listening on a port that isn't open

the server logs when it first starts would be helpful too. it'll stay something like this:
```2021-07-08T15:09:43.874-0700	INFO	service/server.go:167	starting LiveKit server	{"address": ":7880", "nodeId": "ND_nMu0nVnx", "version": "0.10.4", "rtc.tcp_port": 7881, "rtc.port_range_start": 50000, "rtc.port_range_end": 60000, "prometheus_port": 6789}```

I'm messing with config more right now so if it still doesnt' work I'll post here :pray:

```{"level":"info","ts":1625775100.9957194,"caller":"service/server.go:167","msg":"starting LiveKit server","address":":80","nodeId":"ND_1FUUx1SR","version":"0.10.4","rtc.tcp_port":7881,"rtc.udp_port":9000}```

Hmm looks like it straight up isn't getting the udp ports

```livekit_config = {
    port = var.http_port
    rtc = {
      port_range_start = var.udp_port_start
      port_range_end   = var.udp_port_end
      force_tcp        = var.force_tcp
      tcp_port         = var.rtc_tcp_port
      udp_port         = var.rtc_udp_port
      use_external_ip  = true
    }
    turn = {
      enabled          = var.turn_enabled
      tcp_port         = var.turn_tcp_port
      udp_port         = var.turn_udp_port
      port_range_start = var.turn_port_start
      port_range_end   = var.turn_port_end
    }
    development = var.development
    keys        = var.api_keys
    redis = {
      address = var.redis_address
    }
  }```


ah ha.. so I bet it's still setting rtc_udp_port from the terraform vars file

if you update those values to match the ports you've opened up.. they should be ok

```variable "udp_port_start" {
  type    = number
  default = 50000
}

variable "udp_port_end" {
  type    = number
  default = 60000
}```


And they're not getting overwritten afaik

```"development": false 
"port": 7880 
"redis": 
    "address": "~~~~" 
"rtc": 
    "force_tcp": false 
    "port_range_end": 60000
    "port_range_start": 50000
    "tcp_port": 7881 
    "udp_port": 9000 
    "use_external_ip": true 
"turn": 
    "enabled": false
    "port_range_end": 14000
    "port_range_start": 12000
    "tcp_port": 3478
    "udp_port": 3479```
sans keys

Maybe something with the yaml encoding? when I echo $LIVEKIT_CONFIG it spits it out in one line, not sure if thats because of echo or because of the terraform `yamlencode()`

I wonder if I should try to json encode it instead

oh.. so you *don't* want to set udp_port. if you are trying to use multi-port mode

Oh got it, will make sure it's unset. However if that's the case... Why doesn't single port mode work at all anymore? :s

I've unset udp_port and redeploying, let's see...

I just tried udp_port case and it's still working for me :thinking_face:

image.png

You should be able to find connection info here based on your platform <https://docs.livekit.io/guides/room/connect|https://docs.livekit.io/guides/room/connect>