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?
@damencho @Boris_Grozev
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 SctpConnector channel.
VideoChannel and AudioChannel extend from RTPChannel. SctpConnector extends from Channel.
In 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 RTPTransformTCPConnector
Doing this, triggers rtpConnectorChanged in the RTPConnector object, which ends up calling srtpControl.setConnector(). The SrtpControl here is implemented by DtlsControlImpl. This calls properties.put(Properties.CONNECTOR_PNAME,connector)
Calling 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.
Boris
@amcgowan: Can you tell me how did you disable bundling ? I dint find that option.