(WIP) Data track signaling #1229
Conversation
|
|
Tried to compile and push, but still merge conflicts. Tried resolving conflicts and it became a major disaster. Will look at this more later. |
ladvoc
force-pushed
the
ladvoc/data-tracks
branch
from
00c694f to
916df6d
Compare
ladvoc
force-pushed
the
ladvoc/data-tracks
branch
from
f1c10fc to
886b832
Compare
| } | ||
|
|
||
| message DataTrackInfo { | ||
| string sid = 1; |
There was a problem hiding this comment.
let's add handleID to this model. I think it is useful to have it in the model.
| DATA_TRACK_INVALID_NAME = 8; | ||
| DATA_TRACK_INVALID_MIME_TYPE = 9; | ||
| DATA_TRACK_NAME_TAKEN = 10; | ||
| reserved 11 to 15; // Reserved for future data track errors. |
There was a problem hiding this comment.
don't need any reserved stuff. This can just grow as needed.
There was a problem hiding this comment.
And all the data track specific name can be made generic by dropping the DATA_TRACK_ prefix. We can re-use if it fits a different scenario.
There was a problem hiding this comment.
For example, an UnpublishDataTrackRequest could get a reply with the existing NOT_FOUND reason.
|
|
||
| message PublishDataTrackResponse { | ||
| // Handle of the track that was published. | ||
| uint32 handle = 1; |
There was a problem hiding this comment.
If handle in included in the model, this field can be dropped from this message.
|
|
||
| message UnpublishDataTrackResponse { | ||
| // Handle of the track that was unpublished. | ||
| uint32 handle = 1; |
There was a problem hiding this comment.
Can change this to return DataTrackInfo so that you have both handle (assuming it is added to DataTrackInfo model) and Sid also.
There was a problem hiding this comment.
I am going to make a branch off your branch locally as I am starting to work on some initial signalling handling around this. Please let me know if you have objections to the changes I have suggested. We can discuss and pick out what works.
|
|
||
| message DataTrackSubscriberHandles { | ||
| // Mapping from data track SIDs to handles subscribers will see on incoming packets. | ||
| map<string, uint32> handles = 1; |
There was a problem hiding this comment.
also proposing changing this to map<uint32, string>.
The idea being
- receives packets for unknown handle
- look up map indexed by handle
- if a mapping is found, ensure
Sidcan be found in remote participants. - create a new subscribed data track for thatn handle
No description provided.