RTCP-mux for Plain Transport RTP IN

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.

Thanks for a great project!! Love it.

I don’t understand. rtcpMux is enabled by default in router.createPlainTransport(). You need nothing in RtpSendParameters to indicate that.

1 Like

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)

This is my code

        //let's send the receive audio to mediasoup client
        const options: ProducerOptions = {
          kind: 'audio',
          paused: false,
          rtpParameters: {
            rtcp: {
              mux: true
            },
            codecs: [{
              mimeType: 'audio/opus',
              payloadType: session.remotePayloadType,
              clockRate: 48000,
              channels: 2
            }]
          }
        };
        transportToFs.produce(options).then(producerForMs => {
          // let mediasoup client know to consume this
          console.log('producerForMs', producerForMs);
        });

What does it mean “I don’t know the SSRC”? I hope FreeSwitch adds a=ssrc line into its generated SDP offer, right?

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:

  1. An entry in encodings with ssrc.
  2. An entry in encodings with rid.
  3. 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:

So, somehow, it must be ready to send a=ssrc when using regular unencrypted plain UDP transport for RTP.

Can I make a donation to get MediaSoup to pull it from RTCP-mux?

I am setting this up as SIP connection.

This is the SDP from FreeSwitch with the IP masked out.

v=0
o=FreeSWITCH 1587654382 1587654383 IN IP4 xxxx
s=FreeSWITCH
c=IN IP4 xxxx
t=0 0
m=audio 22296 RTP/AVP 100 101
a=rtpmap:100 opus/48000/2
a=fmtp:100 useinbandfec=1; stereo=1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp-mux
a=rtcp:22296 IN IP4 xxxx

Using:
FreeSWITCH Version 1.10.2-release+git~20191231T140119Z~f7bdd3845a~64bit (git f7bdd38 2019-12-31 14:01:19Z 64bit)

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).

It is the current version of FreeSwitch as 2019-12-31.

Opened a ticket with them, but they are not very responsive and my project is at a standstill at this point and I am out of ideas.

Thanks for considering.

Making progress here and hoping it would help others…

When making the SDP offer, if I change RTP/AVP to RTP/AVPF, FreeSwitch sends the SSRC: m=audio {mport} RTP/AVPF {payloadType}

v=0
o=FreeSWITCH 1587659473 1587659474 IN IP4 xxxx
s=FreeSWITCH
c=IN IP4 xxxx
t=0 0
a=msid-semantic: WMS klNy6C0zPnF1GHimljgWwJ6uh2YZVTN5
m=audio 23548 RTP/AVPF 100 101
a=rtpmap:100 opus/48000/2
a=fmtp:100 useinbandfec=1; stereo=1
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=rtcp-mux
a=rtcp:23548 IN IP4 xxxx
a=ice-ufrag:Jos5Xoq5hfU3YyYU
a=ice-pwd:PjLzv2ZUQgPaGXGgbYbZdsUl
a=candidate:9347119714 1 udp 659136 xxxx 23548 typ host generation 0
a=end-of-candidates
a=ssrc:1460839061 cname:5ru1UlrAzXr5uzhG
a=ssrc:1460839061 msid:klNy6C0zPnF1GHimljgWwJ6uh2YZVTN5 a0
a=ssrc:1460839061 mslabel:klNy6C0zPnF1GHimljgWwJ6uh2YZVTN5
a=ssrc:1460839061 label:klNy6C0zPnF1GHimljgWwJ6uh2YZVTN5a0

Will continue after dinner

1 Like

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.

mediasoup does not generate SDPs, so it knows nothing about sendonly and recvonly. The SDP is up to you :slight_smile: