Single WebRTC stream per handle?

[Dave Ball]

Hi,

I'm building a card game with integrated video-chat between the players.  Each player will publish their own stream, and subscribe/watch the feeds of other players from Janus.  Just the same as a video conference.

I'm using the VideoRoom plugin and when subscribing to another feed I get the message
"Already in as a publisher on this handle".

Having read the documentation further, I believe that I need to create a new handle for each webrtc stream - is this correct?  So if there are three players in the game, each player will "attach" three times, once as a publisher and twice to subscribe to the feeds from the other players.

Currently, each player is trying to subscribe on the same handle that player uses to publish - it seems this doesn't work but I can't see anything explicit about this in the docs.

Kind regards,
Dave

[Mirko Brankovic]

You have to attach new handle id for every stream you want to publish or subscribe if you use master, but on multistream you can use one, but signaling is a bit different, so you have to read PR

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/6e6986da-07d6-417a-89bb-8a905a5ae121n%40googlegroups.com.

[Dave Ball]

perfect - Thanks  Mirko.  Really glad I found Janus.

Dave

[Dave Ball]

Reading through the #1459 PR, for videoroom the multistream branch expects separate PeerConnections for publishing and subscribing.  So a publisher can publish multiple streams (over PC1) and a subscriber can subscribe to streams from different publishers (over PC2), but a single PC can't be used for both Publish and Subscribe.

Is a PeerConnection 1-1 with a "handle" in Janus?  E.g. each time I "attach" to the plugin, I can negotiate a single PeerConnection for that handle, which will be either publishing or subscribing.

My initial assumption was that for a given user(browser) I could "attach" once creating a single handle, and then publish/subscribe multiple times to that handle each negotiating a new PeerConnection / WebRTC transport to the browser.  Am I correct that this isn't possible?

My current understanding is that in both Master and Multistream branches

 - I need to "attach" for each PC/handle,

 - each PC/handle can either publish _ or_ subscribe (not both)

 - in master each PC can only contain one audio, one video and one data stream, but in the Multistream branch a PC can carry multiple streams (unified plan)

 - in Multistream a single subscriber PC/handle can subscribe to streams from different publishers.

Before I get stuck into my refactoring, does this sound correct?

Many thanks!

Dave

[Dave Ball]

in essence I was expecting the WebRTC channel to be associated with the "join" / "room" entities within Janus, but it appears this was a false assumption on my part, and the WebRTC connection is actually at the "attach"/handle level within Janus.

I think...  

Kind regards,

Dave

[Mirko Brankovic]

I think you got it 100% correct, that PC is 1 on 1 with attach/handle_id in multistream branch, but let someone else confirm also.

To view this discussion on the web visit https://groups.google.com/d/msgid/meetecho-janus/aa3ece7b-27f8-49fe-8c7b-48b9b4a32424n%40googlegroups.com.

--

Regards,

Mirko

[Lorenzo Miniero]

That's correct, each handle can only have a single PeerConnection associated with it. As such, when you need more PCs, you need additional handles.

L.

[Dave Ball]

Great - thanks guys.  Really appreciate your assistance!

Kind regards,

Dave

[Daniel Davis]

I'm trying to change my video conference app to share screen on a separate Peer Connection from the One that shares video and audio of the participants.  When I create a new Peer Connection I'm registering like this:

let register = { request: "join", room: self._videoRoomId, ptype: "publisher", display: `${self.username}|${self.userId}|LocalScreenShare`, token: self.userId, pin: self._pin };

pluginHandle.send({ message: register });

then on the joined event I'm publishing my feed with create offer:

{
audio: {deviceId: undefined}

audioRecv: false

audioSend: true

keepAudio: false

keepVideo: false

replaceAudio: undefined

replaceVideo: false

update: false

video: "screen"

videoRecv: false

videoSend: true

}

When I query room participants I get this:

{
display: "dan|02feb237-41ce-4484-9f01-96a16a64d19f|LocalScreenShare"

id: "ff9aa955-1a19-41f8-b7e5-846368f3f0c9"

publisher: false

}

Any ideas on why publisher would be false?

[Daniel Davis]

It looks like joining with ptype: "publisher" has little bearing on whether the video room plugin considers the participant a publisher.  I guess ptype: "publisher" just means the user intends to become a publisher.

The reason my screen sharing plugin handle was not joining correctly was because I was not handling the jsep in the onmessage callback correctly.  I forgot to instantiate the variable "newFeed" that holds the pluginHandle, so when I called newFeed.createAnswer, nothing was happening because newFeed was undefined.