Expose Transport Connection API

[Josh Field]

Feature Request

Lazily connecting when a consumer or producer is requested causes order of operation issues with our mediasoup wrapper. It would be great to call await transport.connect() before producing or consuming.

---

My current solution is to create dud producers & consumers, which seems inelegant:

transport.on('producedata', async (parameters, callback, errback: (error: Error) => void) => {
  const { sctpStreamParameters, label, protocol, appData } = parameters
  if (label === '__CONNECT__') return callback({ id: '__CONNECT__' })
  /// etc
})

// etc

try {
  if (direction === 'recv') {
    const consumer = await transport.consumeData({
      id: '',
      dataProducerId: '',
      sctpStreamParameters: {
        streamId: 0,
        ordered: true,
        maxPacketLifeTime: 0
      },
      label: '__CONNECT__'
    })
    consumer.close()
  } else {
    const producer = await transport.produceData({
      label: '__CONNECT__'
    })
    producer.close()
  }
} catch (e) {
  // no-op
}

But it still throws errors for consuming a data channge that does not exist.

The following solution almost works, though there seems to be some errors that arise likely due to internal magic on the sdpObject passed in to setupTransport in the various transport, this also would not work for Edge11 handler.

const handler = (transport as any)._handler
handler._remoteSdp!.updateDtlsRole(action.dtlsParameters.role === 'client' ? 'server' : 'client')
await new Promise<void>((resolve, reject) => {
  transport.safeEmit('connect', { dtlsParameters: action.dtlsParameters }, resolve, reject)
})
handler._transportReady = true

[Iñaki Baz Castillo]

I'm sorry but we cannot do those things just because you have a problem in your wrapper. The current API is correct and has no bugs. If you have problems using it due to the order of the callbacks (which is how it is for good and unavoidable reasons) then you can ask for help in the mediasoup forum, but this is not a legitimate feature request.

[Josh Field]

Would you mind explaning why an explicit connect call is not a legimitate feature request? I am aware this is intentional and not a bug, which is why I have labelled this a feature request.

[Iñaki Baz Castillo]

Because, unfortunately and due the hell of how SDP works, you cannot connect a PeerConnection unless you provide it with a sending or receiving audio/video/data stream first, and this is because connection info in the SDP is placed in media sections so media/data is required first. And this is why you are trying to add a fake producer or consumer in your code snippet above, but I strongly refuse to do that because it means having to deal with a fake first media section in the SDP that can not even be closed because, again due to the hell of SDP and bugs in almost all browsers, if you close the first media section then it will never connect at ICE/DTLS since almost all browsers expect to read the connection data from first media section, and if that section is closed hell happens.

I summarized some of these issues in https://webrtchacks.com/webrtc-sdp-inaki-baz-castillo/ long ago.

Yes, I'd love if things are like you are trying them to be, but it's not possible or there is no reliable way to make them work consistently in all browsers and existing WebRTC engines.

[Josh Field]

Understandable. Thanks for your response.