Frequently Ask Question (FAQ)

This FAQ section is created to provide a better understanding to aTalk users on the application features and observed behavior. This section will continuously be updated as more inputs are feedback from aTalk users.

Account Setup & Login

Enhanced Features

OMEMO Messaging

OTR Messaging

Media Call Communications

User Avatar


Account Setup & Login
Does aTalk communicate with all the available xmpp clients in the market? { Content }
By definition, if an xmpp client implementation follows XMPP standards as defined in XEP's spefications, then it should be able to work with aTalk. A list of all the XEP's supported by aTalk can be viewed in the About dialog box on your installed device or the site: atalk-android
aTalk has been verified to work with the following xmpp clients e.g.
[20181006] What information to enter in "Override server setting" when I setup a new account? { Content }
In today advance technology, a physical xmpp machine can actually support multiple virtual domain services/hosts. This service name is usually tag with the user xmpp account e.g. where is usually referred to as service domain or virtual host.
If you leave the Override server setting option unchecked, aTalk first needs to ensure the specified service domain name is reachable; it searches for the actual internet ip address on a Domain Name Server (DNS). On success, aTalk then proceeds to lookup the SRV record from the server which contains the required ip:port network information for connection. Connection attempt wil fail if neither of the following conditions is met, and you will need to enable the Override server setting option:
In the first case, you need to specify the actual physical domain name, Fully Qualified Domain Name (FQDN) where the xmpp service reside.
For the second case, you need to copy the service/domain name into the server setting i.e. Connect Server IP field, so aTalk will not look for SRV record on service domain host/server, instead falls back to use the Connect Server IP resolved internet address for connection.
Note: You may enter either a FQDN hostname or an IP address e.g. in the Connect Server IP field. The user account name cannot contain IP address, use Connect Server IP instead to specify the IP address if the service domain name is not listed in DNS.
[20180818] SSL Certificate Authentication, DNSSEC and DANE Security Implementation for Connection Establishment { Content }
aTalk supports the following connection establishment security mode. Please note that both DNSSEC and DANE implementations are still at expermental implementation by miniDNS/smack/aTalk. DNSSEC does not work on server with a self-signed certificate or certificate signed by untrusted root CA's. You may refer to android Seurity Settings for a list of trusted CA certificates.
Plese refer to the following sites for more information:
Do I have to enable IB Registration option when I setup a new account? { Content }
"IB Registration" stands for "In-Band Registration" and is defined in XEP-0077 standard. In general, if an account already has been created and assigned to you by your server administrator, you do not need to enable IBR option during account setup. This is usually not true if you want to register an account on an online free xmpp server. Some server needs you to create an account via their web interface before you can setup the account on your xmpp client. If the server supports IBR, then you can create and register a new user account from within aTalk in one single step. When you setup an account with IBR enabled, aTalk does a pre-check whether the account exist on the server, and proceed with the IBR only if the login failed with exception <not-authorized/>.
A few points to note when doing IBR registration as most server has the following rules set:
Google Talk account setup { Content }
To setup a Google Talk account on aTalk, follow the steps below
Note: Google server has its own xmpp implementation which may deviate from the standard XEP standards. You may found that certain features are not supported e.g. Omemo messaging. You can actually send chat messages to another Google account login using Hangouts.
Why my first login in sometimes fails when a new account is created? { Content }
Most of the servers today have installed a ssl certificate on their site. The certificate usually are signed with the private key of a trusted certificate authority. The certificate contains the domain name and/or ip address of the server. When you visit the site, this certificate is fetched and compared against the public keys of all the major certificate authorities; and confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection.
When you setup an account with a new server, aTalk downloads the site certificate and compares against its database. It prompts for manual confirmation if the certificate is new. If you take some time to confirm the certificate before proceed, the server hold time may have expired and the established connection gets disconnected. This is the reason why you need to login a second time.

Enhanced Features
Adding Contact { Content }
In order to protect the privacy of XMPP users, presence information is disclosed only to other entities that a user has approved. When a user has agreed that another entity is allowed to view its presence, the entity is said to have a "subscription" to the user's presence. An entity that has a subscription to a user's presence or to which a user has a presence subscription is called a "contact".
When you add a buddy to your contact list, aTalk actually makes a subscription request to your buddy for his/her approval. In this process, your hosted server routes your subscription request locally if the buddy is on same server; otherwise remotely with connection made to the buddy hosted server via IP derived from your buddy account service name i.e. from "". If the Fully Qualified Domain Name (DQDN) of your buddy hosted server cannot be derived from his JID account service name, the subscription request process will fail. With the current XMPP standard defined for Presence Subscription, it is therefore not possible to include buddy whom resides on a different server where his/her account JID does not contain the FQDN. You are also unable to send message to your buddy in this case since the message is delivered via server-to-server network connection.
When your buddy client receives the Presence Subscription Request from hosted server, an Authorization Request dialog is launched for his/her approval. Your buddy may Ignore, Deny or Authorize the request. Reciprocally, a Presence Subscription Request will be reverted for your approval when your buddy approved the request. In the event your buddy chooses to ignore your request; any further re-authorization request from you will not trigger another Authorization Request. However the server will resend the request on your behalf when the buddy has exited and login again. This process continues until user has made a decision either to Deny or Authorize the request.
The "Add Contact" dialog provides the option to categorize your new contact to one of your existing defined groups or a newly created group. You may perform this grouping or moving to another group after the contact has been added. The same option is also available to your buddy when he approves the Presence Subscription Request.
You may also enable the Presence Subscription Approval-auto accept all in the [menu | Settings...]. Under this case, upon received a Presence Subscription Request, aTalk will automatically approve the request and it will also revert a request to your buddy for approval.
Please see Managing Presence Subscriptions for more information,
[20181017] StreetViews & Map { Content }
Every location on earth has a global address, given as two numbers called coordinates. The two numbers ("Lat/Long") are a location's latitude number (north-south) and its longitude number (east-west). Together with help from google global location service, you can display the global address in graphical views as streetViews and map of the location understand by human.
aTalk has implemented GPS location tracking, displaying both the streetViews and map on user device screen. The tool allows either a single location fix update or in continuous locations fix update mode. The continous mode update is triggered by two parameters changes i.e. distance delta or elapsed time. Either condition will trigger a new location fix fetch. The user selectable distance range varies from 0~500m with 5m steps; while the elapse time can range from 5~1000S in 10S interval. In continuous mode, user may choose only to send the location messages without displaying the realtime updates of streetViews and map information. This is done by not selecting the Continuous StreetViews & Map update option to conserve data usage.
On the streetViews and map display screen, you can select (press and hold) the little orange man figure and then drag to a new location on the display map, the streetView display will also be updated according to the new selected map location. You can also change the device pointing direction for a 360° panoramic view of the current select location on the map.
Send GPS-Location message: The tool allows user to relay his/her current GPS location in a single or continuous mode to his/her buddy as Geo-Location chat messages, i.e. only the longtitue and latitute information are being sent to conserve data usage. This feature is enabled from within the chat window menu Send GPS-Location option. When your buddy clicks the SteetView & Map button on the received location message on his/her device, your current location is displayed on his/her device screen. The steetViews and map display on your buddy device automatically gets updated each time your new location is being streamed via continuous mode; tracking your move in realtime.
Note: To protect your privacy, this feature can neither be accessed nor enabled remotely; neither it can be accessed from any other applications installed on your device.
Show GPS Location: You may use the tool as it without sending any of your current GPS location as message. This feature is accessed from the contact list main menu StreetViews & Map.
Locations playback animation: If you have the location history messages in the chat window, long press SteetView & Map button on any of location messages starts the location playback animation at interval of 2S. The playback anmiation either applies to incoming or outgoing messages grouping pending on which message you have initiated the playback animation mode.
GPS Location Demo: The feature has a built-in demo. Long press the Cont. Location update (xm) @xSec button starts the GeoLocation in demo mode. The streetViews and map will continuous get updated at 2S interval assuming user is moving in the north-west direction. If you enable this demo while in chat mode with another device as your buddy, you can see that the buddy device tracks and synchronizes the streetViews and map display following the user device.
Followings are some possible use of the StreetViews & Map feature:
XEP-0045: Multi-User Chat { Content }
With multi-user chat (MUC) or group chat, in which XMPP XEP-0045 chat rooms are designated; several users can share chat messages at the same time. aTalk implements most of the common features for MUC messaging. Followings are few of the terminology pertaining to MUC operations.
In the main menu, sliding right will show a list of the chatRoom's in which you have once being actively participated in the MUC chat. These are likely to be persistent rooms. aTalk has the following MUC features implemented.
Join Chat Room: Select this option from the main menu to create new or re-join an existing room. Pending on your room privilege, you may supply the NickName and ChatRoom subject when joining the MUC.
Invite: While in MUC session, you may select this option to invite new participants to join the MUC room. An invitation message will be sent to all the invitees you have selected. Your contacts may accept, reject or ignore the invitation. Except for ignore option selected, the accept or reject reply from your buddy is displayed in the chat window.
Discussion History: Depending on local service policy or room configuration, a room may send discussion history to the newly join occupant. Whether such history is sent, and how many messages comprise the history, are determined by the chat service implementation or specific deployment depending on local service policy or room configuration. Talk can receive and display all the history messages, while removing any duplicated messages.
Chat room occupants: Anytime during MUC session, you may select this opton to query a list of the Room Occupants currently have active participation in the MUC room. The list is displayed in the chat window.
Converting a One-to-One Chat Into a Multi-User Conference: Sometimes it is desirable to convert a one-to-one chat into a multi-user conference. In a one-to-one chat, just select Invite option to add existing buddy and other new buddies to the chat. A new MUC room will be created including all the new participants selected.
If you attempt to open a member-only room when you are not in the room member list, the process will failed with an error message. You will no be able to receive or send any messages in the chat room. Likewise you will receive an error message if you attempt to destroy chatRoom when you are not the room owever.
[20180915] Stickers, Bitmoji and Emoji rich content sharing { Content }
aTalk v1.5.2 has added support for Stickers, Bitmoji and Emoji rich content sharing using Google Gboard keybard. The Google Gboard keyboad is normally pre-installed on the latest android devices. If your android device does not have the Gboard, you may install it from Google play store.
Android device with Google Gboard keyboard, it allows user to share sticker and Bitmoji in addition to the current emoji, in messaging apps like aTalk.
With Gboard, users can download third-party sticker packs and/or the Bitmoji app from the Google Play store; and then send these stickers and Bitmoji while using the Gboard keyboard. When using the Gboard keyboard, users first tap the emoji button, and then tap either the sticker button or the Bitmoji button to search for the content they would like to share with the buddy.
Plese refer to the following sites for more information:
[20190508] aTalk Fault-Tolerance File Sharing Implementation & Enhancements { Content }
aTalk file sharing between contacts implementation uses the following XEP protocols:
  • XEP-0096: SI File Transfer
  • XEP-0363: HTTP File Upload
  • XEP-0264: Jingle Content Thumbnails
  • aTalk supports send and receive files for all document types and images. There is an option to enable thumbnail preview before the images file is being sent. The actual file is only sent upon acceptance by your buddy. aTalk allows automatic acceptance of file transfer request or stickers sending with user defined max file size option.
    aTalk SI File Transfer protocol supports both the SOCK5 and IBB bytesStream options; and it implements fault-tolerance with IBB as fallback if SOCK5 failed. During file transfer, aTalk attempts to use the more efficient SOCK5 bytestreams method if the recipient client supports it. However if SOCK5 byestream method failed for reason e.g. client symmetric NAT fireware, aTalk automatically fallback to use IBB method to ensure a successful file transfer.
    If your buddy client e.g conversations, does not support the above legacy SI File Transfer protocol, aTalk will automatic proceed to use the HTTP File Upload to share file with the buddy. (v1.8.3)
    When aTalk detects your buddy is offline, it automatically selects the HTTP File Upload facitiy, if supported by your xmpp service, to continue with the file transfer. XEP-0096: SI File Transfer specification has no provision to transfer file when you are in a muc/conference chat room. Under this condition, aTalk checks the server for HTTP File Upload service support, and uses it if availabe to support file sharing between chat members in conference room.
    [20180710] XEP-0198:Stream Management and ReConnection Manager { Content }
    In wireless communications, fading is variation of signal with time, geographical position, and radio frequency. Fading is frequent in mobile devices and may cause momentarily newtork data lost or disconnection. To improve network communication reliablity and minimize data lost, aTalk implements both XEP-0198: Stream Management and Reconnection Manager.
    In Stream Management, all stanza data exchanges between client and server are verified and acknowledged. When a stanza data is lost during fading, either entities will attempt to resend stanza data that has not been acknowledged by the recipient.
    In event that a sudden lost of network connection is detected, Reconnection Manager will automatically start the reconnection sequence using the algorithm defined below:
    aTalk requires network connection in standby mode in order to receive messages or media calls. If you disable all network connection during device standy, reconnection manager will kick in once it detects network lost, and continues until you manually exit aTalk. Do ensure either GSM network or WiFi network remains accessible when device goes into standby mode. If all network is disabled in standy mode, you may also need to restart aTalk when device is waked up.
    Some of the availabe power saving mode that may affect aTalk operation during standby, options may vary depending on android device and OS version:
    [20181015] Network Keep Alive - Ping Interval Optimization { Content }
    Most of the newtwork service provider inherently closes mobile devices TCP socket connection when it detects there is no data exchange activity for some elapse of time. The established internet TCP connection channel with the server may also be removed by the network after some idle time. If you find that your device is unable to receive messages in realtime or/and with aTalk goes offline frequently; you will need to go to [Account Settings... | Connection Settings] to select the Enable Keep Alive option and set the Ping Interval that is lower than the newtork data inactivity timer for your internet service provider. A good starting value is 240-second for the ping interval; and tweak the value if necessary with 20-second steps for the optimal device performance.
    aTalk has implemented an user option Enable Ping Interval optimization to allow aTalk to auto tune and optimize the Ping Interval time for network connection for each user account. This option is enabled by default until user disables it. The Ping Interval optimization is active only when your device is connected to the service provider via the mobile network connection. No optimization will be performed when the device is connected via WiFi; During testing, no ping failure is detected when the device is connected via WiFi-LAN to the service provider.
    Following gives a brief description on the Ping Interval Optmization procedure with inital setting of 300s (or 5 minutes)
    Manual tuning is needed when <120s is required. When optimization is completed or you want to set Ping Interval manually, you may disable Enable Ping Interval optimization option.
    Note: When an established TCP data channel is terminated by network, neither android nor aTalk is able to detect this condition, until it failed while attempting to send data. Therefore Reconnection Manager is not being triggered when the TCP data channel is removed. It is therefore necessary to send the keep alive ping at regular interval to detect this condition for Reconnection Manager to work.
    [20190119] Android Runtime Permissions Request { Content }
    With Android 6.0 Marshmallow (API 23), a new runtime permission model has been introduced; Users are not prompted for permissions at the time of installing the app, rather app needs to check for and request permissions at runtime. Users can then allow or deny the permissions for the app, users can also grant or revoke permission anytime from the app settings.
    Whenever user launches aTalk on Android M or higher, it prompts the user to grant if there is any missing required permission. For aTalk maximum performance and full features support, aTalk requires the user to grant permissions for the following services.
    If any of the permissions is denied, aTalk may not work properly or may have unexpected behavior. If you have selected Don't ask again option, you will not be prompt on next aTalk launch; You need to go to android Settings -> APP INFO for aTalk to enable the permissions.
    Note: If you change any of the resouce permissions via android Settings, you must exit and restart aTalk for the granted permission to take effect. This is because some of the permission is only checked during aTalk start up e.g. Permission.CAMERA.

    OMEMO Messaging
    [20190424] Why the OMEMO option is grayed out in my chat session menu? { Content }
    In order to support omemo session, both your buddy client and the registered servers' xmpp services must support OMEMO required protocols.
    • Your registered server and the servers of your chat partners must support PEP (XEP-0163) to store and exchange key bundles. Optionally your server should support Message Carbons (XEP-0280) and Message Archive Management (XEP-0313) to achieve message synchronization across all (on- and off-line) devices.
    • Your buddy installed client must also implement omemo service.
    aTalk checks both server and jid entities to ensure both entities can support OMEMO before the OMEMO option is enabled i.e. aTalk sends xmpp request for disco#info with jid='<service>', the server must include all the pubsub.<service> in the replied disco#info <feature/> list as per the standard xmpp specifications. Some xmpp services do support the required pubsub protocols but does not advertise in disco#info <feature/> list reply e.g. prosody version 0.11.2 (released: 2019-01-09). aTalk v1.8.2 (20190424) has added an alternative verification specifically for this deviation and enable OMEMO option. See link for more info: omemo encryption not available (option is greyed out)
    Why am I being asked to authenticate the contact during secured chat? { Content }
    In order for a cryptographic system to make sense, decisions must be made whether a secure chat session is trustworthy. Authenticating a buddy helps to ensure that the person you are talking to is who he or she claims to be. This is done by verify the person fingerprint(s) that are presented to you; contact your buddy via an external channel, such as reading it out on the phone, scanning QR codes etc. If everything matches up, you then indicate in the dialog to trust or untrust the fingerprint(s). This process needs only be done once. However if you later decided to distrust a contact, you can change the trust state of the contact in menu "Settings... | Messaging Security | Crypto buddy fingerprints". During an omemo conference session, OMEMO messages will not be sent to all your defined untrusted buddies
    What is Blind Trust Before Verification? { Content }
    aTalk implements Blind Trust Before Verification with an option to enable or disable it. With the option:
    • enabled: first installed new devices of contacts that have not been verified before will be auto-trusted. However you will be prompted for manual confirmation when a verified contact adds new devices.
    • disabled: you will be prompted for manual confirmation on all devices installed by your contacts.
    When do I have to perform "Regenerate Omemo identity"? { Content }
    Every android device installed with aTalk will be assigned an omemo identification which is required for omemo messaging support. The identification of the omemoDevice is associated with an identityKeyPairs and is unique for each omemoDevice in the network. The identityKeyPairs contains both the Private and Public Keys. The public key is published and stored on the server. The private key is required during omemo message encryption and sending. You contact will retrieve the public key from the server and use it to decrypt the received omemo message.
    In an unlikely event that the omemoDevice identityKeyPairs is corrupted, omemo messaging with your buddies is no logger possible. aTalk alerts you when it detected a corrupted identityKeyPairs. If the problem persists on relaunch aTalk, you then need to regenerate a new omemo identity to rectify the problem. From the main menu select "Settings... | Messaging Security | Regenerate OMEMO identities", select the account that is having problem. Then click "Regenerate Selected" button to proceed. Upon regenerated your OMEMO identity, all your contacts receive the new updated key fingerprint and are required to reverify your omemo identity.
    Note: You need to relaunch aTalk after you have performed "Regenerate Omemo identity"

    OTR Messaging
    What are the OTR version supported by aTalk? { Content }
    aTalk OTR implementation support all current versions of OTR i.e. V1, V2 and V3. During OTR setup, aTalk will attempt to use the highest possible OTR version that your buddy installed client can support.
    Why the OTR option is grayed out in my chat session menu? { Content }
    aTalk has few OTR options to control how OTR session should be handled. These option are user selectable in the main menu "Settings... | Messaging Security" [OTR MESSAGING SECURITY] section.
    • Private messaging: A prerequisite option that you much enable to allow OTR messaging. Otherwise OTR option is grayed out in the chat session menu.
    • Auto initiate private messaging: When enable, the OTR chat session will automatically be initiated when you start a chat session.
    • Require private messaging: The OTR chat session is enforced if your buddy also support OTR messaging.
    • Unlike Omemo, OTR session cannot be setup when your buddy is off-line.
    Note: Omemo session has priority over OTR. If your buddy attempts to change to OTR session while a OMEMO session is in progress, aTalk will stop it and a message is displayed to that effect.

    Media Call Communications
    [20180613] Why the call options button are not shown on some of my contacts in the contact list? { Content }
    aTalk supports both voice and video call sessions. To allow setting up any of these media call with your buddy, your buddy installed xmpp client must also support the respective media call service. During aTalk initial start up, all buddies will send its features supported via cap version hash embedded within its <presence/> stanza. aTalk then perform check on each buddy supported features via service discovery (XEP-0030) protocol; and enable only the respective media call options that are supported by your buddy client.
    Note: The contact must support XEP-0115: Entity Capabilities, version 1.5.1.
    [20181228] Media Call and Chat Message sessions { Content }
    aTalk allows user to send chat messages while an active call is in progress. User may start a media call while in chat mode or vice-versa. When simultaneous call and chat sessions are in progress, switching between the two modes is easily performed with the two special buttons i.e. Back-To-Chat while in call mode, and Back-To-Call while in chat mode.
    When the handsfree/speaker-phone mode is not enabled, the received audio is heard via the phone internal receiver piece or the headset that is connected to the phone audio jack.
    During chat mode, the Back-To-Call will only be shown when there is an active call in progess. Otherwise a voice message (mic) send button is shown instead.
    When user switches to chat mode, all video streaming will be paused as there is no focus window for video display. However audio streaming remains active at all time. When user switches back to video call, the video streaming will resume automatically.
    When in chat mode, user may peform some simple tasks with the active call using the call notification panel as shown below, without actually switching back to call mode.
    Note: Switching video stream on/off is a complex task and it requires reliable communication. When the secured call option is enabled, the replay protection is also enabled against MitM. Due to interruption in video streaming, it may at time triggers a false MitM attack and all violated streaming packets are discarded. Under any of these fault conditions, the video is not display at the remote end. To recover from this situation, just toggle the camera off and on again at the sender device.
    [20181228] Video Call session { Content }
    During video call session, the remote video will always be displayed in full screen i.e. expand to fill the maximum screen size, but keeping video in correct aspect ratio and without clipping.
    Local video or streaming video: The locall video preview size follows a scaled down of the user selected camera resolution, and rotated according to the phone orientation i.e. portrait or landscape. The streaming video size will attempt to keep to selected camera resolution (rotated if necessary), but automatic reduce the data streaming rate (smaller size but same aspect ratio) according to the network condition.
    Remote video: The remote video display orientation will follow the received video stream, but always expanded to fill full screen, independent of the received video size changes due to network condition.
    Auto video rotation: If you change the phone oritation e.g. from portrait to landscape mode, the local preview and streaming video will automatically change according. In aTalk v1.6.4 release, the remote video display orientation may not automatically change pending the video codec in use. The video orientation change is detected by the video decoder and relay to the api for action. So far this is only supported by VP8 codec. Currently H264 codec cannot detect nor report the remote video orientation change; hence the received video is not display properly. To support auto rotation, please select VP8 and set it to top priority in the video codec settings.
    Note: On some new android devices, it was found that swipe inward from the top screen does show the action bar. If your device does not have a hard menu button, you will not be able to access to all option items in the action bar. To toggle front and back camera, long press the video icon at the bottom of the display.
    [20181016] Jabber VoIP-PBX gateway Telephony (experimental) { Content }
    One distinguishing characteristic of Jabber technologies has been the existence of gateways (also called "transports") between the Jabber network and legacy services. The legacy services can be other IM protocols like SIP, AIM, ICQ or even a PBX gateway allowing a jabber entity to make voice/video call to phones via landline or GSM network.
    aTalk provides the necessary interface to allow user to make jabber voice/video call to PBX gateway installed on the user registered service. The gateway however must support the following XEP protocols
    aTalk Telepohny option uses the following two paramteres, and are requires to be setup if you want to override the defaults. These parameters can be found in [Account settings... | Telephony} section
    Note: All media calls including the telephony call will be disabled if you checked the option Disable media calls (Jingle).
    [20181228] VoIP communications security via SRTP with ZRTP, DTLS and SDES protocol. { Content }
    The Voice over IP (VoIP) and other media applications uses Real-time Transfer Protocol (RTP). Many VoIP applications send RTP data over the public Internet in clear, thus the data is not protected from eavesdropping or modification. Therefore most VoIP applications are considered insecure today. aTalk supports SRTP and ZRTP etc to enhance the security for VoIP communications.
    To enable SRTP call ecryption in aTalk. From main meneu select Account settings... and user account properties to edit, follow by Call Encryption setting. Check Enable call encryption option and select the desired Encryption protocols and arrange them in the preference order. Check the ZRTP signalling advertise over signalling if ZRTP protocol is selected.
    During media call, the status of the call security is indicated by a padlock icon. An unsecured call is indicated by red open padlock. When call security is in effect, a green padlock together with the security protocol name is shown. You can click on the green padlock to view the Security information.
    Note: Both the caller and callee must have Enable call encryption option selected before the secure call can take place. If either party has the option disabled, the call will not be encrypted.
    [20181126] STUN, TURN, ICE & Jingle for NAT Traversal in media call setup
    NATs (Network Address Translation) and firewalls play a very important role in securing and enhancing the usability of internal networks, however impose significant challenges in setting up a reliable VoIP call bewteen two end-points. STUN, TURN, and ICE are a set of IETF standard protocols for negotiating traversing NATs when establishing peer-to-peer communication sessions.
    A host uses Session Traversal Utilities for NAT (STUN) to discover its public IP address and type of firwall when it is located behind a NAT/Firewall. It then uses this information to assist in establishing peer-to-peer VoIP connectivity.
    While STUN is effective in addressing the NAT issue with most consumer NAT devices (routers), it doesn’t work effectively for many corporate networks. If the NAT/Firewall would not allow the two hosts to connect directly, they make a connection to a server implementing Traversal Using Relay around NAT (TURN), which will relay media between the two end-points.
    Interactive Connectivity Establishment (ICE) is a framework that describes how to coordinate STUN and TURN to make a connection between two end-points.
    Jingle specification defines an XMPP protocol extension for initiating and managing peer-to-peer (P2P) media sessions between two XMPP entities in a way that is interoperable with existing Internet standards.
    Universal Plug and Play (UPnP) is a set of networking protocols that permits networked devices, such as personal computers, printers, Internet gateways, WiFi access points and mobile devices to seamlessly discover each other's presence on the network and establish functional network services for data sharing, communications, and entertainment. UPnP is intended primarily for residential networks without enterprise-class devices.
    aTalk uses all these options when setting up call between two end-points. These user defined options can be found in Account settings... | ICE.

    User Avatar
    Why some of the avatars for my contacts in main menu are blank or with incorrect pictures? { Content }
    aTalk implementation supports both XEP's defined specifications in handling the contact avatars i.e: Your contact installed client must use either of these methods to update and publish his avatar on the server. aTalk can then retrieve your buddies' avatars from the server for display. Otherwise aTalk will display the default avatar i.e. blank figure picture for contacts without one.
    Each avatar images stored on server can be few KBytes in size. During the process of avatars retrieving from server, sometimes network communications may get interrupted or aTalk encountered reply timeout from server. This can lead to incorrect avatars being associated with your buddies. If the problem persist after you relaunch aTalk, please following the steps below to refresh your buddies' avatars.
    How do I update my user avatar? { Content }
    aTalk has an integrated picture editor that supports zooming, scaling and cropping. This simple tool helps publishing of user avatar an easy task. Please click here to return to main page, and playback the demo video for "User avatar" to get help on how to publish user avatar.
    In order to allow your buddy installed client that supports only either one of the avatar protocols, aTalk uses both methods to update the avatar on the server. This does take some times to store the avatar on the server. So be patient when you update your own user avatar.

    [20181228] Why aTalk is not working properly on my old android devices? { Content }
    aTalk installation requires android device with API 5.0 and above for full features support. To have satisfactory performance for both video call and cryptography etc, aTalk also requires reasonable fast multi-core CPUs. A slow android device is likely to have problem in handling the vast amount of information from incoming & outgoing streaming media data and cryptography processing. With aTalk installed on slow device, you may find response to user action is sluggish, and at time the screen turns black for a while before returning. Please be patient to wait if you in love and cannot part with your old android device.
    Android N introduces Android Runtime (ART) with Ahead-Of-Time (AOT) compilation and improved garbage collection (GC), replacing Dalvik that combines bytecode interpretation with trace-based Just-In-Time (JIT) compilation. Android old devices with JIT implementation do experience problems during some timing critical tasks. It is observed that JIT compilation actually extends the time in processing task e.g. the time gets added to during stanza exchanges with server, hence throws response reply timeout excpetion at times. This usually happens on the initial launch after installation of aTalk. If you do experience this problem, relaunchs aTalk may resolve the issue.
    The initial aTalk released in Google play store actually allow the app to be installed on API 4.1, with expected degradation in performance due to some missing libraries support on these devices. You are advised only to install and operate aTalk on a newer device if you cannot accept these performance degradation. Pending on user feedback, future release of aTalk may remove support on devices with android version lower than Android 5.0 or API-21.
    Note:: Android requires all new apk releases in 2019 with ndk libraries must support 64-bit architecture. Building of 64-bit ndk libraries required minimum API-21. aTalk will eventually move to only support android 5.0 and above.
    [20180808] aTalk - android OS API compatibility { Content }
    Android Marshmallow is android 6.0 or API 23. Starting with API 23, android has proceeded with Text Relocations (Enforced for API level >= 23). This means all shared objects in the installed apk must not contain any text relocation code i.e. the code must be loaded as is and must not be modified. Such an approach reduces load time and improves security. aTalk implementatation uses third party libraries, and one of its native libraries i.e. ffmpeg has text relocation when compiled for anroid with x86 cpu architecture. Android aborts loading of any library with text relocation. Library ffmpeg is ued by aTalk to support the media call services. Therefore when you install aTalk on an x86 android device with API-23 or higher, all the media services will be disabled and not available to the user. Beside this, all other aTalk features should be working. Please refer to the following site for more information:
    Why do I see screen displaying "shutting down ..." message on re-launch after exit? { Content }
    When you exit from aTalk, the application must inform your registered server so that the client state is properly synchronized and also to give time to server to perform some house keeping tasks. When the server has completed the necessary tasks, it sends an acknowledgement i.e. </stream> to inform the client, only then aTalk can proceed to close the connection and exit. If this required acknowledgement is not received due to network error etc, aTalk waits until a predefined reply time period has elapsed before exit. aTalk globally set the reply timeout to 10-seconds, this is to allow servers with high latency and for slow devices to operate properly.
    How can I give feedback to the developer for any aTalk problem encountered? { Content }
    aTalk has a built-in debug log utility that capture any runtime exceptions. In the event if you experienced problem with aTalk, you can forward this log information to the developer to identity the cause of the problem and to provide solutions in the next release if possible. To send the debug log, from main menu select "Help | Report Bugs", then pick your email client to send. To help developer to quickly identity the problem. a brief description of how the problem happen certainly help. Send the mail after you are done.
    The log contains only the required information necessary to help identify the problem. No personnel sensitive inform are being included. The log will be deleted once the problem is identified and no copies of the log are being kept.