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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Trey Hutcheson
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
Reply | Threaded
Open this post in threaded view
|

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

Matthew Waters


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?
>
If you have completed a full SDP negotiation, then the state of
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
Reply | Threaded
Open this post in threaded view
|

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

Trey Hutcheson
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:


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?
>

If you have completed a full SDP negotiation, then the state of
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
Reply | Threaded
Open this post in threaded view
|

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

Matthew Waters
On 5/12/20 7:29 am, Trey Hutcheson wrote:
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:


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.

* create offer
* set-local-description
* (receive answer)
* set-remote-description

This log doesn't contain the failure so is not a useful log.

Cheers
-Matt

On Fri, Dec 4, 2020 at 2:14 PM Matthew Waters <[hidden email]> wrote:


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?
>

If you have completed a full SDP negotiation, then the state of
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
Reply | Threaded
Open this post in threaded view
|

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

Trey Hutcheson
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:
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
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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? 


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel