I’m unable to establish a connection with a Videobridge data channel.
The candidates are accepted, I see logs indicating that ICE has completed. It opens the socket and enters a listening loop.
After that point, I end up with “WARNING: Dropping a DTLS packet. This DtlsPacketTransformer has not been started successfully or has been closed.” in the logs.
This shows up every time the client sends a ClientHello message.
I have bundling disabled in this case. This seems to be the only difference between this client, and a participant using chrome. Looking through the Videobridge code, when bundling is enabled, the data channel is added to an existing RTPTransport, and when disabled it creates a new one.
Just wondering if it’s possible that the channel expects that the DTLS handshake was already completed from other streams in the bundle?
Has anyone had success with data channels without bundling?
Out of curiosity, what’s your use case for non-bundle? As of now it’s something we’re planning on deprecating support for in the new bridge.
@bbaldino the WebRTC libraries used by the client do not support bundling.
Which libraries/client are those?
The client uses IceLink. We were able to get Audio and Video working, next hurdle is getting the data channel established. We currently are not understanding why we are having difficulty, so far the only thing that seems different is that we have bundling disabled.
FWIW, data channels will only work when bundling is enabled.
Tracked this down to the
AbstractRTPConnector always being null in
DtlsPacketTransformer when a
TransportManager only contains a single
AudioChannel extend from
SctpConnector extends from
RTPChannel - in the function
maybeStartStream there is a call to
stream.setConnector(connector), which is implemented in
MediaStreamImpl. This takes the
StreamConnector object and generates either a
RTPTransformUDPConnector or a
Doing this, triggers
rtpConnectorChanged in the
RTPConnector object, which ends up calling
SrtpControl here is implemented by
DtlsControlImpl. This calls
properties.put triggers the
propertyChanged listener in
DtlsPacketTransformer which calls it’s own
setConnector() function that will now call
maybeStart(). This will start the DTLS handshake listener provided that both the connector and the media type are set.
The whole process outlined above is never triggered by the
SctpConnector object on its own. When bundling is enabled, the
SctpConnector object assumes that there is an Audio and Video channel already part of the associated
TransportManager. With a video and audio channel already in the TransportManager, they have already kicked off the above process which ends up setting the
DtlsPacketTransfomer connector. If there is only a data channel, then this process will not occur.
Yeah, that’s exactly the case. Sorry, I didn’t notice your question earlier.
@amcgowan: Can you tell me how did you disable bundling ? I dint find that option.