simple webrtc connection and manual signaling (QR, JSON, Carrier pigeon) - consent time out prevents connection

[minidogenft]

I thought this would be straight forward but the consent freshness will timeout all connections too fast to allow any realistic manual connection between host and peer (no signaling server but directly providing the offer/answer/candidates through high latency messaging: QR, email, JSON, Carrier pigeon, foot).

I am trying something very simple :

• Open a webrtc connection for a single data channel between 1 host and 1 peer.
• I can use 1 STUN server and nothing else. Signaling must be manual and very high latency. Renegotiating the connection is not needed.

As per developer.mozilla.org documentation on webrtc api, even a carrier pigeon could be used to setup the signaling.

However, it doesn't seem to be possible as soon as we create an answer on the peer side, transport will fail if the host doesn't process it within few seconds:

Step 1- host creates offer for 1 data channel and gather candidates until "complete". Format SDP and candidates into a connection String (or QR) and provide it to peer via high latency manual exchange.

Step 2 - peer process connection string/QR, adds sdp, candidates from host, creates answer and gather candidates until "complete". Format SDP and candidates into a connection String (or QR) and provide it to host via high latency manual exchange. Unfortunately, at this step consent freshness will start and the connectionstatechange will change to failed within a short time frame (seconds) if the host cannot process this info fast enough.

step 3 - host process connection string/QR, adds sdp, candidates from peer. Connection is failed or established if we were fast enough.

I cannot find any way to change the consent freshness timeout. Configuring it doesn't seem to be part of the API.

Is there a solution or special setup that I am missing to make my use case possible (high latency manual signaling)?

Or did the protocol changed in such way since consent freshness that not using a signaling server makes it impossible to establish the p2p connection?

Thanks a lot, I really hope there is a way to solve my problem.

[fippo]

MDN makes weird claims at times...

This is not caused by STUN consent freshness which generally takes place only after the connection is established.

If you do something similar like this on the good old (8 years...) https://github.com/fippo/paste as follows
1/ go to index html, copy offer
2/ go to answer.html, set offer as remote description
the ICE connection will actually get established (thanks to peer-reflexive candidates). But Since the offerer can not verify the DTLS fingerprint it will not respond before getting the actual answer. The answerer will send the DTLS client hello at expontential backoff times which becomes a very large time window and eventually give up (I think after an hour).

But https://webrtchacks.com/the-minimum-viable-sdp/ (2015...) mumbles something about 30 seconds but it doesn't come into effect in this case.

What you might try is the following:
1/ not send any candidates from the offerer
2/ tweaking the DTLS a=setup attribute in the SDP to be "active" instead of "actpass" before setting the offer at the remote end. This means the answerer will become the DTLS server. Might work but will still be brittle.

[juberti]

The issue is that both sides need to perform their ICE checks around the same time. However each side will start their ICE processing when given the first candidate, so if signaling is slower than 10-15 seconds, this is hard to coordinate.

With some NATs, having only the initiator start ICE processing might work (answerer will use triggered checks). But if the NAT requires a pinhole to be created first, that won't fly.

Don't think the DTLS direction will have much effect as the key issue is at the ICE layer, I think.

[minidogenft]

What you might try is the following: 1/ not send any candidates from the offerer 2/ tweaking the DTLS a=setup attribute in the SDP to be "active" instead of "actpass" before setting the offer at the remote end. This means the answerer will become the DTLS server. Might work but will still be brittle.

Thanks, so i tried :
1/ not send any candidates from the offerer
2/ tweaking the DTLS a=setup attribute in the SDP to be "active" instead of "actpass" before setting the offer at the remote end.

No luck, I can't figure how to connect.

Same with this repo: https://github.com/fippo/paste after few seconds delay, the connection state will change to failed.

How can I prevent the answerer to try to connect first and still provide candidates from the host ? Ideally the connection should only start when the host gets its answer back.

Is there no solution but to use a signaling server ?

thanks again