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.
CONTENT

Account Setup & Login

Enhanced Features

OMEMO Messaging

OTR Messaging

Media Call Communications

User Avatar

General


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.
[20190731] 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 hosts/services. The virtual host/service name is usually tag with the user xmpp account e.g. alice@example.org, where example.org is usually referred to as service domain or virtual host.
If you leave the Override server setting option unchecked, aTalk first checks to ensure the specified service domain is reachable; it searches for the actual internet ip address on a Domain Name Server (DNS). On success, aTalk proceeds to lookup the SRV record on the server which contains the required ip:port network information for connection.
Initial connection attempt wil fail if neither of the following conditions is met, and you may need to enable the Override server setting option:
In the first case, aTalk uses the service domain resolved internet address and default port 5222 for connection. For server without SRV record implementation and connect via port other than 5222, you need to use Override server setting option. In Connect Server IP field, use service name of the xmpp account.
In the second case, you need to specify the actual physical domain name i.e. Fully Qualified Domain Name (FQDN) where the xmpp service resides. First check the Override server setting option, then enter the FQDN into the server setting Connect Server IP field. With this setup, aTalk will not look for SRV record on the service domain, instead it 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. 115.66.84.204 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.
[20190620] Why my first login in sometimes fails when a new account is created? { Content }
Most of the servers today have SSL certificates installed on their sites. The certificates 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.
In aTalk, when you setup an account and sign in on new server, android OS checks for the site certificate validity during the SSL secure socket connection setup. If the site certificate is signed by a trusted certificate authority and is also listed in android certified trusted authority list; android proceeds normally with the SSL socket connection, otherwise it throws CertificateException.
aTalk captures this CertificateException thrown by androis OS when the certificate is self-signed. aTalk then downloads the site certificate and check against its database. It prompts user for manual confirmation if the certificate is new to aTalk as shown on the right i.e. Certificate Verfication.. You can procced with login by clicking on the Procced button. Under this condition, the certificate info is not saved in aTalk database, and you will be prompted again in your next login.
Alternatively, you can click the Show Certification button, the site certificate is shown with an user option Always trust this certificate. You must check this option if you do not want aTalk to prompt for manual confirmation on your next login. You can then proceed to login with the Procced button.
If you take some time to confirm the certificate before proceed, the server login hold time may have expired and the established connection gets disconnected. Under this case, you need to login a second time. If you continue to receive login failure, please check the error messages return from the server, make the necessary correction/action e.g. make sure jabber Jid, password entries are correct or IBR is required before attempt to sign in again. You may refer to other sections in this page on how to create a new account.
Note: Starting android-P, CLEARTEXT communication is not permitted by android network security policy. aTalk implementation has adhered to this requirements.

Enhanced Features
[20190626] 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".
To add a new contact to your buddy list, from main menu select [Add contact]. A form is displayed for your input.
Click on the Contact Assigned Group selector will bring up the group assigning options.
If you select the Create group... option from the previous menu, a new dialog will appear as shown below. You may entered the new group name in the entry box provided. You may perform this grouping or moving to another group after the contact has been added.

Adding Contact Process Flow:
When you add a buddy to your contact list, aTalk actually makes an online subscription request to your buddy for his/her approval. In this process, your hosted server routes your subscription request on local machine if the buddy is of the same server; otherwise via remotel connection to the buddy hosted server. The server-to-server (s2s) connection setup uses the IP derived from your buddy account service name i.e. example.org from "buddy@example.org". If the derived domain is not a Fully Qualified Domain Name (DQDN) and canno be resolved to an IP, the subscription request process will fail.
With the current XMPP standard defined for Presence Subscription, it is therefore not possible to add 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 s2s network connection.
When you receive the Presence Subscription Request from your buddy via the hosted server, an Authorization Request dialog is launched for your approval. You may Ignore, Deny or Authorize the request. If you accept your buddy request, reciprocally a Presence Subscription Request will be reverted by aTalk to your buddy for approval. Meantime your buddy will receive the acknowledgement of your acceptance.
In the event if you choose to ignore your buddy request; any further re-authorization request from your buddy will not trigger another Authorization Request. However the server will resend the request when you exit and login again. This process continues until you have made a decision either to Deny or Authorize the request.
Instead of manually approve upon each received Subcription Request, you may made this process automatically, by enable the option Presence subscribe approval auto accept all in the [menu | Settings...]. In this case, aTalk automatically approves upon received a Presence Subscription Request from your buddy. It will also revert a request to your buddy for approval.
Note: When you remove a buddy from your contact list, it automatically triggers the server to remove him/her from your Presence Subscription.
Your XMPP service admin may choose to create share-rosters on the server, grouping all the related members in each categorid roster group. Upon first login, every member of the group will have his/her contactList populated with all the members within his/her roster group. This saves the memeber to manually subcribe to everyone in the related entity.
For more information on Presence Subscription, please see Managing Presence Subscriptions
[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.
[20190620] XEP-0048: Bookmarks and autoJoin option for conference { Content }
For ease-of-use in a Jabber client, it is desirable to have a way to store shortcuts to various services and resources (such as conference rooms and web pages) as "bookmarks" that can be displayed or duplicate in other user's client. In aTalk implementation, the bookmark attribute autoJoin is also extended to be used as local standalone opton.
When you slide to the chatRoom list upon first login, the chatRoom list will be populated, in additional to your exisitng local chatRooms, with the chatRoom bookmarks you have previously saved (from another client) on server. aTalk auto joins chatRoom if the autoJoin option is being enabled in the newly downloaded bookmark or via locally specified autoJoin option.
Each chatRoom item in the list is accompanied with two indicators/buttons. The two icons both served as an status indication and user input options.
When you click on the bookmark icon on the chatRoom list item, it brigns up the bookmark form as shown on the right for user update. Below provides a brief descriptions of each field in the form.
From the main menu, you may also access to the chatRoom bookmarks. The new form is very
similar to the one described earlier for the specific chatRoom; the differences are described below.
If you have made any changes to any of the chatRooms in this form, you must click the Apply button to exit. If you exit with Cancel button, all changes made thus far will be discarded. However as a gentle reminder, if you click the Cancel button with any unsaved room attributes, aTalk will alert you, and request for re-confirmation before exit and discard all the changes.
[20190626] XEP-0070: Verifying HTTP Requests via XMPP and WebView Implementation { Content }
XEP-0070 specification defines an XMPP protocol extension that enables verification of an HTTP request via XMPP. HTTP (RFC 2616) is a nearly-ubiquitous mechanism for the publication and retrieval of information over the Internet. Sometimes it is appropriate for an HTTP Server to allow access to that information only if the HTTP Client first provides authentication credentials. While there exist several standardized HTTP authentication schemes (RFC 2617), it may be useful in some applications to enforce verification of an HTTP request by requiring an XMPP entity (normally an IM user) to confirm that it made the request. This request verification can be combined with native HTTP authentication to provide a stronger association between the request and a particular user, as well as to take advantage of the strong user authentication provided in XMPP.
aTalk v1.8.8 has implemented the XEP-0070 protocol and intergrated a webView within the application. To have a better understanding the operation of XEP-0070, there actually exist an online demo site i.e. Demo Website: Authentication with XMPP for this purpose. Folowings detailed the steps on showing the demo on aTalk.
Note: The XMPP HTTP Authorization request is sent via s2s connection, therefore you must ensure that the user account virtual host (i.e. domain part of the account) must be resolved to a valid IP. Otherwise the HTTP will not be able to reach you.

aTalk integrated WebView Interface: aTalk has also integrated a WebView interface within the application. When user slides left until this WebView is in view, it automatically loads the site address as defined in the main Settings....
The purpose of the WebView is to allow an organation to display its official web page. The page can be used to provide the organisation latest news update and even for RSS feed. By default, if you leave the main Settings... Web Access Page blank, aTalk automatically loads the movim page. From here you can sign in to the site for their news update, RSS feed, chat etc.
When a HTTP Server allows user access to the information only if the HTTP Client first provides an authentication credentials, aTalk will pop up Sign In form as shown on the right for uer to login. Like normal browser, you can navigate and click links that appear in the page. aTalk webView will refresh the page with the new page. For security reason, however aTalk will only load the page within aTalk application if the new link host address is the same as defined in the user setting; otherwise it will use android default browser for the web page display.
You can go back to the previous page by using the Back Press button; or slide right to leave the WebView and return to other slider pages. If you change the Web Access Page settings, you must navigate the slider to the ContactList page. This is to trigger android OS to invalidate the last accesed web page. Only then, WebView can load the new user defined web page.
[20190526] 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.
Stickers, Bitmoji and Emoji rich content sharing is supported during an 1:1 chat or chatRoom session.
Plese refer to the following sites for more information:
[20190902] aTalk Fault-Tolerance File Sharing Implementation & Enhancements { Content }
aTalk file sharing implementation uses the following XEP protocols:
  • XEP-0096: SI File Transfer
  • XEP-0363: HTTP File Upload
  • XEP-0264: Jingle Content Thumbnails
  • XEP-xxxx: OMEMO Media Sharing
  • aTalk supports send and receive files for all document types and images. There is an option to enable thumbnail preview before the actual file is being sent. To send or receipt of thumbnail, both the sender and recipient devices must have this option enabled; and the transfer file size is smaller than the 'Auto accept max file size'. The actual file is sent upon acceptance by your buddy. When XEP-0096 protocol is used, aTalk allows automatic acceptance of file transfer request or stickers sending if the size of the file to be transferred is less than the user defined max file size option.
    aTalk implements fault-tolerance file sharing to ensure reliability. aTalk SI File Transfer protocol supports both the SOCK5 and IBB bytesStream options, 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.
    In the event if your buddy client e.g conversations, does not support the legacy SI File Transfer protocol, aTalk will automatic proceed to use the HTTP File Upload service to share file with the buddy.
    When aTalk detects your buddy is offline, it automatically selects the HTTP File Upload facitiy, if the protocol is 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.
    aTalk also supports 'OMEMO Media Sharing' procotol. During an OMEMO chat session either in 1-1 or muc, all file sharing will be ecrypted before sending via HTTP File Upload service.
    aTalk harmonizes and uses a common UI in file sharing irrespective of which file sharing protocols is being used, and in all the various chat sessions. Unlike all other file transfer protocols, when file transfer is via HTTP File Upload service, the sender is unaware of the recipient status. After the sender has succesfully uploaded the file to the server, it forwards the file download link embedded as a chat message to the recipient. To allow recipient to retrieve the file, aTalk always shows the received file download link as a file transfer request. Selecting the Reject button does not actually delete the file link message. aTalk will show the prompt after user returns to the chat session later, even the user has previosuly selected the Reject button, either intentionally or unintentionally. To remove the prompt, user must manually select and delete the link message/prompt.
    [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.
    [20190823] Android Runtime Permissions Request { Content }
    Starting 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 within the android settings to override the permission granted during aTalk permission requests.
    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.
    Followings are also hold truth on aTalk reacts to the permissions grants.
    • aTalk will always prompt for permission grant if none are set to permanently denied on every aTalk new launch. This is to take care of users whom had unintentionally denied the permission on initial use; later want to use features that required new permissions. Normally user should not Exit aTalk as this ends and termates aTalk completely. Instead user should use Back Button to close aTalk window.
    • aTalk will repeatedly prompts user for actions if there are less than 3 permissions being granted even users had permanently denied them. Most aTalk features will not operate properly under these condition. If you understand and accept aTalk unexpected behavior, but do not wish to be bothered by aTalk repeated permission prompts; then always use Back Button to close aTalk window.
    • It was found that some android devices have incorrectly implemented the PERMANENTLY DENIED options; hence aTalk will always prompt user for permission grants even the above conditions are being met. It seems that the affected android devices have init all requested permissions to PERMANENTLY DENIED states, and OS returns incorrect results when aTalk performs the check.
    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
    [20190916] Why the OMEMO option is grayed out in my chat session menu? { Content }
    In order to support omemo session, both the buddies' clients 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 implement omemo messaging encryption service.
    • Non-Anonymous Room: A room in which an occupant's full JID is exposed to all other occupants; contrast with Semi-Anonymous Room where occupant's full JID can only be discovered by room admins only.
    aTalk checks both server and jid entities to ensure all 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.
    In a Semi-Anonymous Room, since not all the recipients' fullJid's are known to every participant, therefore omemo messagging is again disabled for this session.
    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)
    [20190916] Why am I being asked to authenticate the contact during secured chat? { Content }
    0
    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 performed 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
    An unlikely event may occured during omemo chat session; aTalk has detected that one of yours or the buddy omemoDevices key bundle retrieved from the server is corrupted. This corrupted device key is also presented for your action in the Authenticate Buddy dialog. Beside authenticate new omemoDevice fingerprint, you need also to take action on the correupted omemoDevice key. The only available option for a corrupted omemoKey is to select the option Corrupted OmemoKey, purge? currently. This will remove the corrupted omemoDevice from your receipient list. Otherwise, aTalk cannot proceed to send omemo message to other recipients.
    If you leave any undecided omemoDevices' fingerPrint unauthencated on exit, aTalk will display an error message. Click on the OMEMO encryption option to have the Authenticate Buddy dialog prompt for correction, then resend the last message. Alternatively, just click on the last unsent message and re-send. aTalk will auto resend the message once all the undecided omemoDevices have been authenticated.
    When the corrupted omemoDevice is purged from your recipient list, the affected device will not be able to receive your omemo messages that you have sent. If the affect device is one of your other omemoDevies, you need to perform Regenerate OMEMO identities on the specific physical device; Or send an unenrypted message to your buddy to alert him; he/she too needs to perform Regenerate OMEMO identities on the affect device.
    [20190716] 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 device of contact that has 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 contact.
    [20190716] 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 nay 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.
    Purge unused identities You may have the same account setup on mutliple devices for OMEMO sessions. Each of these devices will have its own OMEMO identity created and assigned, with prekeys published on the server. This process also applies to Regenerate OMEMO identities. Over time, you may obsoleted some of the devices and not using them anymore. It is good to just perform Purge unused identities to clean the info stored on the server; Otherwise new device setup will fetch all identity keys including the inactive devices. You also need to perform Purge unused identities when your buddy is having problme to setup an OMEMO session with you.

    OTR Messaging
    [20190716] What are the OTR version supported by aTalk? { Content }
    aTalk OTR implementation only support OTR versions V1, V2 and V3. During OTR setup, aTalk will attempt to use the highest possible OTR version that your buddy installed client can support.
    [20190716] Why the OTR option is grayed out in my chat session menu? { Content }
    aTalk has an OTR option to control how OTR session should be handled. The option is user selectable in the main menu "Settings... | Messaging Security" [OTR MESSAGING SECURITY] section.
    • Private messaging: The option must be enabled to allow you to initial an OTR chat session. Otherwise OTR option is grayed out in the chat session crypto menu; and you will not be able to initial an OTR session.
    Even with the OTR Private Messaging disabled, aTalk continues to litsen in for any incoming OTR session setup request from your buddy. On received an OTR session request, OTR session will be setup and ready to receive OTR encrypted messages from your buddy. Unlike Omemo, OTR session support is not possible with an offline contact. aTalk hides the OTR option when it detects the contact is offline.
    Note: Omemo session has priority over OTR. If your buddy attempts to initial an OTR session while an OMEMO session is in progress, aTalk will block 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 capability 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. for aTalk features discovery
    [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.
    • Back-To-Chat: Click to switch to start the message chat
    • Speaker-Phone/Volume: Enable or disable speaker mode. Long Press to adjust incoming audio volume
    • Mute/Unmute-Mic or Mic Gain: Mute or unmute mic. Long Press to adjust mic gain
    • Video-Call: Turn on/off camera and video streaming. Long press to toggle between front and back camera
    • Call-Hold: Hold call - pause both audio and video media streams
    • Call-HangUp: End the call. Note: BackPress button does not end call
    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.
    • Back-To-Call: Click to switch to call that is in progress.
    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.
    • Back-To-Call: Click to return to media call that is in progress
    • Speaker-Phone: Click to route incoming audio via phone receiver piece or speaker
    • Mute/Unmute-Mic: Click to mute/unmute mic
    • Call-Hold: Click to hold/unhold call
    • Call-HangUp: Click to end the call
    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.
    • Gateway: A service on the Jabber network that translates between the Jabber/XMPP protocols and the protocol used by a Legacy Service (non-XMPP instant messaging service etc); in this context, "gateway" means a "client proxy service" that acts as a client with regard to a Legacy Service and thereby "masquerades" as a user on such a service.
    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
    • XEP-0166: Jingle This specification defines an XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards.
    • XEP-0167: Jingle RTP Sessions This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video.
    • XEP-0115: Entity Capabilities The specification defines an XMPP protocol extension for broadcasting and dynamically discovering client, device, or generic entity capabilities. Service gateway must support <feature var='urn:xmpp:jingle:apps:rtp:audio'/> and/or <feature var='urn:xmpp:jingle:apps:rtp:video'/>
    • XEP-0100: Gateway Interaction It specifies best practices for interactions between Jabber clients and client proxy gateways to legacy services; but disco#info must be updated to confirm to XEP-0115
    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
    • Telephony Domain: The override domain name when making telephone call. If Jabber account is able to make call using PSTN number; but the domain name of the telephony switch is different from the service domain of the account e.g. pbx.domain.org for telephony call instead of the service name domain.org. Then you can use this field property to define the switch domain e.g. pbx.domain.org. When this field is not defined, aTalk uses e.g. 87456078@domain.org as contact to make call via the server pbx switch.
    • Domain that will be using GTalk call: When not null, this domain name will be used when making telephony call from user account containing "google.com". If the value is not defined for "google.com" account, then the default "voice.google.com" domain will be used instead.
    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.
    • From the main menu, select "Account settings ... | Refresh persistent stores
    • Select "XEP-0084/XEP-0153: Avatar" option and Apply
    • Exit and relaunch aTalk
    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.

    General
    [20190607] 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 are in love and cannot part with your old android devices.
    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 exception 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.
    [20190716] aTalk - android OS API compatibility { Content }
    Android requires all new apk releases in 2019 with jni native libraries must support 64-bit architecture. aTalk v1.8.0 released on 20190413 has included JNI native libararies supports for the following ABIS i.e. armeabi-v7a, arm64-v8a, x86, and x86_64. This release has also fixed the Text Relocations problem reported earlier (Enforced for API level >= 23).
    aTalk uses many third parties libraries; some of these libraries have migrated and dropped support for lower android OS. In order for aTalk to continue using these libraries, it must tag along with these libraries migration paths. Starting with aTalk v2.0.0 release, the min android OS support has moved to KitKat-v4.4 or API-19. All aTalk releases have been tested to run on android-9.0 (Pie) or API-28.
    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 acknowledgment 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.