LiveKit Community

hey <@U02A16BN7S8>, it should be able to handle more users than that. how does your UI work btw? does it pull down all video tracks? and at which resolution?

when you say users aren't able to publish their tracks, do you get an error on the client side or server side? Or does something else happen?

For UI: We’re using client js sdk example as base and most of the presets are default

The video tracks are just not visible for the 8th user onwards

Resolution: QHD

We are not getting any error on the server side however on the client side only the participant name is visible but not the video/audio element

hey Kay, I think you are seeing a limitation of the JS SDK sample.. it's hacked up super quick and really doesn't handle more than a few participants

feel free to try the react example. (deployed at <https://example.livekit.io>)

Sure, thanks for the heads up. But was wondering if I could try to sort out this JS SDK version as well. Any pointers in that direction too would help :)

A quick question. I’m planning to use vue.js in frontend where shall I begin?

take a look at the react component. I think the main thing you'd need is translating some of these callbacks into state updates

Vue and react are pretty similar. so I'm guessing what we did in the react component will be similar to what's needed to use it inside Vue

<@U01KZ61GV5Z> just out of interest: What are the significant performance culprits in the JS SDK example, compared to the react SDK?

none that I'm aware of :slightly_smiling_face: the React SDK builds on top of the JS SDK. I think the issue here is UI of the test app, we haven't tested it with more than 4-5 people before and there's probably a layout/logic bug somewhere

<@U01KZ61GV5Z> glad to hear that, thanks. <@U02A16BN7S8> we've been working with Vue and WebRTC/media streams for quite some time now – just wanted to let you know in case you stumble upon some Vue specific issues. Chances are we've already stumbled upon them at some point. :smile:

Wow.. That’s some fillip to my emotions

<@U028SSAKLQ1> which SDK did you use for your vue application? Also, any major issues that you faced while implementation

<@U02A16BN7S8> we are currently in the process of evaluating LiveKit and will hopefully soon start the migration of our clients. I'm building the tests with Vue 3 (so far without Vuex) and the <https://github.com/livekit/client-sdk-js/|livekit/client-sdk-js> and so far that worked quite well. So far I haven't had any problems with this combo, but in the past we have noticed a wide spectrum of issues ranging from buggy reactivity behaviour of srcObject attributes to problems with the event bus system of Vue leading to browsers not recognizing user gestures as direct enough to allow auto-play of audio signals.
Right now we unfortunately don't have the resources to build and maintain a public Vue SDK on our own. But maybe if we find some other volunteers? <@U01KZ61GV5Z> do you have an idea about how many other LiveKit devs are working with Vue by any chance?

The users are not able to publish their tracks

We only see the connection without their media stream

Also Kay, just for repro purposes, how are you deploying?

yeah, that's a good idea.. we are looking at simpler deployment options. DO is on our list too.

We’re deploying on aws using nodejs. We also tried the similar setup on internal LAN

So you have a plain EC2 instance running?

And they both have the specs you mentioned?

For AWS we are using the micro instances, The specs I mentioned was when we tried it locally. Under both circumstances we saw the cap at 7-8 users

Ok for sure; sorry for all the questions.

You say sorry and I am feeling all grateful for your probing

It's possible.. but we are not aware of any known issues with it. It's currently used in the <https://example.livekit.io|example app>. Here's <https://github.com/livekit/livekit-react/blob/master/src/components/ControlsView.tsx#L122|the source> where we unpublish

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

&gt; For production deploys, we recommend using a config file. The config file can be passed in via `--config` flag, or the body of the YAML can be set with a `LIVEKIT_CONFIG` environment variable.

yes, without a config it'll use some sane defaults

quick example of making a new docker image with a baked in config:
```FROM livekit/livekit-server
COPY config.yaml /
ENTRYPOINT ["/livekit-server", "--config", "/config.yaml"]```

I run it from source but yeah I figured out you have to pass `--config`... was hoping it would automatically try to use `config.yaml` if that was available

that's the railsy way of doing things :stuck_out_tongue:

image.png

this typically happens if the IP of the server isn't detected automatically. what does the server say your IP is?
```2021-08-04T15:25:38.193-0700	INFO	livekit	service/server.go:172	starting LiveKit server	{"addr": ":7880", "nodeID": "ND_nMu0nVnx", "nodeIP": "172.20.1.126"```

<@U01KZ61GV5Z> It started working somehow?

regen'd client token... and trying to connect o my local server. Didn't see anything in Console.

Oh hey... guess what? On Iridium (Chromium-based) it works &gt;_&gt;

I'm still new to helm.

I am trying to deploy on gke again, I'm confused on helm install &lt;instance_name&gt;
Is this instance_name the name of the compute engine instance ?

I tried with random name. install goes through but helm list is empty..
I am definitely missing something here

Ok I got it figured, <@U01KZ61GV5Z> can you add this in the docs for GKE.
After cluster is created..
gcloud container clusters get-credentials &lt;cluster_name&gt; --zone &lt;zone&gt;

kubectl get --namespace &lt;namespace&gt; ingress &lt;ingress_name&gt;

This will expose the cluster public ip.

Then connect to the address directly without putting port 7880 as is in the examples

Flutter is coming very soon (this month, for sure).

p2p for small rooms is on our list, but not high priority at the moment.

Jahir, please DM me your GitHub handle and I'm happy to give you an early look

hey <@U028SSAKLQ1>, does it time out consistently? what is the network configuration like when you are running these two different clients? Are they behind a NAT in order to reach the server?

hey <@U01KZ61GV5Z>! yes, the time outs happen consistently. the clients are both on the same machine – as is the server. i'm sitting behind a NAT, but all domains resolve locally (and i've configured `rtc.node_ip` to the same local ip), so if i'm understanding the architecture correctly, this should not be an issue.

ah ok, what about the external IP of the server? is that a public IP?

No, it's local IPs all around :slightly_smiling_face:

With the tokens provided by <@U01UB0LHTTQ> :pray: I'm able to connect to <http://demo.livekit.io|demo.livekit.io> without a problem. That actually helps a lot to narrow the problem down. I suspect ICE/TURN because handlePublisherICEStateChange() is never called when connecting through the SDK. Do you have an idea about what could be different between the JS and Go implementation in this regard?

oh, so if you use local IP, then ensure that the server is advertising a local ip, not a public IP

basically the ports on the IP address need to point to lk server.

I think I'm doing that - `rtc.node_ip` is set to the local IP, and `rtc.use_external_ip` is set to `false` .

that seems right, I'm asking because your logs said `PUBLIC_IP_CENSORED`

those ICE candidates are ones that clients will attempt to connect to.

I see, let me double-check if that was actually a public IP :smile:

Sorry, that was an absolutely unnecessary redaction

See the actual logs:
```2021-08-05T21:11:02.478+0200	DEBUG	livekit	rtc/participant.go:636	sending ice candidates	{"participant": "/modbot", "pID": "PA_iZKDnQS6dwGu", "candidate": "tcp4 host 192.168.1.50:7881"}
2021-08-05T21:11:02.478+0200	DEBUG	livekit	rtc/room.go:163	participant state changed	{"state": "JOINED", "participant": "/modbot", "pID": "PA_iZKDnQS6dwGu", "oldState": "JOINING"}
2021-08-05T21:11:02.478+0200	DEBUG	livekit	rtc/participant.go:636	sending ice candidates	{"participant": "/modbot", "pID": "PA_iZKDnQS6dwGu", "candidate": "udp4 host 192.168.1.50:56352"}
2021-08-05T21:11:02.478+0200	DEBUG	livekit	rtc/participant.go:636	sending ice candidates	{"participant": "/modbot", "pID": "PA_iZKDnQS6dwGu", "candidate": "udp4 host 192.168.1.50:50845"}
2021-08-05T21:11:02.480+0200	DEBUG	livekit	rtc/participant.go:636	sending ice candidates	{"participant": "/modbot", "pID": "PA_iZKDnQS6dwGu", "candidate": "udp4 host 192.168.1.50:54200"}```
192.168.1.50 is the correct local IP.

hah ok.. that makes sense... this is very strange that they cannot connect on the same network...

you might have to add this in the Go SDK.. but it'd be good to see what ICE candidates it's sending for itself..

I assume you are using the Go side without docker or any other NAT right?

Yes, I'm running the Go client right next to the Go server (as in, on the same machine, listening on the same interface etc. – no VMs, no containers)

Sorry, what did you mean by "you might have to add this in the Go SDK"?

sorry, I meant that Go SDK isn't logging when it sends ICE candidates to the server. it'll help if you can add some logs on ur end: <https://github.com/livekit/livekit-server/blob/master/pkg/rtc/participant.go#L348>

Is this helpful?
```2021-08-05T21:45:18.366+0200	DEBUG	livekit	rtc/participant.go:643	sending ice candidates	{"participant": "/modbot", "pID": "PA_a5Svktw4kq9N", "candidate": "udp4 host 192.168.1.50:58919"}
2021-08-05T21:45:18.366+0200	DEBUG	livekit	rtc/participant.go:350	adding ICE candidate	{"Candidate": "candidate:2740367574 1 udp 2130706431 169.254.93.26 62759 typ host", "SDPMid": "", "SDPMLineIndex": 0, "UsernameFragment": null, "target": "PUBLISHER"}
2021-08-05T21:45:18.366+0200	DEBUG	livekit	rtc/room.go:163	participant state changed	{"state": "JOINED", "participant": "/modbot", "pID": "PA_a5Svktw4kq9N", "oldState": "JOINING"}
2021-08-05T21:45:18.366+0200	DEBUG	livekit	rtc/participant.go:350	adding ICE candidate	{"Candidate": "candidate:122508724 1 udp 2130706431 192.168.1.50 58745 typ host", "SDPMid": "", "SDPMLineIndex": 0, "UsernameFragment": null, "target": "PUBLISHER"}
2021-08-05T21:45:18.366+0200	DEBUG	livekit	rtc/participant.go:643	sending ice candidates	{"participant": "/modbot", "pID": "PA_a5Svktw4kq9N", "candidate": "tcp4 host 192.168.1.50:7881"}
2021-08-05T21:45:18.366+0200	DEBUG	livekit	rtc/participant.go:643	sending ice candidates	{"participant": "/modbot", "pID": "PA_a5Svktw4kq9N", "candidate": "udp4 host 192.168.1.50:53591"}
2021-08-05T21:45:18.368+0200	DEBUG	livekit	rtc/participant.go:350	adding ICE candidate	{"Candidate": "candidate:1042019699 1 udp 1694498815 192.168.1.50 50139 typ srflx raddr 0.0.0.0 rport 50139", "SDPMid": "", "SDPMLineIndex": 0, "UsernameFragment": null, "target": "PUBLISHER"}
2021-08-05T21:45:18.368+0200	DEBUG	livekit	rtc/participant.go:350	adding ICE candidate	{"Candidate": "candidate:2841339015 1 udp 16777215 192.168.1.50 28501 typ relay raddr 0.0.0.0 rport 57649", "SDPMid": "", "SDPMLineIndex": 0, "UsernameFragment": null, "target": "PUBLISHER"}```

Hm, that's interesting. Above are the logs from the Go client joining. Below are ones from the JS client:
```2021-08-05T21:48:46.383+0200	DEBUG	livekit	rtc/participant.go:662	updating participant state	{"state": "JOINED", "participant": "luis", "pID": "PA_vgznCRUGQcVd"}
2021-08-05T21:48:46.383+0200	DEBUG	livekit	rtc/participant.go:350	adding ICE candidate	{"Candidate": "candidate:613596702 1 udp 2122260223 169.254.93.26 49707 typ host generation 0 ufrag /J9A network-id 2", "SDPMid": "0", "SDPMLineIndex": 0, "UsernameFragment": null, "target": "PUBLISHER"}
2021-08-05T21:48:46.383+0200	DEBUG	livekit	rtc/participant.go:643	sending ice candidates	{"participant": "luis", "pID": "PA_vgznCRUGQcVd", "candidate": "udp4 host 192.168.1.50:58286"}
2021-08-05T21:48:46.383+0200	DEBUG	livekit	rtc/participant.go:350	adding ICE candidate	{"Candidate": "candidate:109713448 1 udp 2122194687 192.168.1.50 63946 typ host generation 0 ufrag /J9A network-id 1 network-cost 10", "SDPMid": "0", "SDPMLineIndex": 0, "UsernameFragment": null, "target": "PUBLISHER"}
2021-08-05T21:48:46.383+0200	DEBUG	livekit	rtc/room.go:163	participant state changed	{"state": "JOINED", "participant": "luis", "pID": "PA_vgznCRUGQcVd", "oldState": "JOINING"}
2021-08-05T21:48:46.384+0200	DEBUG	livekit	rtc/participant.go:643	sending ice candidates	{"participant": "luis", "pID": "PA_vgznCRUGQcVd", "candidate": "tcp4 host 192.168.1.50:7881"}
2021-08-05T21:48:46.384+0200	DEBUG	livekit	rtc/participant.go:643	sending ice candidates	{"participant": "luis", "pID": "PA_vgznCRUGQcVd", "candidate": "udp4 host 192.168.1.50:53271"}
2021-08-05T21:48:46.387+0200	DEBUG	livekit	rtc/participant.go:662	updating participant state	{"state": "ACTIVE", "participant": "luis", "pID": "PA_vgznCRUGQcVd"}
2021-08-05T21:48:46.387+0200	DEBUG	livekit	rtc/room.go:163	participant state changed	{"state": "ACTIVE", "participant": "luis", "pID": "PA_vgznCRUGQcVd", "oldState": "JOINED"}
2021-08-05T21:48:46.543+0200	DEBUG	livekit	service/roommanager.go:402	add track request	{"participant": "luis", "pID": "PA_vgznCRUGQcVd", "track": "8d973a78-e142-4134-8266-1a44541514ae"}
2021-08-05T21:48:46.543+0200	DEBUG	livekit	service/roommanager.go:402	add track request	{"participant": "luis", "pID": "PA_vgznCRUGQcVd", "track": "80089b4b-4348-4c2f-9673-c4ca5bdf99d0"}
2021-08-05T21:48:46.559+0200	DEBUG	livekit	rtc/participant.go:250	answering pub offer	{"state": "ACTIVE", "participant": "luis", "pID": "PA_vgznCRUGQcVd"}
2021-08-05T21:48:46.559+0200	DEBUG	livekit	rtc/participant.go:270	sending answer to client	{"participant": "luis", "pID": "PA_vgznCRUGQcVd"}
2021-08-05T21:48:46.560+0200	DEBUG	livekit	rtc/participant.go:350	adding ICE candidate	{"Candidate": "candidate:613596702 1 udp 2122260223 169.254.93.26 55894 typ host generation 0 ufrag /J9A network-id 2", "SDPMid": "1", "SDPMLineIndex": 1, "UsernameFragment": null, "target": "PUBLISHER"}
2021-08-05T21:48:46.560+0200	DEBUG	livekit	rtc/participant.go:350	adding ICE candidate	{"Candidate": "candidate:109713448 1 udp 2122194687 192.168.1.50 62247 typ host generation 0 ufrag /J9A network-id 1 network-cost 10", "SDPMid": "1", "SDPMLineIndex": 1, "UsernameFragment": null, "target": "PUBLISHER"}
2021-08-05T21:48:46.572+0200	DEBUG	livekit	rtc/participant.go:250	answering pub offer	{"state": "ACTIVE", "participant": "luis", "pID": "PA_vgznCRUGQcVd"}
2021-08-05T21:48:46.575+0200	DEBUG	livekit	rtc/participant.go:270	sending answer to client	{"participant": "luis", "pID": "PA_vgznCRUGQcVd"}
2021-08-05T21:48:46.576+0200	DEBUG	livekit	rtc/participant.go:350	adding ICE candidate	{"Candidate": "candidate:613596702 1 udp 2122260223 169.254.93.26 57427 typ host generation 0 ufrag /J9A network-id 2", "SDPMid": "2", "SDPMLineIndex": 2, "UsernameFragment": null, "target": "PUBLISHER"}
2021-08-05T21:48:46.576+0200	DEBUG	livekit	rtc/participant.go:350	adding ICE candidate	{"Candidate": "candidate:109713448 1 udp 2122194687 192.168.1.50 55698 typ host generation 0 ufrag /J9A network-id 1 network-cost 10", "SDPMid": "2", "SDPMLineIndex": 2, "UsernameFragment": null, "target": "PUBLISHER"}
2021-08-05T21:48:46.585+0200	DEBUG	livekit	rtc/participant.go:716	mediaTrack added	{"participant": "luis", "pID": "PA_vgznCRUGQcVd", "track": "8d973a78-e142-4134-8266-1a44541514ae", "rid": ""}
2021-08-05T21:48:46.585+0200	DEBUG	livekit	rtc/mediatrack.go:308	NewBuffer	{"MaxBitRate": 3145728}```

yeah looks like that IP is sent in both go and chrome?

<@U01KZ61GV5Z>, you're right - I missed it in the first log. I'm sorry, it's been a long day (it's 10 PM here) and I'm starting to get inattentive.

It was all about 169.254.93.26 after all. But in a completely unexpected way. :smile:

So.. I was wondering. What _is_ 169.254.93.26?

The mac address could not be traced to a vendor. But the kext was suspicious: AppleUSBNCM.kext

so the presence of this IP is causing the issue?

So: I've unplugged my iPad that I've connected this afternoon to debug a Safari issue. en12 <tel:(169.254.93.26|(169.254.93.26>) is gone.

The Go client connects without any issues.

I'm still not quite sure why it matters..

No wonder this happened out of the blue this afternoon :smile:

I'm not sure either – and I'd really like to find out – but for now, I'm just really, really happy that you guys talked this through with me. I would have lost my mind a few hours ago without you! :heart:

no worries at all! thanks for reporting this, we'll dig into it to see if we could prevent it from happening

<@U01KZ61GV5Z> maybe this will be helpful to know: I was able to recreate this behaviour by connecting to a ZeroTier network – which LiveKit then started to broadcast as an ICE candidate, too. This is a Pion issue, right?

oh, thanks for the heads up. does this happen if you run livekit-server with an explicit `--node-ip` ? I'll file an issue for it.. it's possible this is Pion

I'm running it with an explicit IP in config.yaml (`rtc.node_ip`). That's the same config as the `--node-ip` flag, right?

yup, that should be the same.. ok, good to know that also doesn't work

Ok, thanks. Please let me know if I can do anything to help.

I'm guessing you would have to instrument the real time messaging to work in tandem with the video chat, but they'd technically be two separate feeds (just side by side)

hey Hiroshi, there is an API for <https://docs.livekit.io/guides/room/data#data-message-from-participants|clients to broadcast or send one on one>, but it's not available on RoomService yet. With Go SDK, this is possible.

It would actually be great to have this API on RoomService.

if you are interested in contributing :slightly_smiling_face:

I never wrote go but I looked at the code and code of ListParticipants and writeMessage might be useful.. :thinking_face:. Whats the difference/benefit of message over RTC Data channel or WebSocket ? :thinking_face: I don't know about RTC much :sweat_smile:

good question, there are a few differences:
1. data can be sent via UDP, gives user more flexibility over reliability options (livekit supports lossy delivery too, which makes sense for time sensitive data)
2. broadcast APIs are in place with all of our SDKs, any client can receive arbitrary data broadcasted via this way. now it's possible to do this with websockets as well, but it'll have to be added to all the clients
3. RTC is more performant since it makes the minimal hops before data is broadcasted to other participants (client -&gt; SFU node -&gt; other clients) 

Implementing with Data channel (with option of lossy/reliable) makes a lot sense. I might try implementing it within a few weeks (study go :sweat_smile:) and If I can come up with something useful I will let you know, never wrote go tho :joy:

heh, Go's awesome. lmk if you end up playing with it. It'll start with adding it to the protocol package, then implementing the API.

found the first error. I should only use <http://localhost:7880> instead of <http://localhost:7880/twirp>. But I still get the following error message back:

When I use the Node SDK I dont get any error.

<@U028HADVD5K> are there any options when creating the client? I think it has the option of using either protobuf or json encoding for the request/responses

<https://twitchtv.github.io/twirp/docs/proto_and_json.html>

Just created the files new and now its working. I have no idea where the error came from. For sure a mistake on my part.
But whatever its working now :wink:

thanks for the advice. I am already staying in contact with ogabay

I'm sorry I've been lagging on this guys. I really am.

hey Kevin, for now you should also set `jti` to be identity.

I had used that field initially but realized I used the wrong field :face_palm:

we'll be moving to `sub` eventually, so for now set both fields so that folks can migrate to newer server versions that support sub

Is there maybe also another name for the "canPublish" and "canSubscribe"? If I set these permissions on false a participant is still allowed to subscribe and publish tracks.

btw: the hidden was only used for evaluation ^^

ah yes, I think the server does not distinguish between not set, versus false.. I'll file an issue.

hey Ted, do you know if the user is behind a corporate firewall or VPN? TURN is only needed if UDP is blocked by the firewall.

You can verify if TURN is used by forcing it through relays. The simplest way to do that is to run the JS sample locally, and modify <https://github.com/livekit/client-sdk-js/blob/main/src/livekit.ts#L52|this line> to:
```const config: RTCConfiguration = {
  iceTransportPolicy: 'relay'
}```

that'll require the use of TURN servers in order to connect

we are working on a JS tester that you can use to validate the connectivity of the server. stay tuned.

Thanks for the tip on `iceTransportPolicy` . in my case the issue turned out to be EC2 security group configuration, but i'll definitely need ways of testing TURN traffic in the future so this is super helpful. I'm excited about the JS testing tool

this option is now available in the JS sample app.