I am just experimenting with my phone system and I'm wondering how both endpoints know they are on the same LAN, I have both endpoints breaking out to the cloud phone system with two separate public IP addresses, I've segmented them off from each other with a firewall so they can't see each other however every time I attempt a call between the two end points the call is setup as a peer to peer call and attempts to traverse the local LAN via RTP through the firewall, the firewall blocks the RTP communication and the call has no audio.
I am just wondering how both endpoints are realizing they are behind the same firewall/router since they are both registering with the cloud system from different public IP addresses, I wanted the call to be bridged in the cloud and not traverse the local LAN but somehow both endpoints only attempt the call over the LAN every single time and no idea how they're realising they're on the same LAN.
Anyone else encountered this before?
SIP endpoints don't have to know they are on the same LAN. They just make best use of the IP addresses you provide.
Your INVITE request will provide more insight, but from what you write my guess is that you use public IP addresses for your contact/request URI and local IP addresses in your SDP offer. The local IP addresses are probably routable through the firewall.
With ICE and STUN endpoints may select the best IPs for media traffic - but for that to work the RTP/STUN packets should be able to traverse the firewall in your LAN.
Attempts to communicate directly may mean that LAN uses IPs from public ranges or endpoints a SIP proxy were not smart enough to detect NAT in front of your LAN.
Related
I am working on an embedded software product that runs on an Ubuntu edge computer with multiple network ports.
The software allows the user to change the IP address of the ports via a locally hosted web interface.
In the scenario that a customer changed an IP on one of our devices, but then forgets their setting I am looking for an easy strategy to walk them through detecting the IP.
Ideally this tool would be usable by non-sophisticated customers (we don’t want to walk them through using Wireshark or command line tools).
Is there a service we can setup on our machine that will broadcast its identity across subnets using another protocol like UDP or EtherNet/IP? Then a simple tool the client could install on their computer to ‘scan’ for our devices?
The edge computers also have USB ports if it is easier to broadcast an identify there.
Changing a local IP address to something invalid (=not compatible with its local subnet) generally disables all L3 communication. Limited broadcasts (to 255.255.255.255) still work, but answering to them by unicast most likely won't. The same goes for multicasting - but you could use that for discovery both ways.
Also, the common link-level discovery protocols (like LLDP or CDP) still work since they don't rely on IP.
However, all that is limited to the connected L2 segment at most. Discovery across subnets isn't possible without some kind of infrastructure (discovery sensors, central server, multicast routing, ...). A reasonable way would be dynamic DNS but then again, that requires IP to work.
I think you'd need to take a step back and reevaluate your design. One way would be to verify a user's reconfiguration before it becomes permanent. For instance, you could have a user change the IP setup and then forward the session to the new IP address. If the session isn't continued within five minutes or so on the new address, it reverses to the previous config.
Additionally, some kind of out-of-band management could be useful.
I am developing a custom Alexa Skill and have a requirement where I want Alexa to access REST APIs that are hosted locally on http://localhost:8080? Any idea how to do this?
Thanks!
If you really want to do this, and I’m assuming you are hosting the skill on AWS Lambda, it would involve quite a bit of work.
Your local endpoints need to be accessible from outside of your network, which requires port forwarding in your router to your machine where the endpoints are hosted. This needs to be configured in your router.
An easier way is to deploy your project containing the API to something like Heroku, which can be done easily. They give you a domain and make the endpoints accessible to Lambda. This should be possible within their free tier.
Here' a link to a pretty good article about how IP addresses work.
Allowing a device sitting on your local network (eg. a laptop computer or Raspberry Pi connected to your wifi) to be accessed from outside your local network (eg. from a service running on AWS) will involve mapping 2 separate IP addresses:
The IP address assigned to your router (your public IP)
The private IP addresses assigned by your router to your devices (laptop, iPhone, RPi, etc).
You have a couple options for allowing your router's IP (#1) to be accessible from outside your local network:
a. Pay your internet provider to provide you with a static IP address
b. Use a dynamic DNS service such as DuckDNS or No-IP.
Once you have a fixed public IP that can be used to access your router, you will then need to map a port on your router (#1) to the device IP on your local network (#2). This is usually referred to as "port forwarding". Most routers will support configuring this. In effect, your tell your router "when you get a message to : pass it to my laptop :"
Your local private IP address will typically have an IP value like 192.168.0.23 (where the 23 can be anything from 1 to 254).
An outside IP will start with something other than 192. Refer to the first link above regarding IP ranges.
You can google "port forwarding" and "public IP" for more info on how IP addresses and port forwarding work, but hopefully this will help get you started. It may seem a bit complicated at first, but if I can understand it, then anyone can :-)
In UPnP IGD there is 2 services "WANPPPConnection" (or WanIPConnection) and WANIPv6FirewallControl that have methods that look similar:
AddPinhole
Add(Any)PortMapping
Both taking similar arguments (remote/internal host/port, protocol, lease time).
I was wondering, what is the difference between them ? FW control is apparently exclusive to IPv6 while PortMapping seems to allow both v4 and v6, so what is the real difference ? Is there a different behavior ?
A (typical) IPv4 firewall, embedded in an Internet router, has a single IPv4 address on the Internet, on its WAN interface. Devices on the LAN behind it typically use private range addresses. This means that they are not reachable from the Internet.
If a service on a device must be reachable from the Internet, the router must be instructed to forward incoming traffic from one of its ports on its WAN interface, to a port on the LAN device. This is called a "port forwarding," using the NAPT (Network Address and Port Translation) feature of the router.
On IPv6, routers are not provided with a single address on the WAN interface, but a whole prefix. Devices on the LAN all have publicly routeable addresses. There is no need for address and port translation on the router.
The firewall in the router, however, may be configured to block all incoming connections. In this case, the router's firewall must be instructed to pass through traffic to certain ports on certain protocols to certain LAN addresses. This is called a "pinhole" in the UPnP-IGD standard.
I have a question about network connections among computers.
I've made some applications where messages pass through the Internet (via sockets) to make a connection between two devices. However, a strong condition is that two devices must be connected to the same network.
Can anyone give me a trick how to create a communication using sockets between two computers even if they are connected to different netwkorks?
Thank you in advance.
Here is a great tutorial on how to use sockets and general networking
(in java) http://www.thenewboston.org/watch.php?cat=25&number=38
In order to communicate between two diffrent networks over the internet, you will need to do something called port forwarding. What that does is that when your public IP of your network receives a packet with a spesific port number. The router knows where to send that packet to which local IP.
If you dont port forward and receive some data. The router doesent know where to send the packet. Therefore it discards it, which means others wont be able to connect to you.
You will only need to port forward the network with your server (using the example i linked). How you do that is by logging in to your router, and say that a port which the server uses gets forwarded to the IP of the PC hosting the server.
On the other network (client) you will need to change the IP address of which the client shall connect to. That IP address needs to be your public IP of your server's network. You can find that by connecting to the server's network and go to: http://www.whatsmyip.org/ . Keep in mind that public IP addresses may change over time.
Hope this helped!
-Kad
Once a service is discovered through DNS-SD, how exactly does the address of that host get resolved, and does it take significantly more time/overhead?
Also, if I am using JmDNS or Bonjour there are call-backs for both serviceFound and serviceResolved. If I am just interested in the IP address of the device publishing a certain service, is there a faster/more efficient way of getting the address than going through both serviceFound and serviceResolved?
Thanks
DNS-SD uses Multicast DNS (MDNS) which works by sending DNS packets over UDP to a certain multicast address. All mdns-capable hosts in the network also listen to this address. It uses UDP so, it's quite low overhead. Also, the clients are designed in a way that the amount of chatter on the network is kept to a minimum, by using extensive caching.
Service discovery is a two step process. The first step is finding the names of all hosts providing a certain service (e.g. printing). This will not yet give you the ip address, instead it gives you the mdns name (ending with .local). This is because the ip could possibly change, whereas the name will not.
The second step in service discovery is to resolve the .local name of the host over mdns. You ask via multicast who foo.local is, foo.local will see that packet, and respond via broadcast with its ip address, port number and other information.