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? _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On 5/12/20 7:02 am, Trey Hutcheson 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? > webrtcbin will be 'stable'. This specific line: 'Not in the correct state (stable) for setting remote answer description' probably means that you didn't actually 'set-local-description' on this webrtcbin instance (or you're confusing which webrtcbin instance you're calling against). Calling 'create-offer' does not change any of the state properties. They are only changed with the 'set-*-description' calls as specified in the JSEP specification. Cheers -Matt _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel OpenPGP_signature (505 bytes) Download Attachment |
Wow, thanks for the quick reply. However, I can assure you that I am setting the offer on the correct instance. Excerpt of actual code (rust; it emits the create-offer signal, and in the promise, takes the offer and uses it via set-local-description): let promise = gst::Promise::with_change_func(move |reply| { let webrtcbin = match webrtc_ref.upgrade() { Some(w) => w, _ => return, }; match reply { Ok(Some(reply)) => { let offer = reply .get_value("offer") .unwrap() .get::<gst_webrtc::WebRTCSessionDescription>() .expect("Invalid argument") .unwrap(); let raw_offer = offer.get_sdp().as_text().unwrap(); info!( "Setting renegotiated offer for {}/{}: {}", session_id, epid, raw_offer ); webrtcbin .emit("set-local-description", &[&offer, &None::<gst::Promise>]) .unwrap(); if tx.send(Ok(raw_offer)).is_err() { error!("Could not send offer to receiving channel"); } } _ => { if tx.send(Err(anyhow!("Could not generate offer."))).is_err() { error!("Could not send error to receiving channel."); } } }; }); webrtcbin .emit("create-offer", &[&None::<gst::Structure>, &promise]) .unwrap(); And actual log messages: 2020-12-04T14:20:17.185953907-06:00 [unnamed][src/gstlib_webrtc.rs:568] - Setting renegotiated offer for b41be2aa-40db-4e5b-981e-8f78cbf7dc5e/ep1: v=0 ... 0:00:13.224684399 93456 0x7fffb400c6a0 INFO webrtcbin gstwebrtcbin.c:4311:_set_description_task:<webrtcbin> Attempting to set local offer in the stable state 0:00:13.224699818 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:4313:_set_description_task:<webrtcbin> SDP contents v=0 ... 0:00:13.224759621 93456 0x7fffb400c6a0 DEBUG webrtcbin gstwebrtcbin.c:4478:_set_description_task:<webrtcbin> we are in ice controlling mode: true 0:00:13.224770732 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:507:_find_transport_for_session:<webrtcbin> Found transport <transportstream0> for session 0 0:00:13.224844291 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:507:_find_transport_for_session:<webrtcbin> Found transport <transportstream0> for session 0 0:00:13.224910856 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:4639:_set_description_task:<webrtcbin> notify signaling-state from have-local-offer to have-local-offer ... ... 0:00:13.354347283 93456 0x7fffb400c6a0 INFO webrtcbin gstwebrtcbin.c:4311:_set_description_task:<webrtcbin> Attempting to set remote answer in the have-local-offer state 0:00:13.354358154 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:4313:_set_description_task:<webrtcbin> SDP contents 0:00:13.354396677 93456 0x7fffb400c6a0 DEBUG webrtcbin gstwebrtcbin.c:4478:_set_description_task:<webrtcbin> we are in ice controlling mode: true 0:00:13.354405533 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:507:_find_transport_for_session:<webrtcbin> Found transport <transportstream0> for session 0 0:00:13.354466028 93456 0x7fffb400c6a0 DEBUG webrtcbin gstwebrtcbin.c:3718:_update_transport_ptmap_from_media:<webrtcbin> mapping sdp session level attributes to caps 0:00:13.354473852 93456 0x7fffb400c6a0 DEBUG webrtcbin gstwebrtcbin.c:3720:_update_transport_ptmap_from_media:<webrtcbin> mapping sdp media level attributes to caps 0:00:13.354484603 93456 0x7fffb400c6a0 DEBUG webrtcbin gstwebrtcbin.c:3733:_update_transport_ptmap_from_media:<webrtcbin> looking at 0 pt: 111 0:00:13.354504270 93456 0x7fffb400c6a0 DEBUG webrtcbin gstwebrtcbin.c:3718:_update_transport_ptmap_from_media:<webrtcbin> mapping sdp session level attributes to caps 0:00:13.354508387 93456 0x7fffb400c6a0 DEBUG webrtcbin gstwebrtcbin.c:3720:_update_transport_ptmap_from_media:<webrtcbin> mapping sdp media level attributes to caps 0:00:13.354515601 93456 0x7fffb400c6a0 DEBUG webrtcbin gstwebrtcbin.c:3733:_update_transport_ptmap_from_media:<webrtcbin> looking at 0 pt: 111 0:00:13.354526882 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:507:_find_transport_for_session:<webrtcbin> Found transport <transportstream0> for session 0 0:00:13.354531281 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:3438:_find_transceiver_for_sdp_media:<webrtcbin> Found transceiver <webrtctransceiver0> 0:00:13.354535188 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:507:_find_transport_for_session:<webrtcbin> Found transport <transportstream0> for session 0 0:00:13.354586475 93456 0x7fffb400c6a0 LOG webrtcbin gstwebrtcbin.c:3863:_update_transceiver_from_sdp_media:<webrtcbin> marking stream 0x7fffbc04cb30 as active 0:00:13.354612033 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:3438:_find_transceiver_for_sdp_media:<webrtcbin> Found transceiver <webrtctransceiver3> 0:00:13.354615970 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:507:_find_transport_for_session:<webrtcbin> Found transport <transportstream0> for session 0 0:00:13.354648762 93456 0x7fffb400c6a0 LOG webrtcbin gstwebrtcbin.c:3863:_update_transceiver_from_sdp_media:<webrtcbin> marking stream 0x7fffbc04cb30 as active 0:00:13.354653852 93456 0x7fffb400c6a0 DEBUG webrtcbin gstwebrtcbin.c:3878:_update_transceiver_from_sdp_media:<webrtcbin> transceiver <webrtctransceiver3> direction change from none to sendonly 0:00:13.354658451 93456 0x7fffb400c6a0 DEBUG webrtcbin gstwebrtcbin.c:3911:_update_transceiver_from_sdp_media:<webrtcbin> found existing send pad <webrtcbin:sink_1> for transceiver <webrtctransceiver3> 0:00:13.354668630 93456 0x7fffb400c6a0 LOG webrtcbin gstwebrtcbin.c:4532:_set_description_task:<webrtcbin:sink_1> Connecting input stream to rtpbin with transceiver <webrtctransceiver3> and caps application/x-rtp, media=(string)audio, clock-rate=(int)48000, encoding-name=(string)OPUS, payload=(int)111, encoding-params=(string)2, ssrc=(uint)1462191880, timestamp-offset=(uint)573074706, seqnum-offset=(uint)19451 0:00:13.354672998 93456 0x7fffb400c6a0 INFO webrtcbin gstwebrtcbin.c:3482:_connect_input_stream:<webrtcbin:sink_1> linking input stream 1 0:00:13.354739644 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:507:_find_transport_for_session:<webrtcbin> Found transport <transportstream0> for session 0 0:00:13.354781844 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:507:_find_transport_for_session:<webrtcbin> Found transport <transportstream0> for session 0 0:00:13.354817250 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:393:_find_ice_stream_for_session:<webrtcbin> Found ice stream id <webrtcicestream0> for session 0 0:00:13.354822230 93456 0x7fffb400c6a0 LOG webrtcbin gstwebrtcbin.c:3627:_add_ice_candidates_from_sdp:<webrtcbin> adding ICE candidate with mline:0, a=candidate:3885250869 1 UDP 2122260223 172.17.0.1 47390 typ host generation 0 network-id 1 0:00:13.354835575 93456 0x7fffb400c6a0 LOG webrtcbin gstwebrtcbin.c:3627:_add_ice_candidates_from_sdp:<webrtcbin> adding ICE candidate with mline:0, a=candidate:3719404024 1 UDP 2122194687 192.168.0.91 47330 typ host generation 0 network-cost 10 network-id 2 0:00:13.354843510 93456 0x7fffb400c6a0 TRACE webrtcbin gstwebrtcbin.c:4639:_set_description_task:<webrtcbin> notify signaling-state from stable to stable 0:00:13.354849862 93456 0x7fffb400c6a0 LOG webrtcbin gstwebrtcbin.c:1341:_check_if_negotiation_is_needed:<webrtcbin> checking if negotiation is needed 0:00:13.354851695 93456 0x7fff1000d2a0 DEBUG webrtcbin gstwebrtcbin.c:277:gst_webrtcbin_sink_event:<webrtcbin> On <webrtcbin:sink_1> checking negotiation? 1, caps application/x-rtp, media=(string)audio, clock-rate=(int)48000, encoding-name=(string)OPUS, payload=(int)111, encoding-params=(string)2, seqnum-offset=(uint)19451, timestamp-offset=(uint)573074706, ssrc=(uint)1462191880 0:00:13.354855112 93456 0x7fffb400c6a0 LOG webrtcbin gstwebrtcbin.c:1491:_check_if_negotiation_is_needed:<webrtcbin> no negotiation needed 0:00:13.354865982 93456 0x7fffa00f74c0 INFO webrtcbin gstwebrtcbin.c:5618:on_rtpbin_new_sender_ssrc:<webrtcbin> session 0 ssrc 1462191880 new sender ssrc 0:00:13.354889787 93456 0x7fff1000d2a0 LOG webrtcbin gstwebrtcbin.c:1341:_check_if_negotiation_is_needed:<webrtcbin> checking if negotiation is needed 0:00:13.354916548 93456 0x7fff1000d2a0 LOG webrtcbin gstwebrtcbin.c:1491:_check_if_negotiation_is_needed:<webrtcbin> no negotiation needed It's difficult to discern messages from one webrtcbin instance to another. But the code is following the same flow through renegotiation as the original negotiation: * create offer * set-local-description * (receive answer) * set-remote-description On Fri, Dec 4, 2020 at 2:14 PM Matthew Waters <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On 5/12/20 7:29 am, Trey Hutcheson wrote:
If you give your webrtcin elements different names (which is the default if you pass None the gst::ElementFactory::make) then, it is much easier to see which webrtcbin is which.
This log doesn't contain the failure so is not a useful log. Cheers -Matt
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel OpenPGP_signature (505 bytes) Download Attachment |
In reply to this post by Trey Hutcheson
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 <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |