* Cancellation counts for join/publish/subscribe.
To get a better estimate of errors.
* generated protobuf
* Create friendly-jobs-flash.md
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* Marking width and height as not deprecated.
Those fields reflect the capture dimensions.
* generated protobuf
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* updating the reporter inteface to include the gateway noop reporter
* generated protobuf
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* Add rate for memory use and total.
Load and overage for memory is calculated differently in cloud.
Removing that distinction caused memory based load to show higher load
consistently which was unintentional.
* generated protobuf
* Create nervous-ways-yawn.md
* correct next ID
* generated protobuf
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* Reworking node stats a bit.
- Introducing a rate shape that captures rate of different metrics in a
given interval. The interval is contained in that message.
- Stats can have multiple rates. This is akin to reporting different
window load avg in unix systems.
- Clean up a few things
o sys packets pct in rate (not sure what it was capturing)
o associated prom metric (this is in server code which will come in a
separate PR) (was not used anywhere internally, don't
think external projects would be using it either)
* Create tricky-ties-marry.md
* generated protobuf
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* Add a nonce to data messages.
Will be used to de-dupe messages sent via SendData API.
* generated protobuf
* comment
* generated protobuf
* add nonce to UserPacket
* generated protobuf
* 128-bit UUID as string for nonce
* generated protobuf
* UUID bytes
* generated protobuf
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
To provide backward compatibility with already existing Ingresses
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
This includes some feedback on the agents protocol:
- Rename JobDescription to AgentDispatch
- Remove participant_identity entry in the dispatch
- Deprecate namespace
- Add an agent_name field to specify what agent workers a job should be dispatched to
This also allows setting a room configuration in the token.
This PR:
- Adds StartAgentJobRequest/StopAgentJobRequest calls to start an handle manually mange an agent lifecycle
- Deprecates the JobType field in WorkerInfo as workers will now be expected to handle both kinds jobs (if the namespace supports both kinds in the first place)
- Adds a metadata string -> string map to Job to allow agent implementation to take anonymous (to us) parameters
- Adds a JobStatus and error fields to Job for status reporting (Similar to egress and ingress)
- Makes livekit_agent.proto indentation consistent with other proto files
- Add room configuration and management APIs to the Room service. Rooms configuration allow bundling most room configuration parameters under a single id, that can eventually be put as part of the room creation token.
* Add ControllerId and SelectionReason to StartSession.
This will allow media node to have those information.
Main purpose will be able to log it in all in one context.
* generated protobuf
* change name from controller_id -> controller_node_id
* generated protobuf
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* Explicitly set if subscriber_allow_pause is valid
Need to know if `false` (which would be default if not set) is
explicitly set or not.
* generated protobuf
* Use optional, thank you Lukas
* generated protobuf
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
* `SubscriberAllowPause` as a connection option.
This allows controlling stream allocator allow pause or not decision
through a connection option.
NOTE: Thinking ahead a bit, would we allow pause or not at a track
level? We are going to do subscription priority. Maybe, we can also
allow pause or not at track level by adding it to `UpdateTrackSettings`.
Wondering if things are going to be confusing if we do that also.
I think the hierarchy would be (order of increasing precedence)
- from config
- connection option added in this PR will take effect if set
- track level allow pause config if we decide to do this (have to
make sure that we can determine that the value was explicitly set in
the protocol message vs using default value in protocol message).
* psrpc updated compile
* generated protobuf
* update bootstrap psrpc
---------
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
