<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">And that's with GST_DEBUG set to 3,webrtcbin:9</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 4, 2020, 2:02 PM Trey Hutcheson <<a href="mailto:trey.hutcheson@gmail.com">trey.hutcheson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I know SDP renegotiation is something that saw lots of improvements from 1.16->1.18, but I'm currently stuck. <div><br></div><div>Here's my workflow: </div><div>* 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.</div><div>* Create another webrtcbin instance for peer 2. Same workflow. Exchange sdp, with webrtcbin generating the offer. </div><div>* Media (audio) flows from remote peer 2. Dynamically connect audio (opus, opusdepay then opuspay  to re-payload the rtp) from webrtcbin2 to webrtcbin1. </div><div>* 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</div><div><br></div><div>When I call set-remote-description with the updated answer, webrtcbin complains:</div><div><br></div><div>ERROR              webrtcbin gstwebrtcbin.c:4320:_set_description_task:<webrtcbin> Not in the correct state (stable) for setting remote answer description</div><div><br></div><div>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? </div><div><br></div></div>
</blockquote></div>