ICE Restart on recvonly peerconnection

[francesco....@bandyer.com]

Hi guys,

We have recently implemented ICE Restart mechanism in Licode SFU but it doesn't work as expected.

What you need to know is that for every single mediastream licode generate a new peerconnection.

So the test is done with one publisher, publishing to licode thru a peerconnection (sendonly) and a subscriber, subscribing thru licode with another peerconnection (recvonly).

Licode uses the current master of libnice where ICE restart is implemented.

If we make a restart from the publisher, everything works just fine. In chrome://webrtc-internals we can see the peerconnection changing udp port and if we block all udp traffic, we can see it switching from stun to relay.

So the publisher works flawlessly but when we do the same restart on the subscriber, the video freezes.

It switch candidate and udp port as well and the audio never stop working but the video freezes. (note that this happens in Chrome but also in Firefox, same behavior).

The weird thing is that in chrome://internals everything is going well. the decoded frames increase, the bitrate is correct and if I switch resolution from the publisher (ex. during a simulcast test), I can see the receiver decoded width and height acting accordingly.

We tried different things such as send a keyframe from the publisher on ice restart complete but nothing seems able to make the video works again.

Is there any suggestion you can give to me?

Have a nice day!

[Lorenzo Miniero]

Hi Francesco,

I've worked on ICE restarts in Janus as well some time ago (still WIP in a pull request that you can find here: https://github.com/meetecho/janus-gateway/pull/753) and, since IIRC the Licode SFU works pretty much as our VideoRoom, I thought I'd share how we did that.

Basically, the approach we took was to respect the original roles as offerer/answerer. Publishers always offer, and so they're free to originate an ICE restart via a new offer themselves. Since for subscribers we always originate an offer from the server, instead, we do the same for ICE restarts: the client sends an ad-hoc request to the server, and the server reacts by originating a new offer with ICE restart info. This approach seems to work fine in all our plugins, where depending on the scenario or the context we have clients ask for an ICE restart either via SDP (new offer), or via ad hoc request (offer + ICE restart from the server) pretty much as it works in the VideoRoom.

Not sure this answers your question but I hope it helps.

Lorenzo

[francesco....@bandyer.com]

Apparently I was handling in a wrong way the new onAddStream event.

Everything's fine

Il giorno martedì 31 ottobre 2017 16:53:37 UTC+1, francesco....@bandyer.com ha scritto: