I noticed WebRTCTransport does not contain producers map, is this intentional? I swear it was there before, I see:
getProducerById
getDataProducerById
consumers
dataProducers
dataConsumers
No producers in this list. Thanks for understanding. I use latest 3.9.2 not sure when this got adjusted or if it was, hoping it’s not a me problem.
That’s never been public api
Yeah not sure I had seen it listed, but was using it to retrieve producers from users transports. So was this removed then?
Just public api is guaranteed to be kept. Other things are internal stuff and apps should not rely on them. There is a long discussion about this in a recently closed issue or PR in GitHub.
Appreciate the response, that makes sense. I can add the values to appdata no issues! 
I’m surprised how many people used private undocumented API 
Haha were other people using this?
I was convinced it was just not written in documentation yet. Ooops
Yeah, some relied on _* properties in various places too
I know I “did”; no foul though appData works fine. Good to know to not do that, think it was an early mistake or with how I was signaling I required it but no foul.
Appreciate the fast response, I was reinstalling media-soup a few times like, huh.
Curious, why was this removed? Was it due to efficiency or problems internally? Being private no documentation I wonder, but perhaps it’s a mistake to?
Appreciate you guys!
It’s there but now it’s #producers instead of _producers, so now it’s real JS private field.
Similar questions seems to be repeated on and on. May I ask what’s the rationale for keeping those collections completely private? Why not make public read-only iterators for enumerating producers and consumers in the transports and routers in the workers, as well as indexers for getting these items by ids?
Rationale there. I’m afraid that many people have been accessing and relying on private API but definitely not my problem. The public API is clearly documented.
Sorry, but I do not understand.
“I have called
consumer = transport.consume()but later I don’t know in which transport I created that consumer”
Suppose I know exactly in which transport I created the consumer with the given id. I believe it is a common practice that transports are associated with peers, and mapping the peers to the transports is a task for the user app. But then, knowing that the consumer is there, I just want to get a reference to it. What wrong with that? Why do I need to hold a duplicate external collection of consumers that belong to the particular transport? What “doors” will open the public indexer and the iterator? Will consumers be shifted from one transport to another without my knowledge or what?
Whatever task that can be easily done by the user app won’t be provided by mediasoup. That’s the philosophy. I’ve built tons of apps on top of mediasoup and have never needed to get a list of Consumers per Transport. And if I needed it, I could make a simple logic to hold them within my app. mediasoup is never gonna provide the user app with sugar api or opinionated api.
Well, for once I cannot agree with that. The api that brings optimization (makes a duplicate map unnecessary) at no cost is not a sugar api.
Duplicated maps cost nothing unless we’re dealing with millions but a 1core->64core instance would never have such use case so it’s no inefficiency there. Simply an inconvenience for those that spent long hours coding with these private apis.
Fortunately for me it was a matter of adding producers to appData and keeping track that way, but for global search I had mapped the room and user handle. Ex.
Transport.get(roomname).get(userhandle)
So if I loop through a room or its users I can still through appData get their producers, if there’s active consumers which pipes/networks they belong to, how much they’ve been consumed.
I’ll admit, using the private API I didn’t think was a risk but I get it fully, there’s better ways to setup and IBC just trying to apply the dankest standards. No foul here and hope others can adjust. IBC you do amazing work, this is one slip up for me but answered quickly and is no problem.
I would ask @ibc if you could maybe reconsider; this is useful stuff for public API. However if this slows the soup process down or hinders it any, I’m in all favor. Stay lit.
Then the primary maps with read-only public access cost less than nothing. 
In theory yes, unless there is a loop that repeatedly had to check these maps then there’s added delay in processing. Containing large maps no concern till then!