I am working on connecting generic webrtc client with mediasoup backend, it works in my prototypes, but i want to reduce number of transports to one and i hit a wall - preferredPayloadType is not honored by consumers. Tried to search the code - it looks like it is not used on native side at all. Am i missing something? Is there a way to force use specific payload type instead of generated one?
Please describe the topic a bit more. Just in case:
There are reasons for using separate PCs (transports) for sending and receiving in mediasoup-client.
Sorry, but what reasons?
I have everything working on my proof-of-concept with two transports/pc. I just want to have a different logic for consumers - i want browser/app side always to make an offer and i am unable to generate correct answer with payloadType from the offer, it always dynamically generated (100).
I am not sure if this an issue in my case - i just see media flowing between transports, but i can’t hear any sound on both sides.
Ah! I found the answer: What are the design limitations leading to separate send/receive transports on the client and can we lift them?
Basicaly mediasoup just forwards packets and can’t (i suppose) change payloadType on consumer side.
As explained in that topic is more than just rewriting payload types. The limitation is not in mediasoup server but in client side due to SDP.