ice failed

[brian....@bdkconsulting.com]

I was so proud of myself for getting a streaming page of janus working.  Alas, that was on a home server.

I basically had (all on the same subnet)  Server (192.168.1.191)   talking to Device (192.168.1.111) talking to Camera (192.168.1.137)

Janus is running on the Server and an rtsp proxy server is running on Device.

Since I dont expect the Server to be on the same subnet as the Device, I create a tunnel in a 10.128.0.0/9 network and the rtsp_url that

the janus server gets is 10.129.4.30 which is the ip address of Device in the 10 network that the Server knows how to route to.

That all worked fine.

Then I moved server to AWS.  In that environment, the server can still talk to Device over the 10 network, but when I ran janus I got ICE failed.

I dont really (yet) know anything about ICE, so I will start looking.  And I have logs, but I suspect I failed to do something very basic and was hoping that someone can shed some light.

The 10 network is only valid on the server on which janus is running.

fwiw, I have nothing set up for nat-1-1 or anything like that either but maybe that is required in this situation; I am creating my own interfaces and necessary routes through my tunnels.

-brian

[brian....@bdkconsulting.com]

Maybe I want to limit ice to localhost since that has all the routing?

[brian....@bdkconsulting.com]

Here is a pastebin of what I hope is the relevant section of the log:

https://pastebin.com/nMQy0y71

One can see many 10.129.x.y (where y is odd) addresses and those are the addresses of the server as seen from the perspective of different devices on the other end of the tunnels.  For any given rtsp_url that I am trying to watch there is a unique device which is serving it.  So I am not sure if I should disable the 10. addresses as ice clients or it is necessary to have them.  If I need them, then I am pretty sure I would need only one for any given watch but I am quite unclear as to how to control that.

thanks much

-brian

[brian....@bdkconsulting.com]

I have read a bit more about ice.  Given my setup where my server has a public ip address and janus is running on that server which can directly reach my device, then I think I should limit the ice candidate to be the public ip address of the server.  (Looking in the sdp, it appears that the default candidate is a local AWS address.)  Is that the right way to think about it?

Is everyone on holiday!?  Usually folks are so responsive.

thanks

[Alessandro Amirante]

Yes, restricting to the server's public IP should be the right thing to do.

And yes, I guess most of the folks is on vacation... At least the Janus team is! :)

A.

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[brian....@bdkconsulting.com]

Allessandro,

Thanks for the feedback, however things are still not working for me.  On one hand, I believe I am very close, on the other hand, maybe I am missing a critical component.

What I am hoping for is some specific suggestions for what variables (nat_1_1_mapping, ice_enforce_list, and anything else I may need).  In most ways, I think my setup is far simpler than most of the other things that this tool can do.

For background, let's assume my server is in AWS and thus has a fixed globally available IP address.  However, it is also the case that I have locked down most all the ports in my current instantiation.  AWS server is at IP 172.31.A.B.  Janus and my web server are running on the AWS server and the AWS server has a point to point connection to each of my devices which are behind some NAT.  Let's assume I have only one device talking to my server.  It is at IP 10.129.4.2 (from the context of the AWS server) and the AWS server is at IP address 10.129.4.1 as well as at its public IP address 173.31.A.B.  All of the ports on the 10.129.x.y network are open.  And then, of course, we have the browser somewhere else.  The rtsp_url that janus uses for streaming is rtsp://10.129.4.1:8554/stream1.

In the above framework, I can get the stream completely set up, but the media data never arrives.  My question is what should the configuration file look like since janus can clearly address everything directly.

I also have a server on my home network which is the same subnet as the device.  That works fine and I assume that is because the ice candidates can all talk directly to each other using local addresses.

My home server can also be addressed with a global IP address (63.X.Y.Z) which is behind my router and forwards only a few ports (80, 443, and one other) to my server.  I think whatever would work for AWS should also work for my home setup.

I am not sure if my problem is ports not being open.  If so, where do I specify the ports that are opened? 

And I am not sure what the ice candidates really want to look like given my setup.

Finally, I dont even think I understand if there is a STUN and/or TURN server running as part of the Janus setup?  Or is this something I need to setup if it is even necessary?  Data could flow on the point to point 10.129. network which is what I thought would happen, but obviously isnt.

Welcome back from holiday janus team!!  And thanks for trying to help this webrtc novice.

-brian

[Lorenzo Miniero]

We're not back from vacation... We just started it. Sorry, won't be able to process your mail and answer until I come back.

Lorenzo

[Alessandro Amirante]

Way too much information to process until we come back from holidays!

A.

Il ven 10 ago 2018, 02:54 <brian....@bdkconsulting.com> ha scritto:

[brian....@bdkconsulting.com]

Thanks much to both of you.  I look forward to your response when you return.

[Lorenzo Miniero]

Only partly back, but a couple of quick points. You only need nat_1_1 on AWS. You mention locking ports: if this affects the ports dynamically allocated for RTP, then ICE is doomed to fail: you can configure the RTP range in janus.cfg as well and map it to your rules.

L.

[Brian Koblenz]

Lorenzo,

Not sure if you are back from vacation or not.  (I am currently on vacation!)

I was hoping the rtp-port-range was exactly what I needed and I believe it was necessary but not sufficient.

My server is in AWS and I opened UDP ports 12250-12750.  (I think this allows up to 250 camera/video pairs, is that right?)

I am not setting 1-1-nat because I am not sure if I need that or not.  The janus command I am issuing on my AWS server (at public address: 34.x.y.z and private address: 172.a.b.c) is:

/opt/janus/bin/janus --daemon --pid-file=/home/ubuntu/Irricloud-server-development/data/janus.pid --apisecret=kPoFCIFvFdA7eyLF --rtp-port-range=12250-12750 --ice-enforce-list=34.x.y.z --log-file=janus.log --debug-level=7

In janus.log I see an ice candidate that references the private 172.a.b.c address but nothing that references the 34.x.y.z public address:

[1625299371842198]   Address:    172.a.b.c:12660

[1625299371842198]   Priority:   2013266424

[1625299371842198]   Foundation: 8

[1625299371842198]     8 1 udp 2013266424 172.31.31.4 12660 typ host

Later on I get an ICE failure.  I suspected that may be because I am failing due to set 1-1-nat to 34.x.y.z?  I did that and the streaming now seems to function properly.

I guess I am confused as to what is the meaning of the ice-enforce-list as it relates to 1-1-nat?   I thought by setting --ice-enforce-list I was forcing the appropriate ice candidate.

Should I not be setting --ice-enforce-list?

On my home environment where my externally visible router port forwards the relevant ports to a local server, would I also configure it like a 1-1-nat?

On Tue, Aug 21, 2018 at 1:35 AM, Lorenzo Miniero <lmin...@gmail.com> wrote:

Only partly back, but a couple of quick points. You only need nat_1_1 on AWS. You mention locking ports: if this affects the ports dynamically allocated for RTP, then ICE is doomed to fail: you can configure the RTP range in janus.cfg as well and map it to your rules.

L.

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.

[Lorenzo Miniero]

On AWS you do need the nat-1-1, as otherwise the SDP contains the private address (the one Janus is aware of) instead of the public IP you assigned, and so will cause ICE to fail. Forcing or filtering interfaces simply means that some interfaces may or may not be used for gathering, but again, when gathering is done, for host candidates Janus will only be aware of the locally available IPs, which on AWS are private.

Lorenzo