I would like to ask the forum if the ‘id’ parameter in the callback for transport.on(‘produce’, fn()) must include {id: producerId}, or if I can set {id: false} if my signaling service is not async/awaitable. Is there a way to set this after the on produce event for the transport?
I am having some issues, and it seems it may boil down to that, or rtp parameters being silly.
If anyone is feeling like a followup-question, I’d like to know any ideas about why my received video is not getting frames from mediasoup. It seems my connections and all are valid, my consumer.getStats() reports all the correct information (to my understanding) but the bytecount on the incomingvideo is always 0. I am sending video to server (verified in producer.getStats). It may be related to not returning the correct producer.id to the client in the callback as mentioned above.
You have to pass the id, yes. That’s the ID (UUID value) of the Producer in server side. You can invent any other one but not sure why you would like to do that. Just avoid passing false because it would means that all your Producers would have producer.id === false.
if my signaling service is not async/awaitable
I would just focus on fixing your signaling. Sending a request over the network and expecting a response for that request should not be so hard.
I don’t see how it can be really related, honestly. However, mediasoup-client stores all Producers into a private map in each send Transport. If all them have same if (or false) ugly things may happen.
For informational purposes, setting the producerId to false using dataproducers seems to work. I can establish multi-producer / multi-consumer setups where every peer gets every other peer’s sent data. Was hoping the same for the video feeds, but looking like not. Will post back if that solved anything.
Well, I was able to fix not returning the id of the producer, and it seems to still not have fixed my issue with the video. Just returning to say that the client-side producerId being correct or incorrect doesn’t change the video not receiving in my case.
Now that I wait for the server to reply with the producerId before calling the produce callback, the transport seems to be openeing before the producer. Thats the only difference I can tell so far.