ICE Failed when trying to connect Janus from outside of LAN.

[Hasan Tekin]

Hi,

Now I modified Janus to be a Websocket client. And I modified Streaming Plugin to use Datachannels. Janus connects to a Websocket Server which works like a relay server.

When I connect Janus (Raspberry Pi 2) from a local PC(Firefox), I get video and datachannel working. But when I try from a remote Pc, Firefox says "ICE failed". 

In webrtc internals it says;

____________________________________________________________________________________________________________________________

Local Candidate                                           Remote Candidate                                       ICE State    Priority

other.clients.LOCAL.ip:49933/udp(host)       janus.LOCAL.ip:50681/udp(host)                          failed    8646913483536859000

other.clients.LOCAL.ip:49933/udp(host)       janus.PUBLIC.ip:50681/udp(serverreflexive)         failed    7205760503266673000

other.clients.PUBLIC.ip:49933/udp(serverreflexive)

SDP

Local SDP

v=0

o=mozilla...THIS_IS_SDPARTA-40.0.3 4294967295 0 IN IP4 0.0.0.0

s=-

t=0 0

a=sendrecv

a=fingerprint:sha-256 67:D6:98:A5:E9:E8:CB:35:DC:12:EE:EB:B7:94:00:6F:08:81:89:F7:02:81:50:50:1F:52:9A:CA:F8:F2:C4:1E

a=group:BUNDLE video data

a=ice-options:trickle

a=msid-semantic:WMS *

m=video 49933 RTP/SAVPF 96

c=IN IP4 other.clients.PUBLIC.ip

a=candidate:0 1 UDP 2128609535 other.clients.LOCAL.ip 49933 typ host

a=candidate:1 1 UDP 1692467199 other.clients.PUBLIC.ip 49933 typ srflx raddr other.clients.LOCAL.ip rport 49933

a=recvonly

a=end-of-candidates

a=fmtp:96 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1

a=ice-pwd:095949f5c2cf0e808beaa2e7d38aaa0c

a=ice-ufrag:d18b64c4

a=mid:video

a=rtcp-fb:96 nack

a=rtcp-fb:96 nack pli

a=rtcp-fb:96 ccm fir

a=rtcp-mux

a=rtpmap:96 H264/90000

a=setup:active

a=ssrc:390419691 cname:{5f705f81-ee37-4739-a743-18f7b2ee8568}

m=application 49933 DTLS/SCTP 5000

c=IN IP4 other.clients.PUBLIC.ip

a=sendrecv

a=ice-pwd:095949f5c2cf0e808beaa2e7d38aaa0c

a=ice-ufrag:d18b64c4

a=mid:data

a=sctpmap:5000 webrtc-datachannel 256

a=setup:active

a=ssrc:2809031533 cname:{5f705f81-ee37-4739-a743-18f7b2ee8568}

Remote SDP

v=0

o=- 4294967295 4294967295 IN IP4 127.0.0.1

s=-

t=0 0

a=sendrecv

a=group:BUNDLE video data

a=msid-semantic:WMS janus

m=video 1 RTP/SAVPF 96

c=IN IP4 janus.LOCAL.ip

a=candidate:1 1 udp 2013266431 janus.LOCAL.ip 50681 typ host

a=candidate:3 1 udp 1677721855 janus.PUBLIC.ip 50681 typ srflx raddr janus.LOCAL.ip rport 50681

a=candidate:1 2 udp 2013266430 janus.LOCAL.ip 38133 typ host

a=candidate:3 2 udp 1677721854 janus.PUBLIC.ip 38133 typ srflx raddr janus.LOCAL.ip rport 38133

a=sendonly

a=fingerprint:sha-256 D2:B9:31:8F:DF:24:D8:0E:ED:D2:EF:25:9E:AF:6F:B8:34:AE:53:9C:E6:F3:8F:F2:64:15:FA:E8:7F:53:2D:38

a=fmtp:96 profile-level-id=42e028;level-asymmetry-allowed=0;packetization-mode=1

a=ice-options:trickle

a=ice-pwd:G9p50eaKvLvGJg+BC7arS8

a=ice-ufrag:JEj1

a=mid:video

a=rtcp-fb:96 nack

a=rtcp-mux

a=rtpmap:96 H264/90000

a=setup:actpass

a=ssrc:3705665206 cname:janusvideo

a=ssrc:3705665206 msid:janus janusv0

a=ssrc:3705665206 mslabel:janus

a=ssrc:3705665206 label:janusv0

m=application 1 DTLS/SCTP 5000

c=IN IP4 janus.LOCAL.ip

a=candidate:2 1 udp 2013266431 janus.LOCAL.ip 49540 typ host

a=candidate:4 1 udp 1677721855 janus.PUBLIC.ip 49540 typ srflx raddr janus.LOCAL.ip rport 49540

a=sendrecv

a=fingerprint:sha-256 D2:B9:31:8F:DF:24:D8:0E:ED:D2:EF:25:9E:AF:6F:B8:34:AE:53:9C:E6:F3:8F:F2:64:15:FA:E8:7F:53:2D:38

a=ice-options:trickle

a=ice-pwd:vZiR7c22jeLmoZA1BDHEK1

a=ice-ufrag:vmG/

a=mid:data

a=sctpmap:5000 webrtc-datachannel 16

a=setup:actpass

____________________________________________________________________________________________________________________________

Before using STUN server, I got this;

Local Candidate                                   Remote Candidate                 ICE State  Priority

remote.LOCAL.Ip:53258/udp(host)           janus.LOCAL.Ip:60560/udp(host) failed        8646913483536859000

remote.PUBLIC.ip:53258/udp(serverreflexive)

I'm using stun.l.google.com:19302 which looks working as Janus can get its public ip address.

Also, after getting this error, Janus says;

[ERR] [ice.c:janus_ice_cb_component_state_changed:1130] [883727694] ICE failed for component 1 in stream 1... No WebRTC media anymore

What do you think is wrong here?

Thanks,

Hasan

[Lorenzo Miniero]

Check this blog post, and happy debugging ;-)

http://www.meetecho.com/blog/understanding-the-janus-admin-api/

L.

[Lorenzo Miniero]

PS: as stated in the group header text, please DON'T post huge bunches of text (e.g., logs) in your messages: if you need to, use a service like gist or pastebin for the purpose.

L.

[Hasan Tekin]

thanks :) Happy debugging is the one that is very very short. I hope I get one.

I'm sorry for long text. I read that note before and forgot apparently.

Hasan

[Hasan Tekin]

Is there a way to set Trickle = false in Janus?

[Lorenzo Miniero]

https://janus.conf.meetecho.com/docs/JS

L.

[Hasan Tekin]

Thanks but nothing helped so far.

There is something that I couldn't debug. When I make a WebRTC call with "streaming plugin", Firefox shows candidates like this;

____________________________________________________________________________________________________________________________

Local Candidate                                            Remote Candidate                                        ICE State     Priority

other.clients.LOCAL.ip:49933/udp(host)        janus.LOCAL.ip:50681/udp(host)                          failed     8646913483536859000

other.clients.LOCAL.ip:49933/udp(host)        janus.PUBLIC.ip:50681/udp(serverreflexive)          failed     7205760503266673000

other.clients.PUBLIC.ip:49933/udp(serverreflexive)

_____________________________________________________________________________________________________________________________

As you can see, it doesn't check for (serverreflexive - serverreflexive) ip pair. So when I try to connect locally, first pair succeed and connects. But when I try from remote Pc out of LAN, first two pair fail and without testing public address pairs, it throws NICE_COMPONENT_STATE_FAILED. And after getting this message, Janus stops everthing about that connection. Is that right to do? I mean, does Libnice throw that error after trying all possible pairs or after checking each pair. If the second one, shouldn't we wait for other fails of other possible pairs?

And is that normal that both sides have only two candidates, one for local, one for public ip(srvrflx)?

Thanks for your patience.

Hasan

[Lorenzo Miniero]

Are you on Amazon/EC2 or something like this? If so, make sure the security group is configured to allow the incoming network connections on the ports WebRTC uses. In those scenarios, STUN is supposed to work, incoming connections are blocked by default. Otherwise you'll have to do some digging with tcpdump/Wireshark to check if there's a filter somewhere (client side or server side).

L.

[Hasan Tekin]

Janus is on my local network. Remote pc is a Virtual Server on Amazon. But I'm able to connect to that virtual server by using apprtc.appspot demo. And my pc and that remote pc can connect without using any relay server.

I'll be digging with Wireshark and let you know.

Thanks,

Hasan

[Hasan Tekin]

I got a solution on this;

The streaming plugin only offers not answer. While playing with apprtc.appspot.com demo, I noticed that if my local browser sends the offer, two peer can only connect to each other via TURN servers. But if remote browser which was an Amazon Virtual Server in my case, sends offer and my local one sends answer, they can connect P2P directly with only using STUN server.

So, I modified "Streaming Plugin" to accept an offer and send an answer back. And now, I tested it with many people from different places and I had successful P2P connection with most of them.

I still don't know why sending offer or answer makes a difference. If someone have an ideaa, pls do not hesitate to share.

Lorenzo, thanks for your helps.

Hasan

[Lorenzo Miniero]

The reason why the plugin always offers is because the characteristics of the media (which comes from an external source) are very specific, and so we want to make sure we only offer what we support. The same thing is done for videoroom viewers, for instance, where the SDP is constrained to what the publisher negotiated in the first place and cannot be changed or adapt.

Not sure why it's not working for you in the other scenario: try digging in the admin API I mentioned above for more insight on what causes the ICE failures.

L.

[Titan Pan]

Hey Hasan,

  I have the same issue that you have. I put Janus behind NAT and port forward the Janus local api port and the Janus web server port.

  I try to access the web server from my remote browser and the Janus log showed "ICE failed".

  What exactly did you to solve this problem? I don't quite understand the solution you gave.

Thanks,

Titan

在 2015年9月23日星期三 UTC+8下午5:28:59，Hasan Tekin写道：

[Lorenzo Miniero]

If Janus is behind a NAT, port forwarding for the signalling is not enough. You need to set a STUN server for media in janus.cfg as well, or otherwise you'll only private addresses as candidates to use and ICE will fail. If you need a limited range of ports to use as you configured it like that in your firewall, you can do that as well in the same configuration file. Read the janus.cfg comments for more details. 

L.

[Titan Pan]

Should I set STUN server both in janus.cfg and javascript API?

Thanks,

Titan

在 2016年9月27日星期二 UTC+8下午4:17:35，Lorenzo Miniero写道：

[Lorenzo Miniero]

It's two completely different things. The STUN you set in JavaScript is for the clients; the STUN in janus.cfg is for Janus itself.

L.

[Titan Pan]

So if the client and janus server are both behind NAT, the STUN server should be both set.

Am I right?

在 2016年9月27日星期二 UTC+8下午5:17:09，Lorenzo Miniero写道：

[Lorenzo Miniero]

Yep. In general you always set a STUN server (and often TURN options too) for clients. For Janus you only need it when Janus itself is behind a NAT, as is your case.

L.

[Titan Pan]

Thanks a lot!

在 2016年9月27日星期二 UTC+8下午5:49:55，Lorenzo Miniero写道：

[Hasan Tekin]

Hi Titan, sorry for way late message. I wasn't working on this for a long time.

Now I learned that value of 'a=setup:' in sdp decides who is gonna initiate the connection. And offerer have to send 'a=setup:actpass' value, so answerer decides who is gonna initiate the call. And apparently most of the time answerer sends 'a=setup:active' value which means answerer is going to connect to offerer first. So, in my case, I believe there was a firewall or something that prohibited access from outside. So, after I modified 'Streaming Plugin' to answer instead of offer(you can see the line "We're always going to do the offer ourselves, never answer"), Janus initiated the connection and problem was solved. These days I'm unable to reproduce the problem, so I can't verify my thesis.

If you could solve your problem and know how you did it, please share with us.

Best,

Tr

[Titan Pan]

I not quite sure what the problem you met is. In my case, I just simply forgot to set up the stun service at the client end.(Because the default google's stun service is unavailable here in China). After I set the stun service correctly, the connections all work fine.

在 2016年11月27日星期日 UTC+8下午11:08:16，Hasan Tekin写道：