4

I'm looking for a solution to exchange information using (UDP or TCP) between ** NAT ** separated android terminals or nodes, let's assume A and B are two android clients.

I am working on a " remote VoIP application " in which clients are directly communicating with each other.

For the implementation of STUN Server and NAT Traversal, I used an open-source STUN server software namely STUNTMAN.

On the client-side, In order to obtain Public IP: PORT from STUNTMAN, I have integrated an open-source stun-client as "JSTUN" which is a Java-based STUN client.

At Client-A, the example results from ** STUNTMAN Server ** are like;

stunclient --mode full --localport 9999 stunserver.stunprotocol.org
Binding test: success
Local address: 192.168.1.8:9999
Mapped address: 1.2.3.4:9999
Behavior test: success
Nat behavior: Endpoint Independent Mapping
Filtering test: success
Nat filtering: Address and Port Dependent Filtering

To make Peer-to-Peer communication between Android Clients, I have maintained a signaling server which is accurately sharing Mapped Addresses between Clients A & B.

But, when I tried to start Peer-to-Peer communication using UDP or TCP sockets, there was no such communication between them.

I have also tried this solution on StackOverflow as confusion-about-stun-server and android-iOS-peer-to-peer-arhitechture. I am unable to understand where am I doing wrong?

  • Is there any possibility to maintain P2P communication for VoIP?

  • Is there any VoIP application having a P2P feature? (Initially, Skype was based on peer-to-peer architecture)

What I need is a programmatic example, not a theory based answer.

selbie
  • 100,020
  • 15
  • 103
  • 173
Muhammad Usman Bashir
  • 1,441
  • 2
  • 14
  • 43
  • 1
    It doesn't sound like you are doing the hole punching step. [See my answer here](https://stackoverflow.com/a/8524609/104458) – selbie Oct 23 '19 at 21:07
  • 2
    @selbie , I think you're saying about to "punch a hole" like **UDP or TCP Hole Punching**, in which each client connects to an unrestricted third-party server that temporarily stores external and internal address and port information for each client. Then this server relays or share each client information to other? – Muhammad Usman Bashir Oct 23 '19 at 22:28
  • 1
    Your *signaling service* which could be SIP, a web server, or anything facilitates the exchange of IP addresses and ports. Then the hole punching step tries repeatedly to ping the other address until it responds back. This is importantly because the first packet will fail to reach the target device, but it enables incoming packets to go through. – selbie Oct 24 '19 at 04:24
  • 1
    @selbie As he has stated the sip signaling is done manually so no need for signaling for now, what the question is that after even the signaling is done. When the data gram socket is tried on any ip:port it won't connect. I'm working with him and this is all about it. The signaling is not an issue the connectivity issue is there. Even on the same router cannot connect to IP:Port returned by the stun server. – Saif Ali Oct 24 '19 at 13:49
  • 3
    If you are behind the same router, then you need to fallback to using local candidate addresses instead of the external candidates address provided by STUN. Because many (perhaps most) routers do not support hairpinning (an internal node accessing its own external IP address). The ICE methodology addresses all of this. – selbie Oct 24 '19 at 17:55
  • 1
    @selbie Lets assume, i want to have a one-to-one communication between two clients **A and B**. Both are connected with different routers. I have obtain three types of candidate Addresses of ICE for A and B which are **"Host", "Relay" and "Server Reflex"** candidate Addresses. All i have to integrate ICE Server for TURN and STUN usage ? – Muhammad Usman Bashir Oct 24 '19 at 18:12
  • 3
    There's no such thing as an ICE server. There are STUN servers, TURN servers, and your signaling service. Your signaling service can certainly be used for address exchange and to coordinate the start/stop of hole punching. But you'll need client code to do the ICE methodology of repeatedly trying connection establishment. – selbie Oct 24 '19 at 21:07
  • 3
    @selbie Thanks for your valuable time you taken to respond to our thread. We have implemented signaling and STUN server. UDP hole punching is done data is also being traversed between Full Cone Clients. Now need help managing sessions. – Saif Ali Oct 26 '19 at 12:04

0 Answers0