Using in-band WebRTC DCEP (ppid 50) for SDP DataChannels

[j1elo (Juan Navarro)]

@ibc

• A client can send (a WebRTC DCEP packet, PPID 50)
• mediasoup should (parse the data)
• Then it should notify Node/Rust layer

That’s it. The SCTP Association is internally owned by the mediasoup Transport, so the most logical place to have such event is in the SCTP-enabled transports.

This is a very WebRTC-specific feature, so maybe it makes sense only as a WebRtcTransport event. But I can visualize an app wanting to build these packets on its own so maybe any SCTP-enabled transport should be allowed to have it (something to think more about):

sctpTransport.on("inbanddatachannel", fn(dcParams: DataChannelParameters))

// Or maybe just "datachannel", the same name used by WebRTC.
sctpTransport.on("datachannel", fn(dcParams: DataChannelParameters))

with DataChannelParameters being very similar to DataProducerOptions:

type DataChannelParameters = {
    sctpStreamParameters: SctpStreamParameters;
    label: string;
    protocol: string;
};

@ibc

• Node/Rust app can then decide to create a DataProducer with that info.

Yes:

const dataProducer = await sctpTransport.produceData({
    sctpStreamParameters: dcParams.sctpStreamParameters,
    label: dcParams.label,
    protocol: dcParams.protocol,
});

@ibc

• Node/Rust app can then dataConsume() it so SCTP messages received in that SCTP streamId are forwarded to clients. This last part is unclear to me. The app should call transport.consumeData({ dataProducerId }) in mediasoup side as usual but it may decide to signal the info of the created DataConsumer to receivers (so negotiated datachannels as usual) or may decide to send the datachannel info via SCTP (with PPID 50) to receivers that are pure SDP clients.

Correct. Same as the official WebRTC API allowing to distinguish between out- or in-band with the negotiated boolean, I believe it would make sense a similar toggle here.

DataConsumerOptions would have an inband (if you like that name more than “negotiated”, which admitely is a bit confusing) so the call could look like this:

const dataConsumer = await sctpTransport.consumeData({
    dataProducerId: "...",
    inband: true,
});

// Or `inbandNotify` or `inbandDcep` to be more technical, or any variation.

This, of course, would be one of those parameters that are documented as “Just if consuming over SCTP”. The effect of true is to tell mediasoup that it needs to send a WebRTC DCEP packet to the remote side on its Stream ID.

@ibc

• Problem I see here is that mediasoup doesn’t deal with bidirectional streamId (a DC streamId can be used to send or to receive, but both, although I may be totally wrong and such a limitation only exists in mediasoup-client, probably).

I’m currently having a separate issue with this, but will talk in a different topic to keep things separate.

EDIT: Done – Need to specify DataConsumer SCTP StreamId

@ibc

The idea behind having a library that makes it possible for pure SDP clients to interact with mediasoup was not that we should make tons of changes in mediasoup to allow creating things without server side consent.

The thing is, mediasoup is 99% already there in being able to work as a fully standalone WebRTC server!

Was not for this specific thing, needing collaboration from a helper client (like mediasoup-client) would really be just a nice-to-have, not a strict requirement. And that’s quite a good property for the server, I think.

Things work fine if the server is supplemented with an SDP-ORTC translation library. That’s a solved problem, it’s easy to convert m= sections into lists of codecs. But a support library only goes so far without help from the server for core protocol features. For stuff that WebRTC specs decided must be in-band, no library can “polyfill” anything, such as DTLS (no other way to do it) or… in-band DataChannels.

---

I’m working on a dirty “let’s break everything” solution to verify the feasibility of doing all this. Will report when I know more.