LiveKit Community

Hey <@U04HZ52BXFD>, first off, for transparency, I deleted your message asking for a status update on this thread. The core team provides free support to the community and often times (i.e. weekdays), we’re quite busy working to make LiveKit better for everyone. Many of us try to catch up on community messages in the early mornings, evenings and weekends. If your questions go unanswered for some time, rest assured, we want to help you, but we just need a bit more time to get around to it. It’s possible that we miss  things, and if you think we may have (i.e. it’s been over a week without a response), a gentle bump in the original thread works just as well. Thanks so much for your patience and understanding. :pray::skin-tone-4:  

cc <@U02LTG3D3K8> for (4) and (6)
cc <@U02EU2ZPTQU> for (1), (2), and (3)

Oh I thought the message may have been lost since I saw reply on others but not mine, so I just thought I added something make sure it wasn't lost. Sorry, not really sure how slack notification works since im new to slack.

Ok thanks, I will keep this in mind :+1:

for (5), the short answer is *yes*, <@U04HZ52BXFD>. With LiveKit Cloud, we meter all upstream and downstream data (i.e. bytes) transmissions. So any audio/video tracks that are published and/or subscribed, and all data messages that are sent/received. This includes transmissions associated with Ingress and Egress. Every month, we calculate the max of your upstream and downstream usage. If the resulting max usage is over the free monthly threshold (currently set to 50GB/month), you are charged for the difference at the per-GB rate (for current rates, see <https://livekit.io/pricing|pricing>).

1. you can check for `adaptiveStream` on the remote video tracks’ `isAdaptiveStream` getter. for `dynacast` there’s currently nothing exposed to verify the status of a room. for `simulcast` I think you had the correct approach in the previous thread already with `isSimulcast`
2. have you tried `remoteTrack.dimensions` ?
3. yeah, generally the resolution of the acquired camera track will be used as the highest quality layer (and the only one in case simulcast is turned off). you can have a look at the <https://docs.livekit.io/client-sdk-js/interfaces/TrackPublishOptions.html|publish options> to customize the simulcast layers, specifically `videoSimulcastLayers` and `screenShareSimulcastLayers`

1. I will play around with it again thanks.
2. Both `RemoteTrack` and `RemoteVideoTrack` does not have property `dimensions` :confused: (I am using `"livekit-client": "^1.6.2"`)

(4) yes, all server function/api’s count towards the allocated API rate limit. These are currently set at 1K requests per minute, which can be raised based on individual requests
(5) This is dashboard issue, and not a backend bug. When the browser is refreshed, this leads to the participant reconnecting, and publishing the tracks again(Same identity, but different sessions). That is why you see bump in published track counts when you refresh the browser every time. We are working on handling this better where a participant on rejoin/republishing  so that it does not lead to double counting. This should be rolled out soon :slightly_smiling_face:

2. sorry, should have clarified, `dimensions` exists on `TrackPublication` and `RemoteTrackPublication`

image.png

that is correct. we talk about this in <https://docs.livekit.io/oss/deployment/kubernetes/|our docs>.

```LiveKit pods requires direct access to the network with host networking. This means that the rtc.udp/tcp ports that are open on those nodes are directly handled by LiveKit server. With that direct requirement of specific ports, it means we'll be limited to one LiveKit pod per node. It's possible to run other workload on those nodes.```

Hello <@U04FCB3GF5F>, I think the code you're showing shouldn't have any impact on the audio track. It should only mute/disable the video track and leave the audio track untouched. This said, I've never tried this in react-native.

unfortunately it does, as referenced in the documentation above `If a track has already published, it'll mute or unmute the track.`

I think that's just a terminology difference. there we are using `mute` to mean `disable` .

the commands that you are running should not disable the mic.

it doesn't on react apps but it does on react-native apps, I even tried the `unPublishTrack()`  method on the video track only and it still mutes the mic, tried logging  `isMicrophoneEnabled` and it's always true even after the toggling the video off, but the user on the other end doesn't hear anything when the video is disabled

I have a feeling that, this is probably a bug.

I'm rather curious are you using `setMicrophoneEnabled()`  anywhere in your code? I'd be curious to know if this gets hit.

yes, I'm using it when I initially connect to a room.

```  // Connect to room.
  useEffect(() =&gt; {
    let connect = async () =&gt; {
      try {
        // If you wish to configure audio, uncomment the following:
        await AudioSession.configureAudio({
          android: {
            preferredOutputList: ["speaker"],
          },
          ios: {
            defaultOutput: "speaker",
          },
        });
        await AudioSession.startAudioSession();
        await room.connect(roomUrl, token);
        await room.localParticipant.setCameraEnabled(true);
        await room.localParticipant.setMicrophoneEnabled(true);
        console.log("connected to ", roomUrl, " ", token);
        setIsConnected(true);
      } catch (e) {
        console.log("ROOM ERROR: ", e);
      }
    };

    connect();
    return () =&gt; {
      room.disconnect();
      AudioSession.stopAudioSession();
    };
  }, [roomUrl, token, room]);```

thanks for your report, we'll investigate. which version of RN sdk are you using?

I'm getting the package directly from githup as it's still not released I think.
`"livekit-react-native": "<https://github.com/livekit/client-sdk-react-native>"`

and my react-native version is `0.70.5`

I've tested with ios, but I will build for both android and ios

hmm, tested on both android and ios, but I’m not able to repro this

could you clone our repo and try out the example app to see if this still happens for you?

We did publish it! give <https://www.npmjs.com/package/@livekit/react-native|this version> a try

Hey <@U0411KFD5NX>, just as a friendly suggestion, for code changes, I would suggest you to provide more details as to why this code should/could be removed. If you could explain a bit more your train of thoughts so everyone can understand clearly the suggestion and be able to provide valuable feedback. :blush: Just my 2 cents.

I think ( if i remember) hosPort was enabled to keep the performance to optimal in network communication ( by having direct pod - port mapping with woker node port) outside world in contrast  having another k8s network hop ( internal k8s network routing via ingress or ClusterIP setup ).

Could you explain what you mean by only want to play? In order to test ingress, you'll need to publish your rtmp stream so in your room you can see the particpant.

I use <https://example.livekit.io/> to test ingress. I have publish a rtmp stream to ingress. Using <https://example.livekit.io/>, the browser will be an user in the room. But I only want to see the rtmp stream. There will be 2 users in the room. I only want to see rtmp ingress user.

In the example, yes there will be 2 user, but if your own use case requires you to only see 1 user, you don't need every user to publish. Users join a room and only be allowed to subscribe to a stream and watch.

This is app specific configuration / development. The example is broad to show the potential of LiveKit with most features in place. Another way to not have your participant being able to publish, is to set `canPublish: false` in your token creation. For extra details, feel free to look up the Video Grant in the docs: <https://docs.livekit.io/concepts/authentication/#video-grant>

Thanks. <https://docs.livekit.io/oss/dev-tools/livekit-cli/> is 404 by the way.

I see a grant param here. Are there some examples for this param?

<@U0411KFD5NX> please give our docs site a read. We try our best to document things so it's clear to folks :slightly_smiling_face:

I have read the docs. And I cannot find the docs for livekit cli,  this link is 404 <https://docs.livekit.io/oss/dev-tools/livekit-cli/>

<https://docs.livekit.io/concepts/authentication/#video-grant>

We did not have a good experience trying to use ffmpeg - error handling especially was quite brittle. May I ask, why do you want to use ffmpeg rather than gstreamer?

:laughing:because my company do a lot of  ffmpeg works.

Yeah, so… the honest answer is: we tried ffmpeg, we couldn’t make it work, so we gave up and used gstreamer instead. If you manage to make ffmpeg work reliably, maybe you can tell us how to do it! :sweat_smile:

Ingress got a lot of  reset logs here. Any body know why?

this is my compose file
```version: "3.8"
services:
  # redis:
  #     image: redis:latest
  #     ports:
  #     - target: 6379
  #       host_ip: host.docker.internal
  #       published: 6379
  #       protocol: tcp
  #       mode: host
  ingress:
    build: 
      context : ingress
    #image: livekit/ingress:latest
    environment:
      INGRESS_CONFIG_BODY : |
            redis:
              address: host.docker.internal:6379
              db: 0
            api_key: devkey
            api_secret: secret
            ws_url: <ws://localhost:7880>
            log_level: debug
            rtmp_port: 1935
            http_relay_port: 9090
            cpu_cost:
              rtmp_cpu_cost: 2.0
            
    ports:
    - target: 1935
      host_ip: 127.0.0.1
      # host_ip: 172.20.0.3

      published: 1935
      protocol: tcp

  backend:
    build: 
      context: livekit
    environment:
      LIVEKIT_CONFIG: |
          port: 7880
          log_level: debug
          redis:
            address: host.docker.internal:6379
            db: 0
          rtc:
            tcp_port: 7881
            port_range_start: 50000
            port_range_end: 60000
            use_external_ip: false
            node_ip: 127.0.0.1
            udp_port: 7882
          keys:
            devkey: secret
          turn:
            enabled: false
          bind_addresses: [0.0.0.0]
          ingress:
              rtmp_base_url: "<rtmp://localhost:1935>"
          development: true
    ports:
    - target: 7880
      host_ip: 127.0.0.1
      # host_ip: 172.20.0.2
      published: 7880
      protocol: tcp
      mode: host


  ```

my first thoughts are that redis is not configured properly

```Could not connect to Redis at 127.0.0.1:6379: Connection refuse```
i am getting this when calling redis-cli ping from my docker dev environment

````docker-container-ingress-1  | 2023-01-18T14:57:41.209Z  INFO    ingress redis/redis.go:82       connecting to redis     {"nodeID": "NE_dymARM2JEywc", "simple": true, "addr": "host.docker.internal:6379"}
docker-container-ingress-1  | 2023-01-18T14:57:41.227Z  INFO    ingress utils/cpu_linux.go:60   failed reading cgroup specific cpu stats, falling back to system wide implementation    {"nodeID": "NE_dymARM2JEywc"}
docker-container-ingress-1  | 2023-01-18T14:57:41.228Z  INFO    ingress stats/monitor.go:120    available CPU cores: 20 max cost: 2.000000      {"nodeID": "NE_dymARM2JEywc"}
docker-container-backend-1  | 2023-01-18T14:57:41.362Z  INFO    livekit redis/redis.go:82       connecting to redis     {"simple": true, "addr": "host.docker.internal:6379"}
docker-container-backend-1  | 2023-01-18T14:57:41.413Z  DEBUG   livekit routing/redisrouter.go:413      starting redisWorker    {"nodeID": "ND_7eGy8cTP"}
docker-container-backend-1  | 2023-01-18T14:57:41.417Z  INFO    livekit service/server.go:209   starting LiveKit server {"portHttp": 7880, "nodeID": "ND_7eGy8cTP", "nodeIP": "127.0.0.1", "version": "1.3.3", "bindAddresses": ["0.0.0.0"], "rtc.portTCP": 7881, "rtc.portUDP": 7882}
docker-container-backend-1  | 2023-01-18T14:58:50.964Z  INFO    livekit service/twirp.go:120    API Ingress.ListIngress {"service": "Ingress", "method": "ListIngress", "room": "", "duration": "6.39714ms", "status": "200"}
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Change state: From = &lt;Unknown&gt;, To = NotConnected(Server)" state="NotConnected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Handle SetChunkSize: Msg = &amp;message.SetChunkSize{ChunkSize:0x1000}" state="NotConnected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg=Connect state="NotConnected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Set win ack size: Size = 2147483647" state="NotConnected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Set peer bandwidth: Size = 786432, Limit = 0" state="NotConnected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Stream Begin: ID = 0" state="NotConnected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Connect: ResponseBody = &amp;message.NetConnectionConnectResult{Properties:message.NetConnectionConnectResultProperties{FMSVer:\"GO-RTMP/0,0,0,0\", Capabilities:31, Mode:1}, Information:message.NetConnectionConnectResultInformation{Level:\"status\", Code:\"NetConnection.Connect.Success\", Description:\"Connection succeeded.\", Data:amf0.ECMAArray{\"type\":\"go-rtmp\", \"version\":\"master\"}}}" state="NotConnected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg=Connected state="NotConnected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Change state: From = NotConnected(Server), To = Connected(Server)" state="Connected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Release stream...: StreamName = S9SndCXWRwYz" state="Connected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="FCPublish stream...: StreamName = S9SndCXWRwYz" state="Connected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Stream creating...: &amp;message.NetConnectionCreateStream{}" state="Connected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Change state: From = &lt;Unknown&gt;, To = Inactive(Server)" state="Inactive(Server)" stream_id=1
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Stream created...: NewStreamID = 1" state="Connected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Publisher is comming: &amp;message.NetStreamPublish{CommandObject:interface {}(nil), PublishingName:\"S9SndCXWRwYz\", PublishingType:\"live\"}" state="Inactive(Server)" stream_id=1
docker-container-ingress-1  | 2023-01-18T14:59:20.561Z  INFO    ingress rtmp/server.go:177      Received a new published stream {"nodeID": "NE_dymARM2JEywc", "streamKey": "S9SndCXWRwYz"}
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Publisher accepted" state="Inactive(Server)" stream_id=1
docker-container-ingress-1  | time="2023-01-18T14:59:20Z" level=info msg="Change state: From = Inactive(Server), To = Publish(Server)" state="Publish(Server)" stream_id=1
docker-container-ingress-1  | 2023-01-18T14:59:20.567Z  INFO    ingress redis/redis.go:82       connecting to redis     {"nodeID": "NE_L68vYtzKwZnD", "simple": true, "addr": "host.docker.internal:6379"}
docker-container-ingress-1  | 2023-01-18T14:59:20.866Z  ERROR   ingress service/handler_deprecated.go:116       ingress failed  {"nodeID": "NE_L68vYtzKwZnD", "error": "signal error dial error: dial tcp 127.0.0.1:7880: connect: connection refused"}
docker-container-ingress-1  | <http://github.com/livekit/ingress/pkg/service.(*HandlerV0).sendUpdate|github.com/livekit/ingress/pkg/service.(*HandlerV0).sendUpdate>
docker-container-ingress-1  |   /workspace/pkg/service/handler_deprecated.go:116
docker-container-ingress-1  | <http://github.com/livekit/ingress/pkg/service.(*HandlerV0).buildPipeline|github.com/livekit/ingress/pkg/service.(*HandlerV0).buildPipeline>
docker-container-ingress-1  |   /workspace/pkg/service/handler_deprecated.go:106
docker-container-ingress-1  | <http://github.com/livekit/ingress/pkg/service.(*HandlerV0).HandleIngress|github.com/livekit/ingress/pkg/service.(*HandlerV0).HandleIngress>
docker-container-ingress-1  |   /workspace/pkg/service/handler_deprecated.go:35
docker-container-ingress-1  | main.runHandler
docker-container-ingress-1  |   /workspace/cmd/server/main.go:238
docker-container-ingress-1  | <http://github.com/urfave/cli/v2.(*Command).Run|github.com/urfave/cli/v2.(*Command).Run>
docker-container-ingress-1  |   /root/go/pkg/mod/github.com/urfave/cli/v2@v2.23.7/command.go:271
docker-container-ingress-1  | <http://github.com/urfave/cli/v2.(*Command).Run|github.com/urfave/cli/v2.(*Command).Run>
docker-container-ingress-1  |   /root/go/pkg/mod/github.com/urfave/cli/v2@v2.23.7/command.go:264
docker-container-ingress-1  | <http://github.com/urfave/cli/v2.(*App).RunContext|github.com/urfave/cli/v2.(*App).RunContext>
docker-container-ingress-1  |   /root/go/pkg/mod/github.com/urfave/cli/v2@v2.23.7/app.go:333
docker-container-ingress-1  | <http://github.com/urfave/cli/v2.(*App).Run|github.com/urfave/cli/v2.(*App).Run>
docker-container-ingress-1  |   /root/go/pkg/mod/github.com/urfave/cli/v2@v2.23.7/app.go:310
docker-container-ingress-1  | main.main
docker-container-ingress-1  |   /workspace/cmd/server/main.go:72
docker-container-ingress-1  | runtime.main
docker-container-ingress-1  |   /usr/lib/go-1.18/src/runtime/proc.go:250
docker-container-ingress-1  | 2023-01-18T14:59:21.623Z  INFO    ingress rtmp/server.go:269      key frame found {"nodeID": "NE_dymARM2JEywc", "streamKey": "S9SndCXWRwYz"}
docker-container-backend-1  | 2023-01-18T14:59:30.440Z  INFO    livekit service/twirp.go:120    API Ingress.ListIngress {"service": "Ingress", "method": "ListIngress", "room": "", "duration": "4.337012ms", "status": "200"}
docker-container-ingress-1  | time="2023-01-18T14:59:37Z" level=info msg="FCUnpublish stream...: StreamName = S9SndCXWRwYz" state="Connected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:37Z" level=info msg="Stream deleting...: TargetStreamID = 1" state="Connected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:37Z" level=info msg="Stream deleted: TargetStreamID = 1" state="Connected(Server)" stream_id=0
docker-container-ingress-1  | time="2023-01-18T14:59:37Z" level=info msg="Server closed"
docker-container-ingress-1  | 2023-01-18T14:59:37.530Z  INFO    ingress rtmp/server.go:288      closing ingress RTMP session    {"nodeID": "NE_dymARM2JEywc", "streamKey": "S9SndCXWRwYz"}```
managed to get ingress to work, but ingress for some reason cannot connect to livekit server

The issue is with your ingress config. This needs to be an URL that is reachable from the docker instance where ingress service is running in
```ws_url: <ws://localhost:7880>```


hi <@U043WB2J79C>
it’s correct to assume that `RoomEvent.AudioPlaybackStatusChanged` is only fired when it changes.
So if playback fails initially you wouldn’t get subsequent events if it also fails on attach.
When there was a moment in between that audio playback did in fact work and for some reason it switched back to not-working you should receive events for each of those changes.
If you are interested on the failure on a track level you can attach a listener on the track with  `TrackEvent.AudioPlaybackFailed`

Hi <@U02EU2ZPTQU>, thank you for response and explanation :slightly_smiling_face:

There is no difference config of livekit-server itself between oss and cloud, I think the difference is caused by the network quality between your host server and cloud node, the cloud has a algorithm to allocate a node that has best connection quality and server load for the client

Thanks for a quick answer <@U02GP9AENTH>. Is there any way to confirm this? 

The connection on hosted oss is great over Wi-Fi (tested 3 different networks), but degrades drastically after about 10 seconds on LTE never to return to higher bandwidth. It’s looks like being throttled down for some reason. I don’t understand where the throttle comes from – 
network, browser, device, turn server or host?

<@U04E8HT0QKE> it likely has to do with how your server is configured. I would check firewall settings on the instance/hosting provider to ensure that <https://docs.livekit.io/oss/deployment/ports-firewall/|the ports> we require are opened.

<@U01KZ61GV5Z> Thanks for feedback. We’ve opened port 7882, which was closed due to use of 50000-60000, but it didn’t help.

I looked into the issue more thoroughly and noticed behaviour:
1. When connecting via LTE from iPhone the connection degrades always after 30 seconds (not about 10 as I mentioned before).
2. After that in console on iPhone appears:
```secondary PC state changed disconnected```
Client starts to reconnect. After that connection is restored, but after another 30 seconds it happens again.

During that time on iPhone I can see video from other call participants without any interruptions.

I also tried using data channel to keep the connection and it works during the “disconnection” phase.

We use LiveKit 1.3.3

The disconnected means network not stable for the rtc connection, but it will continue work until state transit to `failed`, so the video is not interrupt

By the way, the client should only reconnect when PC state transit to `failed`, is it right for iOS? <@U02MAJLGN65>

<@U02GP9AENTH> That might be true, it actually starts to reconnect after state transit is `failed`. Here is full log

<@U04E8HT0QKE> I have post you a test server and token, you can check it with your client

Hey <@U02GP9AENTH>, <@U01KZ61GV5Z>, I’ve tested this issue on 4 different devices, 3 networks (1 wi-fi, and 2 cellular networks) and 3 servers (ours, rauber’s and LiveKit Cloud).

The result is still the same: both on rauber’s and our open source server connection is being lost every 30 seconds on iOS with a cellular network. Mac &amp; Android on a cellular network aren’t affected by this problem. Connecting with LiveKit Cloud on a cellular network works just fine.

I was wondering, maybe LiveKit Cloud uses a different version of livekit-server? Is there any way to check it? Our host use 1.3.3

That's interesting.. Cloud uses the same LiveKit SFU code. However, we do enable ICELite on Cloud. That's one difference

<@U01KZ61GV5Z> Thanks for looking into this. Can ICELite be enabled on open source version? I couldn’t find much info about it.

I might also add I’ve tested the connection on 3 different iPhones (14 pro, 12, X) with iOS 16 and 15 on 3 different SIM cards (including 2 mobile service providers).

Is it possible the server somehow limits the bandwidth instead of a phone?

Yup, you can enable ICELite, it's <https://github.com/livekit/livekit/blob/master/config-sample.yaml#L52|here>

as long as you are able to connect. the quality of connection depends a lot on your hosting provider and how they are connected to various ISPs.  LiveKit Cloud runs across a number of providers that we've vetted to have performant networking and interconnects to various ISPs.

Thanks, I must have missed it in the config. We’ll give it a try and let you know how it went

<@U01KZ61GV5Z> We’ve just enabled ICELite, but it didn’t help :confused:

I compared <chrome://webrtc-internals> settings for oss and cloud, and noticed that
• Cloud uses port 3478 for UDP and 443 TCP.
• Our host (and rauber`s) use 443 for UDP and 443 for TCP
Do you think it might be the source of the problem?

hmm, that shouldn't be a major difference.. do you know how the connections have been terminated? can you enable debug on the client sdk and attach logs there?

Do you mean client JS sdk? If yes, it looks just like on the screenshot I’ve attached before <https://livekit-users.slack.com/files/U04E8HT0QKE/F04KF9DGMQW/image.png> I can post full log (as text) if needed in the morning (GMT+1 timezone).

I’m not sure I understand the question about terminating the connections. Our sys admin was monitoring literally all data packets on the host while the issue occured, but he couldn’t find anything useful

do you have timestamps for these logs? from their alone it's not visible that they are becoming disconnected.

with-timestamps.png

Yes, here is a screenshot (it’s easier to read than plaintext due to code highlight).

I’ve just sent you a PM with our host url and test tokens – maybe it will be helpful to try it on your device

<@U01KZ61GV5Z>, <@U02GP9AENTH> After many hours of testing I’ve managed to identify the cause of this problem.

*Problem:* Stream from iPhone users connected with mobile data is freezing and disconnecting every 30 seconds. Issue occurs on both Amazon EC2 with cloud-init built environment and custom host on another data center.
*Solution:* Enable TURN server and set `enable_loopback_candidate` to `true` .

Enabling ICELite was not necessary. Changing ports didn’t have any effect.

That's great! Can you check the users that solve the problem are connected through TURN server?

How can I check that? I’ve observed chrome webrtc internal logs and they show TURN urls for ICE candidates. Also the issue occurs again if I disable TURN in livekit.yaml config

You can check the ICE candidate grid of `webrtc-internals` tab, there will have the selected candidate pair information.

Yes, I can confirm the connection uses TURN udp

That means your client’s udp traffic for iPhone seems not stable, some ISP may block STUN/DTLS traffic, but that can’t explain your other device (android, pc) works well in same network:thinking_face:

<@U02MAJLGN65> Do you have similar experience for iPhone disconnected every 30 seconds?

while a user is connected to a room, the token gets refreshed automatically (in case there is a reconnect).

<https://docs.livekit.io/concepts/authentication/#token-refresh>

I see. the docs says

&gt;  Refreshed access token has an expiration of 10 minutes.
My translation is that it only gets auto refreshed once, and after 10mins, no more refresh.

But this doesn't make sense since there is no manual refresh function. So I assume after 10mins, if user connected, it continues to get auto refreshed.. infinitely?

yeah, it gets auto-refeshed as long as the user is connected, also multiple times.

you can try to use “useMemo” to prevent the refresh of the specific component inside the _participantRenderer_

_<@U04DM2NALT0> how I would use this since participantRenderer is a function witch returns a_ ReactElement? 

I used stageRenderer, but its basically the same:

```stageRenderer={(props: StageProps) =&gt; {
          return &lt;StageView {...props} params={params} /&gt;}&lt;/&gt;;
        }}```

then inside StageView you can use:
`const localParticipant = useMemo(() =&gt; room?.localParticipant, [room]);`

But yes, Livekit component has some issues with re-render multiple times

The thing is not using in my case a custom UI the unmount behavior is not obvious, or maybe is not happening but can't  confirm since I'm not sure abou this

because even if I use useMemo let’s say I render with _participantRenderer_ a component witch returns a &lt;img/&gt; tag

the unmount happends with the component witch is returned from the `participantRender` function

humm.. I didn’t have a problem with unmount, but with re-render.. the image was blinking, that was caused by the participant state change, so that solved for us. :confused:

another option was to remove the component from stageRender and render outside livekit, passing the state

the ideea is what I’m trying to achieve is having a custom design for the user cameras

an this is a big issue because this would have saved a lot of time using participantRender :disappointed:

in the GridStage component from the lib is decided what is rendered
```const ParticipantRenderer = participantRenderer ?? ParticipantView;```
so around here may be the “bug”

Hi <@U04DM2NALT0>, if you can comment on the issue and attach your logs, that'd be really helpful!

<@U04DM2NALT0> I have checked your log posted in the issue but no result.. can you change you log level to debug and try again? Also a `webrtc-internals` dump log would help this.

<@U04DM2NALT0> Sorry, I have missed the `Debug` info of your server log, there are many sessions in it, and I can’t find suspicious logs… Can you post a fresh log for the failed session, and confirm if v1.3.2 works well for you? It would help us to narrow down the which change cause the problem, thanks!

Hello <@U02GP9AENTH>, I will try downgrade and test later today :wink:

<@U04CNESF2ER> which version of the library are you using? This seems to be a pretty old bug.

We've recently published it <https://www.npmjs.com/package/@livekit/react-native|to NPM>. So give v0.3.0 a try.

I've installed "react-native-url-polyfill" and it was fixed.

the RTMP process is likely the culprit. I believe our transcode latency is &lt;100ms.

Did your team test the latency? Also cost 2s?

I change the rtmp input gop to 1s , latency is 1s ! Oh yeah.

yup, we add only &lt;100ms of latency to the Ingress pipeline!

hi <@U04L510DK5W>
a server update to the latest version will always be a good idea as a first step.
Are the other users muted in the room or is everyone speaking/unmuted?

Hi <@U02EU2ZPTQU>
Server update is in progress.
Most of the users unmuted, usually one or two are speaking at the same time. Participants with the problem can be muted/unmuted.

Is it always the same 4-5 people that have that problem or is it totally random?

The are few people who have this problem every time but sometimes random people have it too. But all of them use Safari.

Hi <@U02EU2ZPTQU> <@U01KZ61GV5Z>
I have the same problem. Users who use Safari during a meeting stop hearing part of the users. When these users re-enter the room, the problems disappear, but then the problems repeat again. How can this be fixed?

There were recent audio fixes in client-sdk-js.
Try updating as a first measure, if that doesn’t fix things post the client logs (`setLogLevel('debug')`) of affected users

we don’t support custom audio tracks on the native clients at the moment

I test with chrome network throttle, not work.

It seems uses Netlink conditioner of mac, works well?

I read the codes. But I cannot find what rtcp message or other cmd send to browser(participant) when adjusting the layer. Can anybody give a clue?

yup, we have congestion control for cases like this

<@U04K1L6103H> I'm surprised to hear that. We have great latency from most of the world today and will be adding three more data centers in the coming months.

Mumbai data center is coming online in the next month

From North america, europe, asia and india, you should expect &lt;100ms latency to the end user.

Or do we need any server configuration to access this?

But access token generation is working. So there is no issue with api key and secret key

This seems like an SSL issue, we have not seen this before.

Or are these values calculated at a certain rate according to the original quality?

Yup, you can customize the layers. see `videoSimulcastLayers`  option <https://docs.livekit.io/client/publish/#advanced-track-management|here>

<@U01KZ61GV5Z> Is the first element of the videoSimulcastLayers array low resolution and the second medium resolution? Does the videoSimulcastLayers object matter when the Simulcast value is false?

1. the ordering of layers doesn't matter. you'd just have to pass up to two additional layers to publish
2. that object does not matter when simulcast is disabled

My first thinking is that gathering all tracks on initial load at a top-level and passing that to inner components. somehow that data needs to be updated when participants connect/disconnect and I should re-render only the relevant track. I would appreciate any pointers.

hi <@U04H997FHH6>
we released this library just today as a preview, there are some examples in the repo at <https://github.com/livekit/components-js> that should help you get started.
Feel free to ask more questions if things are still unclear. We are actively working on improving the documentation for this as well.

thank you. while all examples are good for high-level use (as in developing a video conference-app), in my case (where I only need tracks to play selectively) I guess I need to use the hooks to gather the initial participant-track pairs, pass that to my app through a provider and use it on the relevant component? I am not even sure if that’s the right abstraction, just looking for ideas

yeah, that sounds about right.
In case you are going to use `autoSubscribe: false` as an option: we haven’t optimized the library for this use case yet, but would be great to know your thoughts once you explored the options.

For gathering tracks, it will depend on how you would like to filter them. The TrackLoop and TileLoop both take a `filter` argument, so you could get away with just using that, depending on how your selection works.
other than that you are right, you would use the `useTracks` loop and get the pairs that you are interested in and render them either with `ParticipantTile` or a custom UI view

Also, in what format do I get the audio. Is it wav pcm or webm opus?

I know there might be some small latency with the audio, but that's not a problem.

You should be able to do this by using two rooms:
1. publish audio from alice to "staging" room
2. connect to staging room with Go SDK, process audio streams (it's opus)
3. then publish that stream to the actual room

<@U01KZ61GV5Z> thanks for the answer. Additional Q, what if Bob needs to do the same? I need N staging rooms -  where N is the number of participants. Am I right?

Also, what about video? Is it an ok use case for the livekit, or is it hacking too much, and it might end not so well?

You do not need multiple staging rooms.. the backend instance could grab multiple/all audio streams and publish them.

Video from the user could be published to the actual room directly. What this means there will be a bit of potential sync diff between audio and video, depending on your processing time.

And how should I publish the audio from Alice to the staging room? Should I do this serverside?

I'm also not seeing any traffic to my webhook address in my LiveKit Cloud project. The webhook works fine w/ dev server and the prod URL also is working and also has error reporting + logging so I should see all traffic + possible errors.

I just tested this first time yesterday, didn't notice the missing logs until now.

looking into this, would be strange that it's not working for some hosts, but works for others.

can you please DM me your project IDs? we'll take a look on our side

Our problem was just installed feature-toggle that was switched off :man-facepalming: 

I don’t have time to test it atm but I’m confident ours was a 100% user error — sorry about the noise :) 

My problem caused by custom mime type `application/webhook+json`, now fixed

<@U03J7HTAF1C> can you share more about the mime type issue? how are you receiving the payload?

<@U01KZ61GV5Z> I don't know the details, but our backend team found errors `Unsupported media type "application/webhook+json" in request.` in the server logs. We use django python framework. Problems were solved by adding a custom mime parser.

Thank you for sharing <@U03J7HTAF1C> . We'll add this to our docs so it doesn't surprise anyone moving forward.

And this error too
`available layers changed - layer gone`
But these issues are happened when I try to publish video track with 6 users on 1 PC

Without publishing video track, there is no issue at all

```rtc.congestion_control.min_channel_capacity value```
Is this related with capacity Livekit team?

Hey Jin, I'm curious. How quickly do you expect someone to respond when you ask a question?

and how long do you think it'd be appropriate to wait before repinging the entire channel?

Sorry. I only left the question. I spent the most of times on this issue.

It was urgent for me. Livekit connection was unstable from start always.
I tried to update by myself. But it was same always.

I think there is hidden option and found the config.
But I am not sure what value would be prefer to fix this issue.

<@U04DED3V5PT> congestion is always possible in the network. What you are seeing is expected behaviour. If you are running so many clients from the same machine, congestion is not unexpected.

Server uses bandwidth estimation of downstream link and adjusts what is streamed down to fit within available capacity. You can set the min capacity config to restrict how low the estimation goes. But if that is set too high, streaming will happen even when there is congestion and that will affect audio/video quality.

Thanks <@U02CM28PB4Y>
But I didn't get the reference  how can set min capacity. Can you share the config this?
Min capacity means BPS or any other?

It is BPS. You can set it in this section - <https://github.com/livekit/livekit/blob/1ef7c46fd7704fdf040c8f87adb74572a70c5ab4/config-sample.yaml#L67>. It is not documented as it is experimental and use of it is not advised. You can try it if you want and see if it works better for your use case.

You can do it through data channel, send url or image data

I’ll let Mat comment, but I think that post may be a little outdated. Try this?

<https://docs.livekit.io/oss/deployment/vm/|https://docs.livekit.io/oss/deployment/vm/>

Yes, that Medium article is outdated and you should instead follow the link above :point_up:  from <@U01KZ0SCDKL> 

Also you mentioned using a livekit.cloud URL. If you’re using LiveKit Cloud, there’s no need to deploy your own LiveKit Server VM.

live-livekit-issue.png

I am getting this issue in the live server but working fine in localhost. how can I resolve it? <@U02BBTRGF98> <@U01KZ0SCDKL>

Browsers do not allow you to use `getUserMedia` from a non-secure page. You can get around it by:
1. running this app on <http://localhost>:&lt;port&gt;
2. hosting your app with a SSL cert

ok, I will try thanks for your help. after changing to HTTPS. I don't need to worry about livekit production setup?

Right, if you’re using LiveKit Cloud, you don’t need to run LiveKit Server as well. You just need to handle your own app :smile: 

Can you say more about `it can reconnect again and it can publish again` ? how is the participant reconnecting?

if you are connecting again, you'd need to ensure the user's token is updated to remove `canPublish`. If livekit automatically reconnects, it *should not* give that user publish permissions. we have checks against that case.

Once i mute the publisher remotely by setting `canPublish` to false - the publisher get’s muted successfully but then he/she click disconnect and connect again and it can publish again. The token is not updated in LiveKit for some reason and this is the exception it throws when this is happening(updatingParticipant)

LiveKit does not control the token.. As you were saying, when the user clicks "disconnect" and then "connect", your application is passing in a token to the `connect` function in LiveKit. That token contains publish permissions. Am I correct in understanding that?

Yes it does, but what if the user capture the old token with publish permissions and connect again with it

yes, that's what we'd recommend. your webpage should refresh its token *after* the user presses the connect button.

I did another fix thought but the interesting part from my POV is that livekit is updating the claims but is that only in runtime or…? Also what about the error when muting is it expected behaviour(i attached logs above)

LiveKit updates the claims for its internal reconnect token (should it need to resume for connectivity changes). It cannot control the token that you are going to pass into it

Got it! Thanks for your time and great work!

Hi there, trying to follow this thread.

are you saying one user is not able to see a particular screen share, but others can?

I don't believe we've seen this before reported anywhere.. Can you try to see what the bitrate is for the receiving user if/when this happens again next time?

you can use `remoteParticipant.getTrack('screen_share').currentBitrate`
docs

Are you using track permissions at all?