I need NAT config for Atalk

[cmeng-git]

I need NAT config for Atalk

MDS

Originally posted by @MAGDIA in https://github.com/cmeng-git/atalk-android/issues/144#issuecomment-732736923

Hello Sir

I referred to the online help for configuring NAT between two different mobile networks (example between the Orange mobile network and Teletel), but without success.

Let me explain : 1 - When two smartphones on two different mobile networks (example between the Orange mobile network and Teletel mobile) are called, communication is established but there is no sound (ZRTP does not turn green) so the correspondents do not get along.

2 - When two smartphones on the same mobile network (eg the Orange mobile network alone) call each other, communication is established and there is sound (ZRTP turns green) so the correspondents get along very well.

To fix the NAT I have tried the STUN Google = stun.l.google.com: 19302 and our own STUN = server2magdia.africa.com:3478 without success.

Always to correct the NAT I also tried some Atalk versions (versions: 1001, 1053, 1062, 1.6.6, 2.3.4, 2.4.1, and the latest = 2.4.3}, but also without success.

In short, the only problem I have with Atalk, this product that I love so much, is correcting the NAT.

I sincerely ask you to help me solve this problem.

If you need two clients (openfire users) to test yourself, let me know.

The version of my Openfire server is 4.2.3.

I also have a question: Which XMPP server does Atalk not have a NAT problem with (i.e. on two different mobile networks, the correspondents get along very well) ?.

Thank you for your prompt reaction

Regards,

MAGDIA

[cmeng-git]

Failed to establish call when the two devices are registered on two different internet service providers

All the network NAT settings are defined in ICE: STUN, TURN, ICE & Jingle for NAT Traversal in media call setup

I too encountered problem when making call between two devices on two different networks. In my case, ice4j failed to establish connection via all the given transport candidates,

2020-11-24 18:21:23.767 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: [fe80::8961:5b15:60cd:e093]:5000/udp/host -> [fe80::f025:b7ff:fe9c:3c5]:5000/udp/host (audio.RTP), failing.
2020-11-24 18:21:23.792 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: [fe80::8961:5b15:60cd:e093]:5000/udp/host -> [fe80::f225:b7ff:fe9c:3c5]:5000/udp/host (audio.RTP), failing.
2020-11-24 18:21:23.815 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 10.135.253.160:5000/udp/host -> 192.168.1.30:5000/udp/host (audio.RTP), failing.
2020-11-24 18:21:23.839 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 10.161.160.121:5000/udp/host -> 192.168.1.30:5000/udp/host (audio.RTP), failing.
2020-11-24 18:21:23.860 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 10.135.253.160:5000/udp/host -> 42.60.7.13:5000/udp/srflx (audio.RTP), failing.
2020-11-24 18:21:23.888 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 10.161.160.121:5000/udp/host -> 42.60.7.13:5000/udp/srflx (audio.RTP), failing.
2020-11-24 18:21:23.891 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() CheckList will failed in a few seconds if no succeeded checks come
2020-11-24 18:21:24.670 16746-22251/org.atalk.android D/AudioTrack: stop(3649): called with 22050 frames delivered
2020-11-24 18:21:25.039 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: [fe80::8961:5b15:60cd:e093]:5001/udp/host -> [fe80::f025:b7ff:fe9c:3c5]:5001/udp/host (video.RTP), failing.
2020-11-24 18:21:25.060 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: [fe80::8961:5b15:60cd:e093]:5001/udp/host -> [fe80::f225:b7ff:fe9c:3c5]:5001/udp/host (video.RTP), failing.
2020-11-24 18:21:25.088 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 10.135.253.160:5001/udp/host -> 192.168.1.30:5001/udp/host (video.RTP), failing.
2020-11-24 18:21:25.110 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 10.161.160.121:5001/udp/host -> 192.168.1.30:5001/udp/host (video.RTP), failing.
2020-11-24 18:21:25.136 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 10.135.253.160:5001/udp/host -> 42.60.7.13:5001/udp/srflx (video.RTP), failing.
2020-11-24 18:21:25.163 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() timeout for pair: 10.161.160.121:5001/udp/host -> 42.60.7.13:5001/udp/srflx (video.RTP), failing.
2020-11-24 18:21:25.165 16746-22288/org.atalk.android I/aTalk: [47207] org.ice4j.ice.ConnectivityCheckClient.log() CheckList will failed in a few seconds if no succeeded checks come

From aTalk history log, I saw that aTalk v2.2.5 is released with an upgrade to ice4j library i.e. Port ice4j-2.0.0-20181024.160538-12 to ice4j-2.0.0-20190607.184546-36 I am not sure if this is the cause of the problem, or the NAT firewall is blocking all the traffic. Need more time to investigate.

Meantime to overcome the problem, you may have to setup a Relay on your server to take care of the problem.

[simobservices]

Hello CM Eng   To allow you a better investigation of our NAT problem, I am sending you two accounts for your tests: 1- UserName = cmeng Password = xxxxxxxx

2- UserName = test2 Password = yyyyyyyy

3- Serverdomain / IP = server2magdia.africa.com / 45.76.61.104  

Mypersonal account is:

• UserName = mdsat2 Password = xxxxxx Contact name = MAG DIALLO

For setting up a relay on our server to fix the problem, how should we do it ?.   I don't know if the relay is the equivalent of STUN / TURN?   Still in relation to the configuration of a relay, I inform you that at the server level there is the following STUN configuration: stun.external.addresses= …… .. stun.xten.net:3478; jivesoftware.com:3478; igniterealtime.org:3478; stun.fwdnet.net:3478; server2magdia.africa.com:3478.   To configure STUN / TURN Server at the ICE level of aTalk we have: STUN = TURN support = no mark IPAddress = server2magdia.africa.com Serverport = 3478

TURN username = none Password= none   STUN /TURN = TURN support = check IPAddress = server2magdia.africa.com Serverport = 3478 TURN username = none

Password= ……… ..

I don't know if this is the correct STUN / TURN configuration.   However if you find it necessary to make diagnostics and modifications on the server, I could send you the server password by SMS / aTalk for security measures.   Also I have a few questions: 1- Why are you using version 2.2.5 instead of the latest version?

2- Will the next version take care of our NAT problem?   Finally I inform you that I am available to become a voluntary aTalk beta-tester if needed. If you have beta versions I can help you test them.   NB: I remain at your disposal for any other useful information, because I really like the aTalk product.   Thank you for your prompt reaction   Regards,   Magloire DIALLO Phone +223 65 73 15 43 Le jeudi 26 novembre 2020 à 02:44:59 UTC+1, Eng ChongMeng notifications@github.com a écrit :

[cmeng-git]

Thank for updating me on your setup and the two test accounts for me to test. Actually I have been spending time to investigate the NAT problem for the last few days. May be I will update you on my finding so far.

Before I go into detail of the NAT test observations, there is another medial call implementation in aTalk that you should be aware of; You may refer to the following aTalk bugs discussion: a. Call compatibility with Conversations #140 b. incoming (audio or video) calls are not appeared if the mobile is in steady state (black locked screen) #150

A media call setup consist of two stages i.e. a. Media call negotiation using Jingle protocol b. Connectivity establishment for transport of media streams.

a. During process a, the call initial and call acceptance are all carried out in this stage via xmpp jingle messages. Once the recipient accepts the call via \, sender aTalk will display "Connected", while the media channel connectivity establishment is still in progress. b. When the media transport channels is successfully established in b, an the media stream is received, only then you will hear the voice.

aTalk media transport implementation uses rtcp-mux, only one transport media channel is used for both the RTCP and RTP in multiplex mode. So during aTalk audio call, only two transport channels are required i.e. outgoing and incoming, instead of 4 channels in non-multiplex mode.

If your receiver client does not support rtcp-mux, then your will see only "connected" display on sender, but there is no audio hear. This is because the recipient does not have enough media channel to send the audio stream.

Note: aTalk has the capability to use non-multiplex mode, but only the non-multiplex client initial the first call. After which, aTalk will remember the client as non-multiplex client, it will then use non-multiplex mode to communicate with the client in all subsequent call; provided you did not exit aTalk.

======================== Below is my test setup environment: a. One of my ISP provider is M mobile network, where my android test device Note-10 is connected to. b. Another one of the ISP is the using the internet S, where my second android device Note-3 and other xmpp clients are connected to.

Test setup: '# M ISP <-> S ISP

1. aTalk <-> aTalk
2. aTalk <-> pidgin
3. Conversations <-> Conversations
4. aTalk <-> jitsi-desktop (2.11.5624)

Note: both pidgin and jitsi-desktop xmpp clients are running on Ubuntu 20.04. The rest are on android devices.

It is found that tests #1, #2 & #3, all call setup failed. All failed with the same reason as reported in my previous comments. However in test #4, the call setup is successful with ZRTP security.

From the debug log, actually the pair also failed in all the transport candidates connectivity test. However it is found that jitsi provides another transport candidate type='prflx' during the connectivity check process as below:

2020-11-28 11:47:46.617 8548-19625/org.atalk.android I/aTalk: [69031] org.ice4j.ice.ConnectivityCheckClient.log() Receive a peer-reflexive candidate: 119.56.98.95:5001/udp. Local ufrag dgg291eo6fdfbj

The whole call setup is successful is because of this prflx candidate. It seems that M ISP has a symmetric NAT that is causing test #1, 2, 3 to fail. See below for more in on prflx https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity#:~:text=A%20peer%20reflexive%20candidate%20is,connection%20verification%20phase%20is%20finished).

I have changed aTalk source to use the same ice4j.jar library as in jitsi desktop (2.11.5624), but test #1 is still not working. This is where I am now, to find out what is the actual root cause.

============================= For setting up a relay on our server to fix the problem, how should we do it ?. I don't know if the relay is the equivalent of STUN / TURN?

Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols

a. Traversal Utilities for NAT (STUN) b. Traversal Using Relay NAT (TURN)

Usually the relay is setup in the TURN (Traversal Using Relay NAT) server. I am not sure if your xmpp server support TURN with relay setup. You need to refer to server manual. If you need to google around to find out how to setup an standalone TURN with relay support.

[cmeng-git]

Finally found the cause of test #1 (aTalk <-> aTalk) failure. It is because the uPnP Harvester in ice4j is not working under android OS. ice4j uPnP Harvester uses org.bitlet.weupnp lib and is not compatible with android.

see Don't work on android #20 I have fixed the problem for aTalk and released a new aTalk version v2.4.4.

Please note that the uPnP Harvester works only when the user device behind a NAT firewall has the router uPnP option enabled. If there is no support for uPnP for devices, you still need the TURN/Relay support to allow call for devices behind NAT firewall.

FYI: Found that ejabberd 20.04 support STUN/TURN. see How to set up ejabberd video & voice calling

Please update me on your test results with aTalk v2.4.4.

[simobservices]

Hello EngChongMeng

  I’m very glad to heard that you havefixed the problem for aTalk and released a new aTalk version v2.4.4. How can I get the new aTalkversion v2.4.4, I don’t see it in the play store after play store update to latest23.0.11-21 [0] [PR] 344295131.

  Can you send me the link please ?   Thank for your quick reply   Sincerely,   MagloireDIALLO   Tel +223 6573 15 43 Le mardi 8 décembre 2020 à 01:36:28 UTC+1, Eng ChongMeng notifications@github.com a écrit :

[cmeng-git]

I have just released the apk into the google play store this morning. However the android development team needs a day or two to review it before they make aTalk accessible to the public.

If you do not want to wait, there is a link you can download the debug version for testing only. https://atalk.sytes.net/releases/atalk-android/aTalk-playstore-debug.apk

However please note that android does not allow inter-mix of an official released apk in google playstore and a debug apk version. You will need to uninstall the current one on android device whenever you switch between the two versions.

[simobservices]

Hello Mr  ChongMeng ok I have understand. Thanks M. DIALLO

Le mardi 8 décembre 2020 à 04:53:14 UTC+1, Eng ChongMeng <notifications@github.com> a écrit :  

I have just released the apk into the google play store this morning. However the android development team needs a day or two to review it before they make aTalk accessible to the public.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[cmeng-git]

Did you manage to upgrade to aTalk v2.4.4? Any update on your test observation with this version.

[cmeng-git]

Please upgrade to use v2.4.5 which now working on android 8 and above:

aTalk v2.4.4 UPnP is not working for android-8.0(O) API-26 and above. Cleartext HTTP traffic not permitted in UPnP gateway getDescription ().

Please update me on your finding.

[simobservices]

Hi

EngChongMeng

 

It’s truethe v2.4.4 version doesn’t work with android 8, as I have done everything withmy two samsung A2 Core having android 8.1.0 without success.

I willtest version 2.4.5 as soon as it is available on the play store and keep youposted on the results of my tests.

 

Regards,

Magloire DIALLO

Phone +223 65 73 15 43

Le vendredi 18 décembre 2020 à 01:11:37 UTC+1, Eng ChongMeng <notifications@github.com> a écrit :  

Please upgrade to use v2.4.5 which now working on android 8 and above:

aTalk v2.4.4 UPnP is not working for android-8.0(O) API-26 and above. Cleartext HTTP traffic not permitted in UPnP gateway getDescription ().

Please update me on your finding.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[cmeng-git]

See my last comment. UPnP uses Cleartext HTTP traffic which is not permitted in android O and above. I have fixed this in aTalk v2 4.5.

[simobservices]

Hello CM Eng

  The version2.4.5 are not working on two different network for the moment. What I have todo please ?   On thesame network it work pretty well.   What haveyou do so it is working for you ?   Thank youfor your prompt reaction   Regards,   Magloire DIALLO   Phone +223 65 73 15 43 Le samedi 19 décembre 2020 à 12:15:27 UTC+1, Eng ChongMeng notifications@github.com a écrit :

See my last comment. UPnP uses Cleartext HTTP traffic which is not permitted in android O and above. I have fixed this in aTalk v2 4.5.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[cmeng-git]

The aTalk v2.4.5 only resolves the UPnP connectivity establishment. For UPnP to work, one of the two clients must be connected to LAN (Intranet), where network connection to external is via the router. Also the router must also have the UPnP feature enabled.

If both the clients are connected via mobile networks under two different services; it is likely that both devices are behind corporate firewalls. Under this case, UPnP support will not work. To allow these two clients to have media call setup, the XMPP server/services must support TURN with Relay. This is the network/firewall constraints. I believe this is what you facing currently.

aTalk supports the user defined TURN with Relay in the ice configuration per user account.

[cmeng-git]

The aTalk v2.4.5 only resolves the UPnP connectivity establishment. For both the clients behind firewalls, user needs to setup the service using TURN with Relay option, and then define these settings in aTalk ICE settings.