Incorrect reporting for the RTP capabilities if the 'Device' is used only for consuming streams

[Mahmoud-Masri]

Bug Report

Issue description

Some android devices support decoding h264 but does not support encoding it,
Most Huawei devices are like this (even the modern ones)

These devices response only vp8/vp9 support for the following code

const pc = new RTCPeerConnection(
			{
				iceServers         : [],
				iceTransportPolicy : 'all',
				bundlePolicy       : 'max-bundle',
				rtcpMuxPolicy      : 'require',
				sdpSemantics       : 'unified-plan'
			});
pc.addTransceiver('audio');
pc.addTransceiver('video');

const offer = await pc.createOffer();

console.log(offer.sdp)

which is what is used in the Chrome74 Device Handler

however response with some h264 support (in addition to the vp8/vp9 support) using the following code

const pc = new RTCPeerConnection(
			{
				iceServers         : [],
				iceTransportPolicy : 'all',
				bundlePolicy       : 'max-bundle',
				rtcpMuxPolicy      : 'require',
				sdpSemantics       : 'unified-plan'
			});

const at = pc.addTransceiver('audio');
const vt = pc.addTransceiver('video');

// you can add the following to check the decoding capabilities
at.direction = "recvonly"
vt.direction = "recvonly"

const offer = await pc.createOffer();

console.log(offer.sdp)

notice that setting the direction to 'recvonly' cause thee sdp offer to response differently

so in case you want to consume a h264 stream even though the h264 decoding is supported, the device response with empty list for the RTP capabilities causing the mediasoup server router to return false for the canConsume

router.canConsume({
            producerId,
            rtpCapabilities,
        })

resulting in inability for the user to consume the stream

right now in our application we have a patch for mediasoup-client to accept a direction which can be 'sendonly' | 'recvonly' | 'sendrecv' and return the RTP capabilities accordingly resulting in a functional consumtion

here is a short list of some of the devices which we found have this issue

Samsung SM-G532F
Samsung SM-J320H
CASPER_VIA_M3
Etab5
HRY-LX1T
HTC Desire 830
Huawei ANE-LX1
Huawei ANE-LX2
Huawei DRA-LX2
Huawei ELE-L29
Huawei FIG-LX1
Huawei JSN-L21
Huawei MRD-LX1
Huawei POT-LX1
Huawei SNE-LX1
Huawei VNS-L31
Huawei VOG-L29
INE-LX2r
LG-D693TR
LG-K430
M2004J19C
MAR-LX1A

we tested the patch and it worked for what we have tested up to now though we still haven't finish testing all of them

[ibc]

Thanks for reporting. I cannot accept a solution that requires passing "sendonly", "recvonly" or "sendrecv" to the Device constructor. The device can later create send transports and recv transports. There is where we should run different code to get capabilities from a local SDP offer. But unfortunately we don't do that (yet).

I want to get rid of the Device class and instead let the app directly create sendTransports or recvTransports, so mediasoup-client will compute capabilities in each of those transports and will run different code if it's for sending or receiving. But we are not yet in this stage.

Something that you can do within your app (to avoid having to use a fork) is calling transport.produce() with the desired codec capability, so mediasoup-client won't choose but your app will do:

• https://mediasoup.org/documentation/v3/mediasoup-client/api/#transport-produce
• https://mediasoup.org/documentation/v3/mediasoup-client/api/#ProducerOptions

I'll let this issue open since it's a good use case that we'll address in a future re-design.