Webrtcbin SDP Renegotation (1.18): Not in the correct state (stable) for setting remote answer description

[Trey Hutcheson]

Ok for anyone that may stumble upon this in the future - this particular
error was user error (mine). I had a bug where the offer was being
generated, and then the remote side was posting the answer *twice*; the
first one worked, the second failed because webrtcbin was in a stable
state.

On Sat, Dec 5, 2020 at 7:20 PM Trey Hutcheson <trey.hutcheson at gmail.com>
wrote:

> Yes I am aware of the name argument. Webrtcbin just happens to be the name
> we're using at the moment, though admittedly it's a poor chase.
>
> There is nothing else in the logs. The error message is what I shared in
> the original email. That's why I asked the list for help; the logs don't
> really provide any info.
>
> And that's with GST_DEBUG set to 3,webrtcbin:9
>
> On Fri, Dec 4, 2020, 2:02 PM Trey Hutcheson <trey.hutcheson at gmail.com>
> wrote:
>
>> I know SDP renegotiation is something that saw lots of improvements from
>> 1.16->1.18, but I'm currently stuck.
>>
>> Here's my workflow:
>> * create webrtcbin instance for peer 1. Initialize with one audio source.
>> Create offer (sdp contains one audio m= line), set-local-description, send
>> to remote peer. Remote peer responds with answer, then
>> set-remote-description.
>> * Create another webrtcbin instance for peer 2. Same workflow. Exchange
>> sdp, with webrtcbin generating the offer.
>> * Media (audio) flows from remote peer 2. Dynamically connect audio
>> (opus, opusdepay then opuspay  to re-payload the rtp) from webrtcbin2 to
>> webrtcbin1.
>> * Ask webrtcbin1 to create a new offer, then set-local-description. Offer
>> now has two audio m= lines. Send offer to remote peer, peer responds with
>> new answer (with two m= lines). set-remote-description on webrtcbin1
>>
>> When I call set-remote-description with the updated answer, webrtcbin
>> complains:
>>
>> ERROR              webrtcbin
>> gstwebrtcbin.c:4320:_set_description_task:<webrtcbin> Not in the correct
>> state (stable) for setting remote answer description
>>
>> And that's because sdp was previously negotiated, and the signalling
>> state had achieved stable. But I want to re-negotiate, and I assumed
>> invoking create-offer a second time (after connecting a new sink pad and
>> verifying caps) would change the signalling state?
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20201207/2eb79a1c/attachment.htm>