Hello, I’m trying to create a stage visualization web application by streaming a video from TD to a web browser client. Currently I’m not using anything pre-built from the TD palette browser but instead using a webSocket DAT to connect to a node.js signaling server.
I had success when it was the TD side that creates the offer. But when it’s the other way around, the video track doesn’t get passed to the remote peer even though both TD and browser sides show success for the connection state:
After a bit more investigation it seems like when I call the “addTrack()” method on my webRTC DAT, even though it returns success, the video track doesn’t seem to get added to the answer SDP when I call “createAnswer()” after that. In other words, when I had success with TD creating the offer, on the browser side, when I inspect the remote description, I could see “m=video…” in the Video Lines. But when TD creates the answer, it shows only “m=application…” on the browser side.
Also, in the second case, when I call rtcDAT.getTracks() on the TD side, I can see my local video track:
But on the browser side the remote streams show up as an empty array:
Am I missing something?
Here’s a bit more info that might be relevant - Since I’m only streaming video from TD to browser, I found out that when I create the offer from the browser side, I need to create a dataChannel in order to kick start the ice gathering process. Otherwise no ice candidate will be sent to TD and the connection will therefore fail.
addTrack() is an Async call. The core nature of TD is sync though, so Derivative had to create a little workaround.
You need to use the onTrack() callback to get the track, and send the answer from there on.
(1) I’m trying to add the local track here to the answer SDP and send it outwards, and I believe the onTrack() callback is an event fired when the remote peer ( in this case the browser) adds its media track.
(2) This doesn’t explain why I don’t have any issues when adding the media track to the offer. Also, when I print out the result of addTrack() before calling createAnswer(), I get True:
Interesting… made some progress here and found out that if I added a local stream on the browser side when initiating the offer (ex. my webcam feed), the problem gets solved. Seems like if there’s no media track in the offer SDP, that will affect the answer SDP ( guessing there’s some kind of “media stream channel” that’s being created when initiating the offer )…
If I understand correctly where you are going, you shouldn’t make an offer without any stream.
In the past, you would use offerToReceiveAudio or offerToReceiveVideo as a mean to say “I am not sending video or audio, but know that I am ready to receive something.”
Thanks a lot for the solution! That’s exactly it. Didn’t realize making an offer without any stream is problematic from the MDN documentation. Much appreciated.
For anyone who might run into similar issues in the future, here are two more posts that further explain RTCRtpTransceiver and offer examples: