Communicating with both internal and external users about janus-gateway HOT 13 CLOSED

Also, I am using Debian Jessie as my OS and it is x86.

Another tidbit, I see the stun Bind requests being sent the machine requesting the Echo test but there is no success reply...It seems that the reply, even through it is an internal session is trying to go to the public IP address instead of the local one.

Meaning, the Binding Request originates from the internal IP but Chrome tries to respond to the public IP even though they are behind the same NAT...Interesting....

from janus-gateway.

Well, it works great if I turn off it being behind a NAT...Is there a way for it to communicate with machines behind the same NAT and to ones outside its NAT?

I am gonna start digging around. Let me know if you guys find anything first.

from janus-gateway.

Is the gateway deployed behind a NAT? If so, you need to either specify a public IP to be used in negotiations (assuming the same ports are going to be used locally and on the NAT) or configure the gateway to use a STUN server as well. Both things can be done via command line and configuration.

from janus-gateway.

The STUN solution is probably the way to go to cover users both within and outside the NAT.

from janus-gateway.

Yes, it is deployed behind a NAT and I have the issue only when I do use a STUN server and try to access from behind the same NAT. I will try a different STUN server than googles public one to see if that helps.

Here is my current config for nat

[nat]
;public_ip = 1.2.3.4
stun_server = stun.l.google.com
stun_port = 19302

from janus-gateway.

No dice, tried with stun.ekiga.net, stun.iptel.org, numb.viagenie.ca and still getting the same ICE failed error.

from janus-gateway.

Sorry, traveling now, will look into that as soon as I get back home.
Il 25/lug/2014 13:39 "Computician" [email protected] ha scritto:

No dice, tried with stun.ekiga.net, stun.iptel.org, numb.viagenie.ca and
still getting the same ICE failed error.

—
Reply to this email directly or view it on GitHub
#46 (comment)
.

from janus-gateway.

Safe travels! I will continue digging myself.

from janus-gateway.

The issue may be that, when specifying a STUN server, the public_ip variable is set, that in turn replaces the host addresses with its value, which is obviously wrong. It should only overwrite it when the public IP is specified as part of the configuration, and not when retrieved via STUN.

Can you try commenting this line:
https://github.com/meetecho/janus-gateway/blob/master/ice.c#L194
and see if that works for you?

from janus-gateway.

PS: And this one as well:
https://github.com/meetecho/janus-gateway/blob/master/ice.c#L187

from janus-gateway.

That worked for internal sessions! I have not tested yet with external IPs yet(meaning clients behind a different NAT.

from janus-gateway.

Good! If you configured a STUN server, it should work for external users as well, through the srflx candidates. Let me know if that fixes it and I'll push the fix as soon as I do the same for a couple of other bugs I'm working on.

from janus-gateway.

Yes, external still works with that change! Thank you very much

from janus-gateway.