[jitsi-dev] Data channel messages and SSRC


#1

I have managed to get the datachannel messages to go both ways and confirmed the accuracy of the communication which means the fundamentals are OK.

I have seen some messages:

{"colibriClass":"DominantSpeakerEndpointChangeEvent","dominantSpeakerEndpoint":"32c65abaa"}videobridgetest.js:420 Got Data Channel Message: {"colibriClass":"LastNEndpointsChangeEvent","lastNEndpoints":[],"endpointsEnteringLastN":[],"conferenceEndpoints":[]}{"colibriClass":"LastNEndpointsChangeEvent","lastNEndpoints":["2583855aa"],"endpointsEnteringLastN":["2583855aa"],"conferenceEndpoints":["32c65abaa","2583855aa"]}

videobridgetest.js:420 Got Data Channel Message: {"colibriClass":"EndpointConnectivityStatusChangeEvent","endpoint":"2583855aa", "active":"false"}
videobridgetest.js:420 Got Data Channel Message:

Question 1.

Is there a list of them anywhere?

Question 2.

Do they provide the SSRC (of the stream being sent from the bridge) as well as the endpoints?

(obviously the answer above is no)

Question 3.

Does anyone think it would be useful to modify some to provide SSRCs as well as Endpoints.


#2

I have managed to get the datachannel messages to go both ways and
confirmed the accuracy of the communication which means the fundamentals
are OK.

I have seen some messages:

{"colibriClass":"DominantSpeakerEndpointChangeEvent","dominantSpeakerEndpoint":"32c65abaa"}videobridgetest.js:420
Got Data Channel Message:
{"colibriClass":"LastNEndpointsChangeEvent","lastNEndpoints":[],"endpointsEnteringLastN":[],"conferenceEndpoints":[]}{"colibriClass":"LastNEndpointsChangeEvent","lastNEndpoints":["2583855aa"],"endpointsEnteringLastN":["2583855aa"],"conferenceEndpoints":["32c65abaa","2583855aa"]}

videobridgetest.js:420 Got Data Channel Message:
{"colibriClass":"EndpointConnectivityStatusChangeEvent","endpoint":"2583855aa",
"active":"false"}
videobridgetest.js:420 Got Data Channel Message:

Question 1.

Is there a list of them anywhere?

Not exactly a list, but some docs here:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/last-n.md
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/datachannel-communication.md

Question 2.

Do they provide the SSRC (of the stream being sent from the bridge) as
well as the endpoints?

No.

(obviously the answer above is no)

Question 3.

Does anyone think it would be useful to modify some to provide SSRCs as
well as Endpoints.

Endpoint might have multiple channels and SSRCs. We assume that a signaling channel is used to establish the connection, and use it to configure the SSRCs, so I don't think this fits well in our architecture.

Regards,
Boris

···

On 23/01/2017 07:56, John Hemming wrote:


#3

If I make changes to the code I would like to think they may be potentially adopted in the core system. If I were to create some more messages relating to streams and SSRCs are those likely to be rejected as being outwith the architecture or might they be possible considered for incorporation.

Rest itself is not really well suited as a signalling channel and I need to think on how best to do that. Alternatively rest with a webhook would operate as a signalling channel so If you wish to enourage me to stick to a signalling channel rather than using the datachannel for such things please do.

I am not sure how Rest as specified on the jitsi site would manage to do anything really as it has no function for signalling new participants apart from polling which would be awful.

···

On 23/01/2017 15:56, Boris Grozev wrote:

On 23/01/2017 07:56, John Hemming wrote:

I have managed to get the datachannel messages to go both ways and
confirmed the accuracy of the communication which means the fundamentals
are OK.

I have seen some messages:

{"colibriClass":"DominantSpeakerEndpointChangeEvent","dominantSpeakerEndpoint":"32c65abaa"}videobridgetest.js:420

Got Data Channel Message:
{"colibriClass":"LastNEndpointsChangeEvent","lastNEndpoints":[],"endpointsEnteringLastN":[],"conferenceEndpoints":[]}{"colibriClass":"LastNEndpointsChangeEvent","lastNEndpoints":["2583855aa"],"endpointsEnteringLastN":["2583855aa"],"conferenceEndpoints":["32c65abaa","2583855aa"]}

videobridgetest.js:420 Got Data Channel Message:
{"colibriClass":"EndpointConnectivityStatusChangeEvent","endpoint":"2583855aa",

"active":"false"}
videobridgetest.js:420 Got Data Channel Message:

Question 1.

Is there a list of them anywhere?

Not exactly a list, but some docs here:
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/last-n.md
https://github.com/jitsi/jitsi-videobridge/blob/master/doc/datachannel-communication.md

Question 2.

Do they provide the SSRC (of the stream being sent from the bridge) as
well as the endpoints?

No.

(obviously the answer above is no)

Question 3.

Does anyone think it would be useful to modify some to provide SSRCs as
well as Endpoints.

Endpoint might have multiple channels and SSRCs. We assume that a signaling channel is used to establish the connection, and use it to configure the SSRCs, so I don't think this fits well in our architecture.

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

If I make changes to the code I would like to think they may be
potentially adopted in the core system. If I were to create some more
messages relating to streams and SSRCs are those likely to be rejected
as being outwith the architecture or might they be possible considered
for incorporation.

Rest itself is not really well suited as a signalling channel and I need
to think on how best to do that. Alternatively rest with a webhook
would operate as a signalling channel so If you wish to enourage me to
stick to a signalling channel rather than using the datachannel for such
things please do.

I think that bootstrapping through the data channel is an interesting approach, and it might make the rest of the signalling much simpler. It doesn't fit in our architecture, but I don't think the bridge itself should prohibit such a use case. I don't know if we would accept contributions in this direction. It's not up to me to decide, and it would depend on the details of the patches.

Note that you may be able to get some of this done without modification to the bridge, using the endpoint-to-endpoint messaging.

I am not sure how Rest as specified on the jitsi site would manage to do
anything really as it has no function for signalling new participants
apart from polling which would be awful.

Our architecture depends on a separate entity (the conference "focus") which manages the session on the signaling level and only controls the bridge through COLIBRI (whether REST or XMPP). Clients shouldn't be able to control the bridge directly, as that would allowed them to e.g. mess with other participants' channels. So it really only makes sense for the bridge to be controlled by a single entity.

Boris

···

On 23/01/2017 10:58, John Hemming wrote:


#5

Note that you may be able to get some of this done without

modification to the bridge, using the >endpoint-to-endpoint messaging.

I am wondering how to get the new SSRCs to the client so the client can fire up an element to play the video. I cannot see how this can be done through messages from endpoint to endpoint.

···

On 23/01/2017 17:26, Boris Grozev wrote:

On 23/01/2017 10:58, John Hemming wrote:

If I make changes to the code I would like to think they may be
potentially adopted in the core system. If I were to create some more
messages relating to streams and SSRCs are those likely to be rejected
as being outwith the architecture or might they be possible considered
for incorporation.

Rest itself is not really well suited as a signalling channel and I need
to think on how best to do that. Alternatively rest with a webhook
would operate as a signalling channel so If you wish to enourage me to
stick to a signalling channel rather than using the datachannel for such
things please do.

I think that bootstrapping through the data channel is an interesting approach, and it might make the rest of the signalling much simpler. It doesn't fit in our architecture, but I don't think the bridge itself should prohibit such a use case. I don't know if we would accept contributions in this direction. It's not up to me to decide, and it would depend on the details of the patches.

Note that you may be able to get some of this done without modification to the bridge, using the endpoint-to-endpoint messaging.

I am not sure how Rest as specified on the jitsi site would manage to do
anything really as it has no function for signalling new participants
apart from polling which would be awful.

Our architecture depends on a separate entity (the conference "focus") which manages the session on the signaling level and only controls the bridge through COLIBRI (whether REST or XMPP). Clients shouldn't be able to control the bridge directly, as that would allowed them to e.g. mess with other participants' channels. So it really only makes sense for the bridge to be controlled by a single entity.

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev