Trace/breakpoint trap in GetNativeRtpCapabilities

I was testing the c++ demo , but I keep getting Trace/breakpoint trap from GetNativeRtpCapabilities
GitHub - versatica/mediasoup-broadcaster-demo: mediasoup broadcaster demo (libmediasoupclient). is there any was changed in the functions?

json Handler::GetNativeRtpCapabilities(const PeerConnection::Options* peerConnectionOptions)
		MSC_TRACE();std::unique_ptr<PeerConnection::PrivateListener> privateListener(new PeerConnection::PrivateListener());
		std::unique_ptr<PeerConnection> pc(new PeerConnection(privateListener.get(), peerConnectionOptions));
		webrtc::PeerConnectionInterface::RTCOfferAnswerOptions options;

		// May throw.
		auto offer                 = pc->CreateOffer(options);
		auto sdpObject             = sdptransform::parse(offer);
		auto nativeRtpCapabilities = Sdp::Utils::extractRtpCapabilities(sdpObject);

		return nativeRtpCapabilities;

Nothing coming to my mind that can cause this due to the code in libmediasoupclient.

@jmillan thanks for your input. Do you think the issue could be from the demo itself?

I added a breakpoint. When this line get called this->device.load(routerRtpCapabilities)

Then it just call auto nativeRtpCapabilities = Handler::GetNativeRtpCapabilities(peerConnectionOption)

routerRtpCapabilities returned from the server.

Where do you think I should dig deeper? I feel I could be looking into wrong direction.


What is the problem you are having?

I have experienced multiple issues, when I fix one I run into another one :frowning:
I was able to compile the demo, but when I run it I kept getting the error below

Fatal error in: …/…/media/engine/, line 39

last system error: 88

Check failed: 0 == adm->Init() (0 vs. -1)

Failed to initialize the ADM.Aborted

I searched for days trying to find a fix for this issue and tried many solutions dealing with audio on a linux box, tried pulseaudio, pipewire and installed libwebrtc-audio-processing-dev, but did not go anywhere.

I tried to disable the audio init from webrtc and from the demo, but I kept getting
Trace/breakpoint trap when getting nativeRtpCapabilities get called

I reached out to webrtc google group and I was told to update the libwebrtc because m94 was very old.

I built multiple versions of libwebrc, but mediasoup client does not compile with any version above m98, when I tried to build mediasoupclient using m105, I was getting some errors.
/webrtc/mediasoup/libmediasoupclient/src/Handler.cpp:212:88: error: no matching function for call to ‘mediasoupclient::PeerConnection::AddTransceiver(webrtc::MediaStreamTrackInterface*&, webrtc::RtpTransceiverInit&)’

right now I am stuck between google and mediasoup where google folks think m94 is old and unable to help and mediasoupclient does not work with recent libwebrtc. It is not clear if you are planning to update the client to m105

I was hoping that I can build the demo as I thought it is fastest way to evaluate mediasoup, but it is very problematic more I initially thought

@Bigcat, we’re upgrading to m112, and facing a linking error with the tests…, in case you want to help:

@jmillan I have gave up on the idea completely. The mediasoup server is amazing how it can be added to a nodejs server, but the challenges in creating a custom client seems very painful to deal with. It would be great of mediasoup support webrtc or WHIP client out of the box without needing to create a custom client based on mediasoup API. If I want to build a client for a business case, I want to be SFU agnostic. I know mediasoup server works with RTP which seems good, but webrtc feature such as adaptive bitrate and encryption are important too along with other feature, however multicast seems good option for the time being.

Are you somehow suggesting that mediasoup (clients and/or server) don’t support those things?

We create libraries. We don’t provide with full applications. What you say doesn’t make any sense. Or do you mean that we should create a full WebRTC stack from scratch (including RTP, RTCP, SRTP, ICE, DTLS, encoding/decoding, etc) that is server agnostic meaning that it would communicate with any WebRTC server by just sending and consuming SPDs? Of course we are not gonna do that. And all that super effort just because you gave up trying to get a newer libwebrtc version into libmediasoupclient?