LiveKit Community

Currently TrackSID only changes if the participant unpublishes and republishes the track. By using the `setCameraEnabled` APIs, your Track SID would remain stable. When disabled, the tracks are actually muted instead of unpublished.

You do bring up a good point though.. I think we need to ensure even a unpublish + republish sequence would produce stable track SIDs.

<@U033W4A4H8X> That is a sign of network problem somewhere in the chain. It does not necessarily mean congestion, but it could be congestion too.

You can look at `<chrome://webrtc-internals>` to check for lost packets and NACKs.

Also, when the participant leaves, the server logs `rtp stats` which will show server side view of things.

Are there any stats from Twilio TURN?

Are all the clients running on different machines? Is it possible that a client is overloaded causing it to drop packets?

Thanks for the direction <@U02CM28PB4Y>

The worst of the 9 streams has a very low amount of packet loss/nack/pli but a relatively high value for `frames received - frames decoded`
```jitter	0.01
packetsLost	708
packetsReceived	415947
ramesReceived	337160
framesDecoded	311686
[framesReceived-framesDecoded]	25474
keyFramesDecoded	2872
pliCount	922
nackCount	1829```
• Unfortunately, Twilio has no analytics'/logs  around their turn servers.
• All the clients are on the same machine - M1 pro. I don't think the packets are dropped coz of overloading coz there are other streams running from other servers at the same time which do not show this problem. 


My hunch is it's coz of a problem directly from the source coz i do see some UDP timeouts  between the source and the peer that's publishing to livekit

The publisher side could be an issue, but the NACKs log you see would not be triggered by that. The NACKs in that log is counted when server sees a repeat (i. e. the client NACKed the sequence number once, server retransmitted the packet, but client NACKed that sequence number again). In the case of publisher itself not sending packets, server would not have the packet and it would not be able to retransmit. Client side will still NACK it, but server cannot retransmit. The log from congestion controller means that the packet was already NACKed.

Looks like client is dropping a bunch of frames, maybe due to CPU?

If you run server at debug log level, you can search for `rtp stats` in the log and check what server sees. That log line might a bit cryptic, but I can send you info on what those mean.

Here are some of the rtp stats
```2022-06-03T05:56:00.478Z	DEBUG	livekit	buffer/buffer.go:294	rtp stats	{"room": "sn4b-tajypf--6580", "roomID": "RM_ejmPP8wo6PZe", "participant": "SPOT_SFU", "pID": "PA_vGWsFuNCUFdN", "trackID": "TR_VCw8SWXHKNov7b", "layer": 0, "stats": "t: Fri Jun  3 05:21:27 UTC 2022|Fri Jun  3 05:56:00 UTC 2022|2073.17s sn: 618|144304, ep: 143687|69.31/s, p: 143687|69.31/s, l: 0|0.0/s|0.00%, b: 154203615|595044.0bps, f: 30881|14.9/s / 258|Fri Jun  3 05:55:42 UTC 2022, d: 0|0.00/s, bd: 0|0.0bps, pp: 0|0.00/s, bp: 0|0.0bps, o: 0, c: 90000, j: 169(1882.0us)|169(1882.0us), n:0|0|0|0, pli:13|Fri Jun  3 05:55:48 UTC 2022 / 0|Mon Jan  1 00:00:00 UTC 0001, fir:0|Mon Jan  1 00:00:00 UTC 0001, rtt(ms):0|0"}

2022-06-03T05:56:00.478Z	DEBUG	livekit	buffer/buffer.go:294	rtp stats	{"room": "sn4b-tajypf--6580", "roomID": "RM_ejmPP8wo6PZe", "participant": "SPOT_SFU", "pID": "PA_vGWsFuNCUFdN", "trackID": "TR_AMrRQqCcMoAEdL", "layer": 0, "stats": "t: Fri Jun  3 05:21:27 UTC 2022|Fri Jun  3 05:56:00 UTC 2022|2073.30s sn: 2029|105176, ep: 103148|49.75/s, p: 103148|49.75/s, l: 0|0.0/s|0.00%, b: 16787101|64774.4bps, f: 103148|49.8/s / 0|Mon Jan  1 00:00:00 UTC 0001, d: 0|0.00/s, bd: 0|0.0bps, pp: 0|0.00/s, bp: 0|0.0bps, o: 0, c: 48000, j: 952(19850.6us)|952(19850.6us), n:0|0|0|0, pli:0|Mon Jan  1 00:00:00 UTC 0001 / 0|Mon Jan  1 00:00:00 UTC 0001, fir:0|Mon Jan  1 00:00:00 UTC 0001, rtt(ms):0|0"}

2022-06-03T05:56:00.489Z	DEBUG	livekit	sfu/downtrack.go:632	rtp stats	{"room": "sn4b-tajypf--6576", "roomID": "RM_bgxsZqNDWGYe", "participant": "b32VHeRuiC5h8tU5YjaKt", "pID": "PA_HFZFvQq7vUtU", "trackID": "TR_VC8tSy4XJEMUaB", "stats": "t: Fri Jun  3 05:21:33 UTC 2022|Fri Jun  3 05:56:00 UTC 2022|2067.26s sn: 3963|145710, ep: 141748|68.57/s, p: 141748|68.57/s, l: 30|0.0/s|0.02%, b: 149595024|578912.6bps, f: 41064|19.9/s / 343|Fri Jun  3 05:55:50 UTC 2022, d: 2112|1.02/s, bd: 2267851|8776.3bps, pp: 0|0.00/s, bp: 0|0.0bps, o: 2112, c: 90000, j: 12282(136466.7us)|28267(314077.8us), n:2244|2112|0|1378, pli:2|Fri Jun  3 05:55:53 UTC 2022 / 23|Fri Jun  3 05:21:33 UTC 2022, fir:0|Mon Jan  1 00:00:00 UTC 0001, rtt(ms):309|352"}

2022-06-03T05:56:00.490Z	DEBUG	livekit	buffer/buffer.go:294	rtp stats	{"room": "sn4b-tajypf--6576", "roomID": "RM_bgxsZqNDWGYe", "participant": "SPOT_SFU", "pID": "PA_cZNeP9rL5Es9", "trackID": "TR_VC8tSy4XJEMUaB", "layer": 0, "stats": "t: Fri Jun  3 05:21:28 UTC 2022|Fri Jun  3 05:56:00 UTC 2022|2072.13s sn: 3621|145703, ep: 142083|68.57/s, p: 142083|68.57/s, l: 0|0.0/s|0.00%, b: 148802478|574490.9bps, f: 41177|19.9/s / 344|Fri Jun  3 05:55:50 UTC 2022, d: 0|0.00/s, bd: 0|0.0bps, pp: 0|0.00/s, bp: 0|0.0bps, o: 0, c: 90000, j: 2340(26005.1us)|2340(26005.1us), n:0|0|0|0, pli:10|Fri Jun  3 05:55:53 UTC 2022 / 0|Mon Jan  1 00:00:00 UTC 0001, fir:0|Mon Jan  1 00:00:00 UTC 0001, rtt(ms):0|0"}

2022-06-03T05:56:00.490Z	DEBUG	livekit	buffer/buffer.go:294	rtp stats	{"room": "sn4b-tajypf--6576", "roomID": "RM_bgxsZqNDWGYe", "participant": "SPOT_SFU", "pID": "PA_cZNeP9rL5Es9", "trackID": "TR_AMBJGWGCPvnpsg", "layer": 0, "stats": "t: Fri Jun  3 05:21:27 UTC 2022|Fri Jun  3 05:56:00 UTC 2022|2072.62s sn: 470|103583, ep: 103114|49.75/s, p: 103114|49.75/s, l: 0|0.0/s|0.00%, b: 17113753|66056.5bps, f: 103114|49.8/s / 0|Mon Jan  1 00:00:00 UTC 0001, d: 0|0.00/s, bd: 0|0.0bps, pp: 0|0.00/s, bp: 0|0.0bps, o: 0, c: 48000, j: 944(19683.8us)|944(19683.8us), n:0|0|0|0, pli:0|Mon Jan  1 00:00:00 UTC 0001 / 0|Mon Jan  1 00:00:00 UTC 0001, fir:0|Mon Jan  1 00:00:00 UTC 0001, rtt(ms):0|0"}```

Thank you. Logs from `buffer.go` are up stream and logs from `downtrack.go` are down stream.

You can check against the same track id. Looking at the example above, for track `TR_VC8t...`, you can see `l: 0|0.0/s|0.00%` from `buffer.go`. That is for loss. There is 0 loss up stream.

But, the corresponding stats from one of the subscribers is, looking at the most relevant bits
• `l: 30|0.0/s|0.02%` - That is 30 packets lost. These are real losses, i. e number of packets subscriber did not get at all even after retransmissions. These would require a PLI + key frame to repair.
• `n:2244|2112|0|1378` - the four numbers there are
    ◦ 2244 NACKs - not necessarily unique sequence numbers, but number of times some sequence number was NACKed
    ◦ 2112 - number of NACKs that the server processed. Server will not process every NACK as it will not ACK same sequence number if the NACKs are spaced too close
    ◦ 0 - number of NACK cache misses. Here server did not see any miss. Every NACKed sequence number was in the cache.
    ◦ 1378 - Number of repeated NACKs. Once again, these are not unique sequence number. This is a count of some sequence number NACKed more than once. This is what is causing the congestion controller to act.

This was realy helpful. Helped me identify an issue with my source upstream that had it's keyframes spaced at 6 secs instead of 2 and was causing a lot of NACKs.

unfortunately there isn't a way to avoid transcoding with composites. real time media are not always encoded in a way that's suitable for immediate archival. We also have to handle situations where one stream is muted while the other is continuing, for example.

yes, that was fixed recently. For now, deleting them from redis is ok

cool! thanks.
So I'm just waiting for the commit to be part of the next Docker image release.

<@U01UB0LHTTQ>
I've tried Egress based on the newest commit.
The "starting issue" seems to be gone, but now there are more failures 500 no response when talking to Egress via JS SDK.
Do have an idea when the next Egress Docker release is planned?

next release will be as soon as we’re sure it’s stable. The latest commit probably introduced a bit of latency before sending the response

let me know if you still get the 500 errors, I’m not seeing them on my end

yeah, you can set the <https://docs.livekit.io/client-sdk-js/interfaces/RoomOptions.html#publishDefaults|publish defaults> (including bitrate) when <https://docs.livekit.io/client-sdk-js/classes/Room.html#constructor|creating a room>

```{"event":"track_unpublished","room":@,"participant":@"sid":"xxxx","identity":"test123","track":@"sid":"xxxx","source":"MICROPHONE","mimeType":"audio/opus","mid":"0","id":"EV_RsoFnsbuuviC","createdAt":"1654536376"}```

It seems to be related to anything which represents an object type.. but decoding the json causes me an issue currently

is that the raw JSON posted? that looks rather strange.

Yeah.. Ill dig a little more see if there's anything else.

this looks really off: `"participant":@"sid":"xxxx"` where it removed a comma too?

Lets see if this is happening with the response or more on server handling the response. Thanks for letting me know that this isn't supposed to be happening. Ill keep you posted.

<@U01KZ61GV5Z>, Looks like it was a server issue. I'm now receiving the proper Json! Making progress :slightly_smiling_face:

This might probably fit on a single server. However, with 1 broadcaster it seems to me you might be building a live streaming product, not a meeting/conferencing one, and thus you don’t need webrtc. Instead, you can use RTMP-&gt;HLS which is much cheaper and built for scale. A great hosted (paid) service for that is <https://www.mux.com/live>

Yeah LiveKit is open source and the only way currently is to host it yourself.

Do I need to provide some additional config eg. firewall for turn to make it work?

Fixed, had to set up firewall and open udp 443 for my node pool on gke

hey <@U03JMD3N9L4>, LiveKit enables DTX by default, so in practice you’re really only sending audio packets when a user is speaking. When they aren’t, data usage drops to ~1-2 kbps.

<@U01KZ0SCDKL> thanks for the response. I've noticed that I can even hear my my mouse clicks, is it possible to change the threshold?

I’m not the expert on this, and perhaps <@U01KZ61GV5Z> has more thoughts, but I think to resolve something like mouse clicks, we’d need to offer proper background noise suppression. That’s not something we do today, but eventually we’d like to.

This is an open chat, you sure can :slightly_smiling_face:

If you don't supply an upload config the file will be placed at the Filepath instead, our integration tests do this with a mounted directory

Thanks <@U01UB0LHTTQ>. I'd have another question. Based on my lack of knowledge with the egress, is it one file being added only once the room is completed, or the file simply keeps growing as the room gets recorded.

Due to how ffmpeg and gstreamer work, the file will be created immediately but 0 bytes until the very end

If you're looking for something more failure-resistant, we're working on a split MP4 option that will create new files based on duration, but that isn't available yet

Yeah, I'm simply working on another LiveKit Server SDK, and I'm testing the egress stuff. Appreciate the feedback.

Running into some memory issues on the server, so I'll try debugging those out and see. Hopefully all the stream isn't being dumped into memory but Ill keep digging on this.

I believe it’s being dumped into a temporary file somewhere and then transferred at the end. Memory usage does not seem to increase over time, even with long recordings

That's good to know. I'm working on a PHP Server SDK, I'll see how well the integration works with it.

<@U01UB0LHTTQ> Do you know how much memory egress requires?

Not off the top of my head, I'll get back to you in ~45 minutes

it uses about 850MB for a room composite recording

Okay, I see. From my test, I was busting 1GB+. Ill need to keep digging into this and see. Thanks a lot <@U01UB0LHTTQ>

might use more depending on your inputs and template (my test was very basic). I would recommend 4 CPU cores and 2GB or 4GB memory, ours is deployed with 4 and 4

Perfect. All valuable information. Thanks.

Actually I just found out that I can use Xcode to monitor outbound network traffic, which is very useful.
But I'd still like to know the max bitrate that is set if possible.
I can see in `VideoParameters` that the preset for 720p 16:9 has max bitrate of `2_000_000`. So I'm assuming that's what it would be if I don't explicitly set it myself?

yeah, that would be the default bitrate for the track. I don't think there's an API to get the current transmission rate yet.

BTW. I turn on all of ports on AWS lightsail in order to test it but still not work.

Did you try with Livekit URL:

<https://goingeat.com>

?

I don't know if lightsail is going to work. I see <http://goingeat.com:7880/> does take you to an active LK install, but without TLS, browsers will not allow you to connect to it as it's insecure.

I would recommend deploying an EC2 instance instead with <https://docs.livekit.io/deploy/vm/|these instructions>

<@U03JL1FG3L4> Thank you for reminding me use the  pure URL test it. It's work.
Document using wss:// only so i always testing on it.

截圖 2022-06-10 上午11.09.51.png

<@U01KZ61GV5Z> Thank you for replying me. I did several tries yesterday. And now changed to <http://livekit.goingeat.com|livekit.goingeat.com> for testing. Seems work now.

Document using start with wss:// only so i always testing on it.

<@U01KZ61GV5Z> it would be nice if you can do that the Livekit testing page remember the LIVEKIT url with a cookie or session storage, instead of reset the input to default value. I found my self entering again and again the input for testing

I don't believe mobile OSes give applications that level of control. At least on iOS, the audio input source is handled by the system automatically (say if you connected a BT headset).

For desktop flutter, we are planning to expose a set of APIs that gives you this type of device management functionality

Hi Mukesh, what do you mean by `Once the stream is closed` ?

when I end the stream and try to start stream again it doesn't start.

set the channel topic: Question or issues with using LiveKit. please :thread: your questions and keep logs/code snippets in the thread.

image.png

I am getting zillions of this errors:

turnc ERROR: 2022/06/09 21:33:34 fail to refresh permissions: all retransmissions failed for VNmr1p93ljtUgQ53

What could cause this and how to solve it? I only see this

<https://github.com/pion/turnc/issues/10>

<https://github.com/pion/turn/issues/144>

I want to deploy LiveKit server on Kubernetes with AWS ALB ingress. In this setup, multiple nodes will be serving traffic and end user can connect to any of the nodes.

It is mentioned in the documentation that `In a multi-node setup, LiveKit can support a large number of concurrent rooms. However, there are limits to the number of participants in a room since, for now, a room must fit on a single node.`

So, If there is a very large room then how can we route all traffic of that room to only one node and ensure, that node will serve data for this particular room only?

Also, what are the parameters that defines that a room can `fit` on a single node. Is it about either memory or CPU or both?

Question 2: Can I deploy Egress Service in a private Kubernetes cluster? (<https://docs.livekit.io/deploy/egress/|Ref>)

In your load balancer, you can configure "sticky session by URL" in most load balancers. I've done this with HAProxy in the past. That will make it so every user who goes to `/room/someuniqeId` will hit the exact same node.

for 1, there are a couple of ways of handling it. The simplest is to ensure that your node availability metric has sufficient overhead to allow rooms on the instances to grow. For example with <https://github.com/livekit/livekit/blob/master/pkg/routing/selector/interfaces.go#L27|cpuload> selector, and setting limit to 40% will ensure that nodes will not be returned to participants beyond the 40% CPU utilization. Any future participants joining the same room will still be able to join.

Another path is to handle node assignments yourself in CreateRoom, if you create each room via API, you can tell the API where to put the room.

For 2. I believe folks have gotten it to work on a private kubernetes cluster, as long as it could connect to the same Redis instance for message exchange.

livekit server must still run on a public cluster.

<@U02BD5MV5NX> Yes, I was also thinking the same. But just wanted to know if this is natively supported in livekit-server. Thanks :slightly_smiling_face:

<@U01KZ61GV5Z> Thank you for the response. Actually, most of our rooms will have participants less than 50 but at same time 1 - 2 rooms can have greater than 1000. Due to which we don’t want those two large rooms to be created on same node. That’s why I think that `cpuload`  selector will be a good choice for ~50 participants rooms in our case.

Passing a `nodeId` while creating room looks right solution to our problem.

For 2, I’ll keep this in mind and try this approach.

----

Just want to clarify about another approach, `Can we run TURN server in public cluster and keep livekit-server in private cluster?` and ensure that TURN server has access to private cluster to relay the packets.
I am not sure about internal implementation of livekit-server but in-general my understanding is, for WebRTC connection packets (ICE etc.) we need public TURN server and if we can relay data from TURN to a SFU then all should work fine and that SFU can be in private cluster as well.

I'm not sure if I fully understand the need here.. Have you looked into <https://github.com/livekit/livekit-react/blob/master/packages/core/src/hooks/useRoom.ts#L26|useRoom> hook? That should give you an up-to-date view of all of the participants in the room

In my particular case, I want to react to changes in the RoomMetadata.
For that I do it in `roomState.connect` after `ConnectionState.Connected`:

`room.on(RoomEvent.RoomMetadataChanged, (metadata) =&gt; {...`
In this callback I'd like to access some state from the surrounding React component to make some comparisons. It's not about participants in my case.
But State/Ref doesn't reflect updates in this callback. How to avoid a stale closure here?

The only way I was able to access new state was in something like:
`setMyState(newState =&gt; .....)` 

There is no limit to the number of Rooms each instance of the SDK can connect to. You could create multiple `Room` objects from lksdk and connect to different rooms at the same time

the same is true for client SDKs btw :slightly_smiling_face: we use it in tests to simulate multiple participants interacting with one another

yeah that’s cool. for some reason i assumed all clients could only make one connection. perhaps due to my superficial understanding of what ports and sockets actually are :slightly_smiling_face:

relatedly…

with code like this: `room.Callback.OnTrackSubscribed = trackSubscribed`

how do i tell the callback which room it’s dealing with?

you could set up your own struct instance to hold the room. i.e.:
```type MyCallback struct {
    room *lksdk.Room
}

func (c *MyCallback) OnTrackPublished(...) {
}```

are you running the latest server and egress service?

updated everything and getting the same error. is there a way to get any more detail? not sure which service is even generating the error

Hey Mark, can you list which versions you are running now? We haven't seen this reported anywhere.. and really sounds like mixing a pre-1.0 version with a 1.0 version..
Versions for:
• LiveKit server
• SDK used to make the request
• Egress

Ok here's what I got…

1. In the go.mod of my server client code…
       <http://github.com/livekit/protocol|github.com/livekit/protocol> v0.13.4
        <http://github.com/livekit/server-sdk-go|github.com/livekit/server-sdk-go> v0.10.3
        

2. Docker images for egress (not sure how to find version?)

REPOSITORY                 TAG       IMAGE ID       CREATED        SIZE
livekit/egress             latest    768872c70bf5   2 weeks ago    1.14GB
livekit/egress             &lt;none&gt;    fbf8619aec13   4 weeks ago    1.13GB



3. Latest commit of the server code…


        Author: David Zhao &lt;<mailto:dz@livekit.io|dz@livekit.io>&gt;
Date:   Thu Jul 7 23:35:26 <tel:2022 -0700|2022 -0700>

    v1.1.1

if you are running the docker image directly, it'd be a good idea to do a `docker pull &lt;image&gt;`

as long as the server is after 1.0, we have not changed egress protocol message since then..

I did a pull recently. Will check everything again

```	request := &amp;livekit.TrackCompositeEgressRequest{
		RoomName:     roomName,
		AudioTrackId: audioTrackID,
		VideoTrackId: videoTrackID,

		Output: &amp;livekit.TrackCompositeEgressRequest_Segments{
			Segments: &amp;livekit.SegmentedFileOutput{
				FilenamePrefix: "egress-test-",
				Output: &amp;livekit.SegmentedFileOutput_S3{
					S3: &amp;livekit.S3Upload{
						Endpoint:  "<http://ams3.digitaloceanspaces.com|ams3.digitaloceanspaces.com>",
						AccessKey: "*",
						Secret:    "*",
						Bucket:    "*",
						Region:    "ams3",
					},
				},
			},
		},
	}

	info, err := egressClient.StartTrackCompositeEgress(ctx, request)
	if err != nil {
		log.Print(err)
	}
	log.Print(info)```

hey i’m starting to debug this but it seems like it will be really difficult. any hints?

looks like the response from the server is just:

[]uint8 len: 2, cap: 512, [79,75]

string():
“OK”

[0]:
79 = 0x4f

[1]:
75 = 0x4b

server returns 200 so that's good… but I don't know yet what the server code path is 

oh man, I think that's not the right endpoint. which URL is your client accessing? `OK` is returned as the default text from `/` , which also includes unknown paths.

not sure why i wrote that - i guess i was used to writing it

ok so what URL should i initialize the egressClient with?

in the docs i see: “<https://my-livekit-host>”. i’m running local, so do i need a port or anyhting?

whereever you are hosting your livekit server. if you are running on standard HTTPS, then no port is needed

yeah sorry that sounded like a stupid question

it’s local, so i’m gonna try 80 and 7880 - not sure if 7880 is ws only

ok back to square one:
localhost:7880 has same invalid wire-format data

sorry this is making me feel very incompetent

80 gives me: twirp error bad_route: Error from intermediary with HTTP status code 404 “Not Found” (but i wouldn’t expect that to work)

does the default livekit-server install add new reverse proxy info? i will check

fixed it. it never occurred to me to rebuild the executable after pulling from github.

audiobutton_stale_enabled.mkv

<@U02EU2ZPTQU> <@U01KZ61GV5Z>

Hi folks.

Here something very strange going on:
I'm working with:
```"livekit-client": "^1.0.0",
"@livekit/react-components": "^1.0.0",```
*I'd like to customise the buttons in ControlsView.*
So instead of importing it like so:
```import { ControlsView } from '@livekit/react-components'```
and passing it down as `controlRenderer`,
I've copied the content of `node_modules/@livekit/react-components/src/components/ControlsView.tsx`,
*changed nothing initially, only the relative imports:*
```import { AudioSelectButton } from '@livekit/react-components'
import { ControlButton } from '@livekit/react-components'
import styles from '@livekit/react-components/src/components/styles.module.css'
import { VideoSelectButton } from '@livekit/react-components'```
*This already led to malfunction in the control buttons*, especially `AudioSelectButton`:
It seems that the `onClick` event handler of _Audio_ doesn't get any new state of the `enabled` const.
So only one click is possible at max. Then no change of mute/unmute is possible until .... I trigger the switch on video.
Then `enabled` in `onClick` on _Audio_ gets updated one time.

*Please, take a look at the screen recording in the attachment.*

I believe the fix has already been released under the version v1.0.1 -- <https://github.com/livekit/server-sdk-js/releases/tag/v1.0.1>

With this PR in particular: <https://github.com/livekit/server-sdk-js/pull/40>

Ah, yeah didn't realize we already released 1.0.1 yesterday

Yeah, I'm using them in an implementation that uses the js client sdk. For example, here: <https://github.com/bekriebel/fvtt-module-avclient-livekit/blob/be7521d56e2a0962e80ef610420eee9689b9d684/src/LiveKitClient.ts#L1232>
and here: <https://github.com/bekriebel/fvtt-module-avclient-livekit/blob/be7521d56e2a0962e80ef610420eee9689b9d684/src/LiveKitClient.ts#L780>

we'll take a look at this, track published webhooks are pretty new and it's possible there's a bug there.

Whoops! I missed the webhooks part. My brain just read "hooks" :grin:

<@U02Q46USG4D> Which version of server are you using? Track publish/unpublish hooks were first available in v0.15.6 (that is quite old though, almost three months, released on Mar 29).

it’s possible the server code was that old….

anyway - just upgraded to latest and now i’m only receiving participant_joined and participant_left hooks

just verified on our side. we are indeed sending back track published/unpublished webhook calls.

No idea what;s going on. I have a completely vanilla go client with code pasted from docs. I am running the server from bin/livekit-server, not docker 

It’s not blocking me, but it is confusing :)

so you are getting other webhooks, just not TrackPublished?

Yeah. This has been when using <http://example.livekit.io|example><http://example.livekit.io|.><http://example.livekit.io|live><http://example.livekit.io|kit.io> btw. I don't know if the egress hooks are working as I haven't fixed that egress issue I had yet. 

I'll test adding say a screen share track 

To be clear I get room-started, participant-joined, room-finished, participant-left

ok, let me give this a try with the same set up. and you are using Go SDK to receive webhooks?

I apologize in advance if I've done something dumb 

<https://gist.github.com/mwk24/cbf8b1b3eb8d36eb565e485ad6fd2eb3>

same cause: <https://livekit-users.slack.com/archives/C01KVTJH6BX/p1659715175758159?thread_ts=1655037070.514339&amp;cid=C01KVTJH6BX>

For the server SDK to talk to the server, I'm pretty sure it's just the standard websocket port that is used for signaling. If you are talking about an app talking to the SDK, there isn't any networking involved there unless you write something that does so.

if you are using the Go Server SDK, it kind of functions like a client SDK. (it can still punch through most firewalls without additional configuration). Other SDKs don't require any ports to be open.

It appears this is being recorded in `localParticipant` as a `microphoneError` ...

I'm trying this using the js client SDK at version 1.0.4.

Ok - weirdly, it looks like this error was caused by there being no video device.

Hi <@U03G00XN9CJ> , the correct usage should be `lksdk.ReaderTrackWithFrameDuration` . They’re the same function, but was renamed to make it sound more meaningful. I’ll update it, sorry for the confusion!

Thanks <@U02SGSET1RT> for your quick reply. I have another question. Here is what I did.

1. I used the <https://github.com/livekit/client-sdk-js/blob/main/example/sample.ts> to run a client, connecting to my server.
2. I run the go program on my server side to simulate a botuser and publish a track of a short video using server API room.LocalParticipant.PublishTrack. The program runs and exits without any problem. 
3. At the client side, I see the botuser join the room, but did not see the video track created/published by the botuser. Did I miss some steps here?
Thanks!

i figured this out by setting the following before and after the publishing codes. Could you explain why it does not work without setting up a waiting channel. Is that because the program ends too quickly? Thanks.

Before: done := make(chan os.Signal, 1)
    signal.Notify(done, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT)

After: &lt;-done

yup, without running a waiting loop, your program would immediately exit after publishing