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.