Issues around webrtc datachannels?

[Trey Hutcheson]

I am observing some unexpected behavior regarding datachannels and
webrtcbin; this is gstreamer 1.18.2.

Scenario 1:
* 1 peer (webrtcbin) is initialized and a data channel is created, but no
media (audio/video) is linked as an input. Webrtcbin can successfully
create an offer, and I can successfully negotiate sdp with a remote peer
(chrome). The data channel is opened, and I can send data to the browser.

*However*, if I later attach any media whatsoever and then try to create a
new offer from the first peer, it dies horribly. The entire process crashes
with the following messages:

0:00:14.748822643 2066528 0x7fffb00116a0 INFO               webrtcbin
gstwebrtcbin.c:3322:_create_sdp_task:<webrtcbin_ep1> creating offer sdp
with options (NULL)
**
ERROR:../gst-plugins-bad/ext/webrtc/gstwebrtcbin.c:2304:sdp_media_from_transceiver:
assertion failed: (trans->mline == -1 || trans->mline == media_idx)
Bail out!
ERROR:../gst-plugins-bad/ext/webrtc/gstwebrtcbin.c:2304:sdp_media_from_transceiver:
assertion failed: (trans->mline == -1 || trans->mline == media_idx)

So what I'm saying is this - if I create a data channel *first* and
negotiate a stable signalling state, I can not then later add actual media
and re-negotiate.

* Scenario 2:
I tried to reproduce this behavior in a separate repo with two separate
gstreamer pipelines using webrtcbin (instead of a browser as the remote
peer). In this case, I can create an offer from the first peer that only
defines a data channel, and the second peer will respond with an answer,
and both sides each swap ice candidates, but they never actually connect.
But again, if I attach any input media first, then things connect and work
just fine.

I'm still investigating to make sure I can add data channels *after* a
successful initial negotiation with media and continue to renegotiate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210126/41c0876e/attachment.htm>