Alex/adding display name

[alexlivekit]

No description provided.

[changeset-bot]

🦋 Changeset detected

Latest commit: a903bff

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

💥 An error occurred when fetching the changed packages and changesets in this PR

Some errors occurred when validating the changesets config:
The package or glob expression "github.com/livekit/protocol" specified in the `fixed` option does not match any package in the project. You may have misspelled the package name or provided an invalid glob expression. Note that glob expressions must be defined according to https://www.npmjs.com/package/micromatch.

[CLAassistant]

All committers have signed the CLA.

[alexlivekit]

I'm guessing mage proto just regenerates everything, including unmodified files.

I have had more recent versions of both protoc and protoc-gen-go-grpc and that resulted in some major changes in a lot of files, so this is the result of the minimal set of changes I managed to produce thus far.

Please let me know if there's a better way.

[nishadmusthafa]

I'm guessing mage proto just regenerates everything, including unmodified files.

I have had more recent versions of both protoc and protoc-gen-go-grpc and that resulted in some major changes in a lot of files, so this is the result of the minimal set of changes I managed to produce thus far.

Please let me know if there's a better way.

Usually I only use mage proto to make sure the generation is running fine and only commit the .proto files. There is a github action that will generate everything and create a commit for the autogenerated files.

[nishadmusthafa]

@dennwc perhaps for another change, but couldn't we reuse CreateSIPParticipantRequest here ?

[dennwc]

Not directly, but yes, this is on my TODO list as well.

Sharing one structure likely won't work well, because internal has a different representation of a few things (e.g. feature flags).

I was thinking that we should slice this structure into a few smaller ones. Everything related to media setup can be one structure, shared for internal Create, public Create and also for inbound trunks. Similarly, there are fields related to how SIP should join LK room, this could be another structure shared for Create and EvaluateDispatch. The plan is also to allow storing these objects directly into the DB, so that we don't have to flatten/unflatten from SQL and add columns each time we add another flag that is never used as a filter for DB queries.

[dennwc]

Not directly, but yes, this is on my TODO list as well.

Sharing one structure likely won't work well, because internal has a different representation of a few things (e.g. feature flags).

I was thinking that we should slice this structure into a few smaller ones. Everything related to media setup can be one structure, shared for internal Create, public Create and also for inbound trunks. Similarly, there are fields related to how SIP should join LK room, this could be another structure shared for Create and EvaluateDispatch. The plan is also to allow storing these objects directly into the DB, so that we don't have to flatten/unflatten from SQL and add columns each time we add another flag that is never used as a filter for DB queries.

[dennwc]

In theory, we could avoid optional here, since we can populate display_name to a number in NewCreateSIPParticipantRequest. The only concern would be that the backend still cannot know if it should follow the old logic or a new one.