Using FreeSwitch to bring a phone into a media-soup meeting.
Almost everything is working and the phone can hear the participants in the meeting. However, trying to get RTP feed from FreeSwitch into Mediasoup server, I have one question on this:
Since FreeSwitch supports / uses RTCP-MUX, how can I create the RtpSendParameters in a way that it gets it from RTCP-mux? I am not sure how to obtain the SSRC otherwise and stuck at this point.
Correct. Then I have to call produce() on PlainTransport and provide the RTCPParameters for the FreeSwitch audio stream. “codecs” is required, but I don’t know the SSRC… so I get this error
(node:20642) UnhandledPromiseRejectionWarning: TypeError: wrong entry in rtpMapping.encodings (missing ssrc or rid, or rtpParameters.mid)
at Channel._processMessage (/opt/gw-server/node_modules/mediasoup/lib/Channel.js:203:37)
at Socket.Channel._consumerSocket.on (/opt/gw-server/node_modules/mediasoup/lib/Channel.js:68:34)
at Socket.emit (events.js:198:13)
at addChunk (_stream_readable.js:288:12)
at readableAddChunk (_stream_readable.js:269:11)
at Socket.Readable.push (_stream_readable.js:224:10)
at Pipe.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)
If that’s true (FreeSwitch does not add a=ssrc in to its SDP offer) then there is nothing we can do.
mediasoup is ready for handling multiple streams (multiple Producers) over the same transport (WebRTC, plain or pipe transport), so it needs some minimal info to match received RTP and its corresponding Producer. So, in SendRtpParameters you need to signal at least one of these fields:
An entry in encodings with ssrc.
An entry in encodings with rid.
mid.
If FreeSwitch adds none of them, then please blame FreeSwitch because we are in 2020.
Said that, AFAIK FreeSwitch supports WebRTC, and it does generate WebRTC SDPs with a=ssrc lines:
Just to be clear, I have no idea about FreeSwitch, so the version tells nothing to me.
First, please ask in the FreeSwitch forum whether there is a way to signal a=ssrc. If the answer is “no”, come back to us next week and we’ll see, but I cannot promise anything (specially busy nowadays).
Good catch. However note that such a SDP also has ICE candidates. I hope FS is ready to work even if the remote (the mediasoup PlainTransport) does NOT support ICE.
Good observation… thanks. Looks like it should be easy enough to disable ICE/STUN for FreeSwitch. Will post an update once everything is working. Suspect that it might be interesting for others to allow regular phones to join a mediasoup meeting. I know there are some prototypes around other media servers, but FreeSwitch seems like the right answer for a production solution with support for gateways from Signalwire and others.
Upon custom policy, if FS sends a SDP offer with ICE and receives a SDP answer without ICE, it should discard ICE and switch to regular/legacy procedures (trust the remote IP:port in the c= and m= lines and so on). I hope.
Just FYI: the ICE offer does not seem to affect behavior. However, sendonly and recvonly SDP offers works, but then are disconnected by FreeSwitch with a timeout after a few seconds. Using sendrecv on all offers resolve the timeout issue. This seems to be an issue with FreeSwitch, but the workaround seems to work for now.