RTC::Transport::ReceiveRtpPacket() | no suitable Producer for received RTP packet [ssrc:824347444, payloadType:96]
The ssrc value is the same sent into the rtpParameters when creating the producer. I don’t understand if the mid and rid values can be used if the ssrc is not found into ssrcTable.
Anyway, what I need to know is how medasoup can interoperate with a client without using the mediasoup-client library.
Thanks
mediasoup follows ORTC rules for matching a RTP stream against the corresponding RTCRtpReceiver (Producer in mediasoup):
If the ssrc of the RTP packet was announced in the rtpParameters then it’s associated Producer will exist in the ssrcTable.
If the ssrc is not found in the ssrcTable then mediasoup will check its MID RTP extension (if any) and look for the associated Producer in the midTable. If found, it will enter the ssrc into the ssrcTable.
Otherwise it will do the same with the ridTable.
More in detail:
When a Producer is created (via transport.produce()) it’s inserted into these tables (within a specific Transport) as follows:
You can print const dump = await transport.dump() to print those tables (among other info). This is Chrome sending audio and video (with MID in both audio/video Producers and RID based simulcast in video Producer):
You can also print const dump = await producer.dump() to see its effective rtpParameters and see if they match your expectations. Also, producer.getStats() will show stats only for the RtpStreams created in the Producer, this is, those for which at least a valid RTP packet has been received.
Ok, I fixed a code error. I have no errors from mediasoup, but the video flow from GStreamer seems stopped.
One thing I don’t understand is the candidates exchange: I see that mediasoup sends back to the client its candidates list after WebRtcTransport creation, but the client never sends its own candidates list to the server. Is it right?
I’m integrating webrtcbin into https://github.com/vpalmisano/mediasoupbin
What you need to do is converting the GStreamer generated SDP message into the dtlsParameters and rtpParameters structures and send them to the produce call to MediaSoup.
Hi all,
I’m trying to finish the integration between GStreamer webrtcbin element and Mediasoup and I’ve found a blocking problem when I try to consume a WebRTC flow from Mediasoup.
When used as receiver, webrtcbin configures its ICE connection as controlled (https://github.com/GStreamer/gst-plugins-bad/blob/1.16.2/ext/webrtc/gstwebrtcbin.c#L2721) and mediasoup emits this warning: “peer indicates ICE-CONTROLLED in STUN Binding Request”, maybe because using ICE-lite?
Yes, this was the issue I faced and on my request it is already fixed in master branch.
Please note though that RTX is not working with renegotiations in that case though, so make sure to have do-nack=false.
I checked the do-nack property in the transceiver, it is False by default. Anyway, after I setup the pipeline, I receive only some initial rtp packets, then the nicesrc element inside webrtcbin doesn’t receive nothing. I checked on Mediasoup side, the consumer is emitting rtp traces, so all seems fine on server side.
My receiver setup flow:
signalling.createWebRtcTransport -> transport
signalling.consume(transport.id, producerId) -> consumer
[transform the transport json into a SDP offer representation]
webrtcbin.emit('set-remote-description', sdp_offer)
webrtcbin.emit('add-ice-candidate', <transport iceCandidates>)
webrtcbin.emit('create-answer') -> client answer sdp
webrtcbin.emit('set-local-description', answer)
[get the dtlsParameters from answer sdp]
signalling.transportConnect(transport, dtlsParameters)
Similar flow works for me, but I think I didn’t use add-ice-candidate, but rather had them in SDP itself. Essentially I wrote serializer to SDP such that it produces identical result to Chrome 74 handler from mediasoup-client.
Also did you create paused consumer that is resumed afterwards just like with browsers?
Nothing changed after adding this line. The strange thing is that the peerconnection starts and I receive the first video frames that are correctly decoded. After some 5-10 received frames, the nicesrc element seems stalled, maybe there be some threading problem in the pipeline.
Are you creating the webrtcbin with gst_element_factory_make or gst_parse_launch? It may be that you need to pass something to the webrtcbin sink if it is created with a launch string.