Frequently Ask Question (FAQ)

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

aTalk UI desgin & Implementation

Account Setup & Login

Enhanced Features

OMEMO Messaging

OTR Messaging

Media Call Communications

User Avatar

General


aTalk UI design & Implementation
[20200619] aTalk UI design & Implementation { Content }
In aTalk UI design, user interaction with the application uses mainly android device touch screen and gestures to navigate or access to other menu. Generally aTalk uses the following gestures and click actions to access to other part of the menus.

Main user UI:
Use slide left/right gesture on the main menu to access to the following pages i.e.:
Chat Sessions ViewPager:
Whenever user opens a new chat session, the chat session view is automatically added to the chat session viewPager group. All the active chat sessions remain in viewPager until user closes the chat. When there are more than one active chat sessions, user may navigate between all active chat sessions by slide right/left gesture to navigate without exit the chat session view.
Heads-up Notification
Both aTalk incoming call and incomming message use anroid heads-up notifications as UI interface for user action. In order for these two heads-up UI's to work properly, user must ensure the android notification popo-up is enabled. Please refer to the attached screenshot for the correct android notification settings.

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 will 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 experimental 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 Security Settings for a list of trusted CA certificates.
Please refer to the following sites for more information:
[20200228] XEP-0178: Best Practices for Use of SASL EXTERNAL with Certificates for client authentication (experimental) { Content }
XMPP standard allows the use of any SASL mechanism in the authentication of XMPP entities. aTalk supports use of the SASL EXTERNAL mechanism with PKIX certificates for client to server authentication, especially when an XMPP service indicates that TLS is mandatory-to-negotiate. During the stream negotiation process, an XMPP client can present a certificate ("client certificate"), included with zero or more than one JabberID encapsulated as id-on-xmppAddr Object Identifier i.e "xmppAddr".
The SASL EXTERNAL authentication method requires a digital client certificate. This digital certificate should contain xmppAddr field(s), which is always checked first. If there is more than one JID specified in the xmppAddr fields, the client must include the authorization entity which corresponds to the one of the specified JIDs. When no xmppAddr is specified, the cn (common name) field might be used to provide client's username. If the client certificate does not contain a JID, the client must provide one in authorization entity. For the details of the "xmppAddr" usage, please refer to XEP-0178 Best Practices for Use of SASL EXTERNAL with Certificates.
Self-signed certificates for regular TCP/TLS connections: If your xmpp service accepts self-signed certs for connection, you may use the following method to generate the client certificate:
Adding client certificate to keyStore: After the generation of the certificate, you need to add the client certificate to android keystore for use by aTalk.
Enabling client certificate:
Note: Your xmpp server must support and configured to accept client TLS certificate authentication via SASL EXTERNAL mechanism.
[20191102] Bidirectional-streams Over Synchronous HTTP (BOSH) with Proxy support { Content }
Bidirectional-streams Over Synchronous HTTP (BOSH) is a transport protocol that emulates a bidirectional stream between two entities (such as a client and a server) by using multiple synchronous HTTP request/response pairs without requiring the use of frequent polling or asynchronous chunked responses.
Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It is used for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS), or formerly its predecessor Secure Sockets Layer (SSL). The protocol is therefore also often referred to as HTTP over TLS or HTTP over SSL.
Most companies restrict their internet access for their employees with a firewall and proxy. Normally only port 80 (HTTP) and 443 (HTTPS) are opened, which means no access to the xmpp port 5222. With aTalk xmpp client, you can tunnel through the firewall to reach your desired xmpp server via BOSH connection.
For Bosh to work on aTalk properly, the xmpp server certificate must be issued by Certification Authority (CA) trusted by android. The trusted CAs list can be accessed via View security certificates in android Setting. If android OS detects an untrusted certificate during network connection, it will deny access via https:// scheme protocol, and BOSH connection is not possible. Starting with Android 9 (API-28), cleartext support is disabled by default. BOSH connection via http:// scheme protocol is not supported by aTalk on these devices.
aTalk client supports the following BOSH standards:
Below gives a brief description on how to setup BOSH for an xmpp user. From aTalk main menu, select Account settings.... Follow the instructions herein on how to create a new account. By default aTalk will connect to the user server via XMPPTCP connection on first login. You will need to cancel the login prompt upon login failure in order to configure the BOSH settings.
  • On returning to the account list, click on the newly created account.
  • From the account settings menu, select BOSH-Proxy Configuration to setup connection via BOSH/Proxy for the account.
  • The default configuration is NONE. Select BOSH from the Type pull down menu
  • Enter the BOSH URL link e.g. https://example.net:443/http-bind. You need to refer to the xmpp service provider to find the correct setting.
  • If the firewall was your only problem, then you are done with the BOSH settings. If not, you then have to configure the Proxy settings too.
  • There is a checkbox Use HTTP-Proxy in the dialog when you enable BOSH option. Choose this checkbox and enter the proxy data. Enter the authentication info if needed. Leave both the Username and Password blank if proxy authentication is not required.
A proxy server is a dedicated computer system or router that acts as an intermediary between an endpoint device, such as a computer, and another server from which a user or client is requesting a service. Proxy servers are used for the following purposes.
In the enterprise, a proxy server is used to facilitate security, administrative control or caching services, among other purposes. In a personal computing context, proxy servers are used to enable user privacy and anonymous surfing. Proxy servers can also be used for the opposite purpose: To monitor traffic and undermine user privacy.
To the user, the proxy server is transparent; all Internet requests and returned responses appear to be directly with the addressed Internet server. The proxy is not actually invisible; its IP address has to be specified as a configuration option to the browser or other protocol program. You may use and setup proxy only if you do not need BOSH connection
  • In this case, select NONE in the Type pull down menu
  • Then enter only the proxy settings as required.
  • Enter the authentication info if needed. Leave both the Username and Password blank if proxy authentication is not required.
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:
  • If you selected IBR but entered mis-spelled user name or password during login, aTalk will also prompt you with an IBR dialog even the account already exists on the server. For security reason, xmpp server always throws the same exception i.e <not-authorized/> for both "Invalid username or password" and "non-existence" account on server.
  • Server will reject IBR registration for an account already exists on the server with: "XMPPError: conflict - cancel: User already exists" or similar. Click OK and aTalk will prompt you with the login screen. Check your password entry before trying to login.
  • Many of the xmpp servers have a default connection timeout of 30 seconds, therefore you need to response to the Captcha challenge within this time period. When timeout happens, just click OK to retry
  • Password Strength: Minimum informational entropy for passwords. The value Entropy is a number of bits of entropy. The recommended minimum is 32 bits. Server will reject weak password entry. Just click OK to retry with new password entry.
  • Registration Timeout: This limits the frequency of registration from a given IP or username. So, a user that tries to register a new account from the same IP address or JID during this timeout after his previous registration will receive an error resource-constraint with the explanation: “Users are not allowed to register accounts so quickly”. Default value is usually 600 seconds. You need to try it later after the registration timeout has expired.
[20191002] Google Talk account setup { Content }
Note: Google server has its own xmpp implementation which may not compliant fully with the standard XEP standards. You may found that certain features are not supported e.g. Omemo messaging. Therefore it is not encouraged for user to use aTalk to sign in to the google server. You may send chat messages to another Google account login using google own Hangouts app.
To setup a Google Talk account on aTalk, follow the steps below
  • From the main menu, choose Account Settings... | Add new account.
  • Enter your goole gmail account and the regular password as shown above.
  • Click the Sign in button.
  • If you have previously set up Two-Step Verification for your Google account and try to log in with your regular password, you may receive an error message like the one shown on the right.
  • To allow log in from aTalk, you need to generate an application-specific password. For instructions see Sign in using application-specific passwords
  • Enter the App password which is a 16-digit passcode, exactly as provided including the spaces into the password field, and click Sign in.
  • You should now be able to chat and make media call with another Google account signed in using aTalk.
  • The media call option is not available if your buddy is using Google own client e.g. Hangouts. This is because Google Hangouts does not advertise its media call capability via XMPP discovery protocol. However your buddy on Hangouts can initial a media call with you.
[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 android 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 Verification.. You can proceed with login by clicking on the Proceed 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 Proceed 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.
  • Select Account Owner: This spinner will list all your registered user accounts for selection. Select one of the registered users to assign the new contact to.
  • Contact JID or Number: Here you specify the contact Jabber (without the resource), whose presence status ou like to subscribe.
  • Contact Assign Group: You can group for new contact to your existing group or create new. Click on the selector for a list of options.
  • Contact Display Name: The new contact name you would like to show on your contact list. aTalk uses the Jid if you leave this field empty.
  • Add Button: Click on Add button once you have entered all the new contacts properties.
  • Cancel Button: Click Cancel to abort the request and discard all the information entered.
Click on the Contact Assigned Group selector will bring up the group assigning options.
  • No group: Any unassigned contacts will be group under default Contacts group.
  • atalk member: Any existing groups will be listed here for selections.
  • Create group: The "Add Contact" dialog provides the option to categorize your new contact to one of your existing defined groups or a newly created group.
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 remote 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 (FQDN) 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 acknowledgment 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 Subscription 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 member to manually subscribe 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 continuous 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 longitude and latitude 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 real time.
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:
  • Allow your love one at home to virtual travel with you while you are visiting places on tour. Sharing nice scenery viedo without consumming big data usage.
  • When you are back from traveling, you can play back the location messages. A sweet memory recall or share with friends of all the places you have visited.
  • Lost your way while visiting your friend? Just share your gps-location and start a voice call. Your friend can guide you until you have safely arrived at the destination.
  • In the remote chance that you are in trouble; just start the continuous location update to activate the location streaming. Your love one can track your location and help will be on the way.
  • standalone feature without sending location messages: Travel alone and lost your direction bearing? Just enable the feature, realign your current location and direction using the streetViews and map information. This should help you to avoid unnecessary walking in the wrong direction.
[20200330] XEP-0045: Multi-User Chat { Content }
Multi-User Chat (MUC) or group chat protocols are defined in XMPP XEP-0045 specifications; several users participate in room discussion can exchange chat messages at the same time. aTalk implements most of the room common features for MUC messaging. Please refer to XEP-0045: Multi-User Chat for more information. Followings are few of the terminologies pertaining to MUC operations.
  • Invitation: A dedicated message that is sent from one user to another asking the recipient to join a chat room. aTalk displays this invitation message as shown on the right, to the recipient for his/her action.
  • Room Member: A user who is on the "whitelist" for a members-only room or whom has been registered with a MUC room.
  • Members-Only Room: A room where a user cannot enter without being on the member list. Only the room owner or room configuration that has granted the privileges to member can invite user to join the member-only room. An non-member attempts to join will automatically be rejected by the room management. To support OMEMO message chat, the room must be configured as members-only room
  • Persistent Room: A room that is not destroyed by server even the last occupant has exited.
  • Occupant: Any user who is in a room, uses <room@service/nick> by which an occupant is identified within the context of a room.
  • Participant: An occupant who does not have admin status; in a moderated room, a participant is further defined as having voice, in contrast to a visitor.
  • Room Owner: The user who has created the room or a user who has been designated by the room creator or owner as someone with owner status; an owner is allowed to change the room configuration and destroy the room, in addition to all admin status.
  • Discussion History: Depending on service policy or room configuration, a room may send discussion history to the newly joined 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. aTalk can receive and display all the history messages, while removing any previously received duplicated messages.
    Note: When a group chat is setup for OMEMO chat messages, the history messages which are sent to a newly joined participant cannot be decrypted nor displayed, as the history encrypted messages do not contain the rid key information. The rid key is required to decrypt an OMEMO encrypted message.
From the contact list, sliding left will show a list of the chatRooms or none. These are the rooms where you have being actively participated in group discussion. A room item is added to this list; either when you joined the room via invitation or you have manually created the room for group chat. From within the group chat session, pending your designated role in the room, you may not have all of the room options as shown on the right, listed in the pull-down menu.
  • Invite: While in group chat session, you may select this option to invite new participants to join the chat room. An invitation message will be sent to each of the invitees you have selected. The invitees may accept, reject or ignore the invitation. Except for ignore option selected, the accept or reject response from the invitees are displayed in the chat window.
  • Send GPS-Location: aTalk supports sending a GPS message of your current location to all the occupants in the room if so desired.
  • Erase this chatRoom history: Purge all the chat messages in the current room. This action is irreversible.
  • Leave chatRoom: Leave the group chat discussion. After you have left the room, the room item will also be removed from the room list.
    Note: If you leave a members-only room, you may only re-join the room via an invitation from member of the room, or you are the room owner.
  • Destroy chatRoom: Only room owner can destroy a chat room. Otherwise you will receive an error message and given an option only to remove the room item from the room list.
  • ChatRoom info: Provide a list of the chat room properties of the currently joined room. Note the list does not necessary list all the room configurable items.
  • ChatRoom info change: Change the chat room info i.e. nick and room subject only if allowed in room configuration settings.
  • ChatRoom configuration: Only room owner can change the room configuration settings. When selected. a room configuration form as shown on the right is displayed. The option list may varies pending on server implementation. After all the changes, you must submit the changes to the server to take effect.
  • ChatRoom occupants: Anytime during the chat session, you may select this option to query a list of the occupants currently have active participation in the room. The list is displayed in the chat window..
The privilege of a registered user to create a new room on server is defined by the XMPP server configuration set by the administrator. In aTalk, with the right privilege, you may create a new room using one of the two methods described below.
Create / Join Chat Room: Select this option from the main menu to create a new or join an existing room on the server. You need to provide a Nick Name, if necessary update the room subject if permitted pending room configuration settings. You must also provide a valid password when the room is configured with password protected. Check the Save password if you do not want to re-enter the password whenever you rejoin the room at a later time. If you edited the room name in the selector, aTalk will proceed to create a new room when you click the Join button. The creation of a new room may fail if you do have the privilege to do so.
Converting 1:1 chat into a group chat: While in a chat session with a buddy, there may a need to have more people to join the dicussion i.e. convert a 1:1 chat session into a multi-user conference. To do this, just select Invite option from the pull-down menu; you then add the existing buddy and other contacts to the chat room. A new chat room will be created, and invitation sent to all the participants selected.
Note: the chat history discussed thus far prior to the new room creation are not sent automatically under this case. User needs to perform copy and past of any message to share if so desire.
Room configuration: By default, all new rooms created by aTalk support OMEMO chat, hence it is designated as members-only room. However after a new room has been created, you may procced to change the room configuration as required e.g. to include pasword protection and make it a persistent room etc
Note: If you attempt to join a member-only or not public room while 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 owener.
[20200330] 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 duplicated 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 left to the chatRoom list after login, the chatRoom list will be populated, with all the chatRooms you have once joined previously, tagged with bookmarks that you have previously saved (from another client) on server. aTalk auto joins chatRoom if the autoJoin option is enabled in the newly downloaded bookmarked room 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 selectable options.
  • autoJoin: Toggle the autoJoin option on/off. The autoJoin state will be saved to bookmark on server if the bookmark state is on/enabled.
  • bookmark: Click on the icon brings up the bookmark form for user update.
When you click on the bookmark icon on the chatRoom list item, it brings up the bookmark form as shown on the right for user update. Below provides a brief descriptions of each field in the form.
  • Account: The user account to whom the chatRoom is associated with.
  • Name: A name of the bookmark for human readable information. This information is displayed in the main title of the chat Room list item.
  • Nick Name: The user nick name used when joining the chatRoom. The Nick Name must not be set to null.
  • Password: Password to use to join the chatRoom if required. Leave blank if no required.
  • Bookmark: Toggle bookmark option on/off. When enabled, all the specified chatRoom attributes are saved as bookmark on server. This bookmark is retrieved and applied when user login on another device.
  • AutoJoin: Toggle the autoJoin option on/off. When enabled, aTalk auto joins the chatRoom with the newly specified room attributes. The autoJoin state will be saved to bookmark on server if the bookmark is enabled, and/or use as a local standalone flag to join chatRoomo on next user login.
  • Chat Room: The chat room to which all the attributes in this form belong to. This chatRoom name/EntityBareJid is displayed as the sub-Title of the chatRoom list item.
From the main menu, you may also access to the chatRoom bookmarks. The new form is
similar to the one described earlier for the specific chatRoom; the differences are described below.
  • Account: The user account spinner contains all the users whom are registered on aTalk. When you select a user from this spinner, the Chat Room spinner will automatically be populated with the list of chatRooms that are associated with the selected user account.
  • Chat Room: The spinner contains a list of the all the chatRooms that are associated with the selected user in Account field. The chat room spinner includes all the chatRooms that were previously joined i.e. listed in the chat room list page. In additional it also includes all the chatRooms that are available on the server, were created by all the registered users on server. Pending on each room configurations and privileges inherited; if you enable autoJoin and/or bookmark option(s) on any of these server chatRooms, aTalk will include this chatRoom in the chatRoom list page when you click the Apply button.
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.
[20191004] XEP-0070: Verifying HTTP Requests via XMPP and WebView Implementation { Content }
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 its site 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.
XEP-0070 specification defines an XMPP protocol extension that enables verification of an HTTP request via XMPP. The XEP-0070 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 since v1.8.8 has implemented the XEP-0070 protocol and integrated 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.
Folowing details the steps to show XEP-0070 demo on aTalk.
  • From the [main menu | Settings... | Web Access Page], enter the following site link https://demo.agayon.be/
  • Exit main menu, then slide left until you arrive at the webView page.
  • aTalk will automatic load the defined webpage that you have entered earlier.
  • Click the login link on the webpage, login page as shown on the right will be displayed.
  • In the Username field, enter the xmpp user account that you are currently login.
  • Then clik the Sign In button on the webPage.
  • Via s2s connection, the visting site sends the XMPP Server Requests Confirmation via XMPP protocol. Pending whether the entered user account ends with/without a resource; the site sends either an IQ stanza or a Message stanza request to the login entity.
  • Http Authorization Request as shown on the left is returned if you have entered the username ends with a resource. A similar one will be shown if the username is entered without a resource attribute, its dialog content is defined by the site admin. The demo site actually supports client that does not implement XEP-0070 to just reply chat message with the ID for authorization confirmation.
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 sitez address as defined in the main Settings....
The purpose of the WebView is to allow an organization to display its official web page. The page can be used to provide the organization 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 Contact list page. This is to trigger android OS to invalidate the last accessed 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 keyboard. The Google Gboard keyboard 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:
[20200714] aTalk Fault-Tolerance File Sharing Implementation & Enhancements { Content }
aTalk supports send and receive files for all document types and images. There is an option to enable thumbnail preview for media file 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 larger than the 'Auto accept max file size'. The actual file is sent upon acceptance by your buddy. aTalk allows automatic acceptance of file transfer request or stickers sending if the size of the file to be transferred is less than or equal to 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. During file transfer negotiation, aTalk uses the agreed SI protocol for sharing the file. However if the agreed SI protocol method failed for reason e.g. client symmetric NAT firewall, aTalk automatically fallback to use HTTP File Upload service 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 faciliity, 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' protocol. During an OMEMO chat session either in 1-1 or muc, all file sharing will be encrypted 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 succcsfully 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 previously selected the Reject button, either intentionally or unintentionally. To remove the prompt, user must manually select and delete the link message/prompt.
[20200417] Text to speech and speech recognition in chat/groupchat session { Content }
aTalk supports speech synthesis from an incoming chat messages for immediate playback during chat or group chat session. To allow speech syntehsis on an incoming message, user must enable both the global TTS and the specific chat session option for speech playback. The global TTS option is accessed via the main menu General TTS settins.... The main TTS settings menu provides the following options:
  • Default TTS voice: displays the current selected voice speech. During playback of the text message, android auto-detect the text language type and playback with the correct spoken language. However android will playback language independent text e.g. 140,000 in the default selected language voice.
  • Message Text to Speech delay (ms)In android, all notification alerts always have higher priority over any other media including the speech playback. aTalk waits for this specified delay (ms) before starting the text to speech synthesis. If you enable and change the incoming message alert to other than the default, then adjust this duration until the start of the text speech is not being clipped by the alert.
  • Enable Text ➡ Speech You must check this global option to enable TTS feature on aTalk. If you do not enable this global option, then the Enable/Disable Text ➡ Speech option for the chat or group chat session will not be available for user selection.
  • General TTS settings... Select this option to enter the android OS Text-to-speech output configuration menu as shown on the right. The menu allows user to select his/her desired voice output, the playback rate and pitch of the speech. If the user selected language resource is not found on the device, android will procced to download the required voice synthesis files. Other More advance voice options can be accessed via the Setting icon. Click the Play button to play back a short demo message.
  • Demo text entry box:
  • User may copy some longer message text from e.g. web browser and paste them in this entry box, to be playbacked or coverted and save into a voice file.
  • Save Save the demo text synthesized speech into the a voice file.
  • Play Playback the demo text using the user default selected voice output
  • OK Exit the user configuraton settins menu.
After you have enabled the global TTS option from the main menu, you may now procced to enable/disable the TTS operation for the individual chat or group chat session. To enable TTS feature for the desired chat session, long click on the specific contact or chatroom item in the respective item list diplay; a pop-up menu will appear containing the TTS toggle option for user selection. This TTS enable/disable option is also available during the chat seesion access, that is accessed via the chat session main pull down menu.
When a chat/group session has the Text to Speech option enabled; aTalk automatically synthesize any incoming message text to speech, and playback after the specific delay. When you tab on the message text in the incoming or outgoing message view holder, the selected text will also be playback in synthesized voice.

Speech Recognition Input
aTalk supports input of message text via speech recognition. Voice input recognition can be acheive with either of the methods described below.
  • Soft keyboard mic input: This method is always available even without the Global TTS being enabled. When user click in the text entry box, android soft keyboard is activated, together with the voice input option for user selection. Click on the mic icon will bring up the voice recognition input menu. In this mode, user has full control on voice input for voice recognition and place each captured text in the enry box. User may pause the speech at any time, make correction to the text and continue. If the neccessary, edit the caputed text before sending the message.
  • Direct mic input: If you have enabled the TTS option for the chat session, just click on the mic icon next to the text entry box; this is a quick access to the speech recognition mode with opening a soft keyboad. During the flashing of mic, any user voice is converted to text input. Voice recognition process stops when it detects a user long pause. In this mode, user has only one time to speak to input text. If you need to input more text, then active the soft keyboard mic as before. Edit the captured text if necessary before seding.
[20191218] Share, Quote and Forward of messages and media contents { Content }
aTalk supports messages and media contents sharing either from an external application or sharing with an external application. Within aTalk app, it also supports features like Quote of message in reply, and Forward of contents to contacts within aTalk application.
aTalk can receive simple data from other applications with the various MIME types i.e. text/*, image/*, video/*, application/* etc. After you have selected the contents e.g. from web browser or media picker, click the sharing tool if supported by the application. aTalk will be listed as one of the app in the chooser for user selection. On choosing aTalk, the UI as shown on the right is displayed. From here you can select the contact to share. On return to the same UI after sharing with a contact, you can select another contact to share the same contents. Once you have done with sharing the contents, just press the BackKey or click the Done action icon in the action bar.
From within aTalk app, while you are in a chat session, following actions are possible with the selected messages or media contents. Below provide a brief description on each of the action icon and its supported function starting from left to right.
  • Edit: Last sent message correction edit. If the selected message is the last sent message, click on this icon to perform the last message correction. You may also just click on the last sent message to access to the message correction option.
  • Quote: Quote the selected message in the reply message send to a contact. The image on the right shows the quoted content that is displayed on the contact received message.
  • Delete: Purge the selected messages and media contents from database. Media contents deletion is only performed if user enable the Delete Media option in the confirmation dialog. aTalk will not delete any sent media file unless it is a voice message file or media file in tmp directory created by aTalk app.
  • Share: Share the messages and media contents of a user to an external application. You may select messages and/or media contents from the chat window to share with an external application. Android allows only one type of content i.e. text or media content to be shared at any one time. If you have selected both the messages and media contents for sharing, aTalk will start with text message sharing followed by the media sharing. Upon chosen the app for text sharing by user, aTalk will wait for 6 seconds for user to complete the first transaction before launching the chooser for the media contents.
  • Forward: Forward the messages and media contents of a user to other contacts within aTalk. The operation is similar to Share option. However forward operation does not have time bound. Text message will be shown for edit and send, followed by media contents. User is allow the share the same selected contents to more than on contacts. In both Share and Forward operation, all the selected messages are merged into a single text string before sending.
  • Copy: Copy all the selected messages text and merged all messages into a single text message before placing it on the clipboard for pasting.
  • Select All: Select all the messages and media contents that are currently visible in the chat view window.
[20200619] aTalk Heads-Up Notification and Quiet-Hours { Content }
Notifications Overview: A notification is a message that android displays outside the app's UI to provide the user with reminders, communication from other contact, or other schedule information from the app. Users can tap the notification to open the app or take an action directly from the notification. Following android notifications applied to aTalk:
Status bar and notification drawer: Please see aTalk Notification Events for the support and configuration of aTalk individual notification.
Heads-Up Notification: Starting with aTalk v2.2.0, it has added support for the android heads-up notifications; with options for 'Reply', 'Mark as read' and 'Snooze'.
Note: To allow aTalk heads-up option to work correctly on devices with android-N and above, user needs to ensure android [Settings | Notifications] for aTalk is configured as shown in the screenshot on the right. i.e. both the Alert and Show as pop-up options must be checked for the Chat Message Notification notification category.
Quiet Hours: User can defined the quiet hours period for all the aTalk notification. During the quiet hours, all alerts are muted for all the aTalk notifications. Quiet hours does not apply to heads-up pop-up floating window.
[20200619] aTalk Notification Events { Content }
aTalk provides support for user to fine tune the notification actions for each of the events as shown in the screenshot on the right. Starting in Android 8.0 (API level 26), all aTalk event notifications must be assigned to a channel. See Create and Manage Notification Channels. For each channel, user can set the visual and auditory behavior that is applied to all notifications in that channel. If you disable any of the android notification channel, all aTalk notification events which are assigned to that channel will also be disabled. In addition to the android notification channel grouping, android also added its own playback sound and vibrate option for that channel. The android playback sound must be set to silent in order not to mix with the atalk playback sound. You may enable the android vibrate option if it is not defined/unavailable in aTalk.
Each notification event state can be set to active or inactive by toggling the button next to the event. Click the event title for more event setting options. Pending on the type of notification event, each notification event may be associated with one or more actions that are to be performed when the specific event occurs.
Starting in Android 8.0 (API level 26), android has enforced that all notifications must be assigned to a channel. For each channel, user can set the visual and auditory behavior that is applied to all notifications in that channel. Users can change these settings and decide which notification channels from the app should be visible at all. In aTalk implementation, users are given full control to all the notification evetns as explain above. You may ignore the android notification channel.
[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:
  • Disabling Doze & App Standby for aTalk: Settings - Device maintenance - Battery - Unmonitored apps
  • Settings - Wi-Fi - Menu - Advanced - Keep Wi-Fi on during sleeps
  • Settings - Wi-Fi - Menu - Advanced - Wi-Fi power saving mode
[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)
  • aTalk ping the server at the regular interval as specified e.g. 300s
  • When ping to server failed for 3 consequetive attempts @10s interval i.e. to take care network fading
  • Lower and use new Ping Interval i.e. use step size of -30s if >240s, else use step size of -10s
  • Stop optimization if no further ping failure is detected or until min Ping Interval of 120s is reached
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.
[20200113] Android Battery Optimization & Run-time 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.
  • Camera - for video call or capture picture or record video for sharing
  • Contacts - needed for phone state access and call setup e.g. telephony
  • Location - GPS SteetView and Map display for a 360° panoramic view; Location sharing with buddy. Note: Fdroid version does not support Location sharing.
  • Audio - audio chat, voice and video calls
  • Phone - phone features support - telephony gateway
  • Storage - Access to android local storage for saving aTalk vital operational data and files. aTalk will fail unexpectly if this basic permission is denied.
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.
Disabling Doze & App Standby for aTalk
Battery optimization is a function (known as Doze) built into Android 6.0 Marshmallow and above. It preserves battery life by limiting what apps can do when the device is in standby (doze mode). You must not put aTalk under android battery optimization. Otherwise android OS will put aTalk to sleep (offline) when the device is in standby mode. When this happen, aTalk will not alert you when there are new messages sent from your buddy. All messages will be delayed and received as offline messages when aTalk is online again. Your buddy cannot set up media call with you as aTalk appears offline to the buddy.
Whenever user launches aTalk on Android-M or higher, aTalk will alert user if it detects aTalk has been put under android battery optimization. Click Next and select Allow on android prompt.
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
[20200714] 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 client's registered server and the server of your chat partners must support PEP (XEP-0163) to store and exchange key bundles. Optionally your server should also 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.
  • Member Ony (Non-Anonymous) Room: OMEMO encryption is only available in a room in which each occupant's full JID is exposed to all other occupants; Contrast with Semi-Anonymous Room, OMEMO option is greyed out, as occupant's full JID can only be discovered by room admins only.
aTalk checks both server and client 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. aTalk then retrieves the buddy OMEMO devicelist data published on the server. This info is published by client that support OMEMO.
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)
Note: During the server and client OMEMO capability discovery process, the server must respond to aTalk query within a time-out grace periond of 5 secods. Otherwise OMEMO option will also be disabled.
[20190916] 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 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
[20191102] 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. In order to have media call with your contact, your buddy installed xmpp client must also support the required media call services. The buddy media call supported capablities will be shown as icons next to the contact name in the list. To make video or voice call with your buddy, just click the appropriate media call icon next to the contact whom you want to make call with.
During aTalk initial start up, each buddy device will send its supported features via capability version-hash embedded within its <presence/> stanza. aTalk then performs check on each buddy supported features via service discovery (XEP-0030) protocol request; and enable only the respective media call options that are supported by your buddy xmpp client. Therefore it is necessary for your contact xmpp clients to support XEP-0115: Entity Capabilities, version 1.5.1.in order for aTalk proper features discovery. Without which, the call icon option will not be shown even if your buddy's client supports media call. In this case, the call can only be initiated from your buddy; aTalk will response and take the call.
While you are in a chat session, you may also make call using the pull down menu as shown on the right, if you buddy client supports the media call services.
[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.
  • SRTP: Secure Real-time Transfer Protocol enhances security for RTP and provides integrity and privacy for RTP media connections. To use SRTP in an efficient way, VoIP applications should be able to negotiate keys and other parameters automatically.
  • ZRTP: Media Path Diffie-Hellman session key exchange Agreement for Unicast Secure RTP, is a protocol that negotiates the keys and other information required to setup a SRTP audio and video session, without additional infrastructure, server programs, registration, and alike. It indicates to the VoIP user if a session is secure or not, inform about problems and thier severity. ZRTP cannot automatically authenticate the end-users, this is task of the users once they can talk to each other.
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.
  • Encryption protocols: ZRTP will detect any MITM (Man In The Middle), whereas DTLS versus SDES will not. Generally select ZRTP > DTLS > SDES in this preference order
    • ZRTP: The key exchange negotiation happens in the media stream, except that rather than rely on TLS for the establishment of keys, Diffie-Hellman key agreement takes place and key verification is done by verifying "fingerprints" in the form of short strings. You can think of this as the voice equivalent of OTR
    • SDES: Session Description Protocol Security Descriptions for Media Streams and is a way to negotiate the key for Secure Real-time Transport Protocol.
    • DTLS_SRTP: This is another way to negotiate keys but rather than use an extension to SIP to do it, SIP simply indicates the media stream uses DTLS-SRTP and key negotiation happens in the media stream. Key negotiation happens as in TLS and thus relies on PKI.
  • SDES cipher suites: Simplified Data Encryption Standard, the process of encrypting a plain data to an encrypted data stream with the use of SDES cipher as defined below
    • AES_CM_128_HMAC_SHA1_80:
    • AES_CM_128_HMAC_SHA1_32:
    • F8_128_HMAC_SHA1_80:
  • RTP/SAVP indication: This setting is effective only when SDEP SRTP encryption is enabled and is used to specify whether the use of the RTP/SAVP profile by the VoIP should be <off>, <optional> or <mandatory>
    • Off (indicate RTP/AVP only): off for backward compatibility
    • Mandatory (offer and accept only RTP/SAVP): When this setting is set to "mandatory" aTalk will offer and accept only SDPs that contain with an audio profile of RTP/SAVP.
    • Optional (offer RTP/SAVP first, then RTP/AVP: When this setting is set to "optional", aTalk will offer SDPs containing i.e. one with an audio profile of RTP/SAVP the other with an audio profile of RTP/AVP and it will accept SDPs containing with either profile. The RTP/SAVP profile, being the preferred one, is listed first
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.
  • Use ICE, Use UPnP & Use jingle nodes: It is good ideas to check all these options so as to facilitae higher possibliity of a succesful media connection.
  • Auto discover STUN/TURN servers: When this option is checked, aTalk will attempt to discover STUN/TURN using service domain from the user account i.e. via SRV records fetching. You should NOT enable this option if the account service domain is a virtual host, and cannot be resolved to a valid IP for actual network connection. An unreachable service domain will introudce an unneccessary delay of ~40Sec due to internet address validation during call setup. If user account service domain is a valid internet address, but does not support STUN/TURN, it is recommended that you disable this option. If you found that aTalk takes a long time to startup a call, you may try to disable this option to see if there is any improvement.
  • Additonal STUN/TURN servers: Allow user to define additional STUN/TURN servers for use as ICE Agent Candidate Harvesters. You may enter FQDN or the server IP address in the IP Address field. aTalk adds this list to the ICE Agent Candicate Harvester after the Auto discover STUN/TURN process has completed. If aTalk found zero user configured or from auto discovered stun server, it falls back to use aTalk pre-defined internal stun servers.
  • Auto discover Jingle Nodes relays: Not use
  • Additional Jingle Nodes: User defined Jingle Nodes with optional media relay support.

User Avatar
[20200214] How do I update my user avatar? { Content }
aTalk has an integrated photo editor that supports zoom, scale, rotate and crop functions. This simple tool helps publishing the user avatar an easy task. The following steps describe on how to add an user avatar:
  • From main menu, select Account settings...
  • In Account settings..., click and hold the account to access the context menu. Select Account Info
  • Click on the account avatar near the top-left corner of the account info display page. Then select Choose picture to pick a picture from your storage.
  • This will launch the photo editor and display your selected picture.
  • Use the editor, select, zoom, rotate and crop the image area you want.
  • Click the tick arrow on the top right corner to save.
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 i.e. This does take some times to store the avatar on the server. So be patient when you update your own user avatar.
[20200214] Why some of the avatars for my contacts in main menu are blank? { Content }
aTalk implementation supports both XEP's defined specifications in handling the contact avatars i.e: Your contact device client must use either of these methods to publish or update his avatar on the server.
If you buddy client implements XEP-0084: User Avatar protocol, the server automatic sends an event on avatar hash for the buddy that is stored on the server after you have logged in. If the received avatar hash is different from the local stored avatar hash, aTalk then procceds to retrive the buddy avatar from the server. The avatar hash update event is sent whenever your buddy update his avatar with new image.
If your buddy client supports only XEP-0153: vCard-Based Avatar protocol; the server only sends the avatar hash info embedded in the <presence/> stanza when the buddy is online. If one or more of your buddies are offline when you first login, aTalk will display the avatars that were previously saved in the local store; or the default avatar i.e. blank figure if none is available.
Refresh Contact Avatar: If you want to refresh the avatar of any contact; you may long click on the contact avatar shown in the contact list. aTalk will fetch and update the contact avatar immediately.
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. You may use the above method to update the avatar of the contact. Alternative, 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


General
[20190607] Why aTalk is not working properly on my old android devices? { Content }
aTalk installation requires device with android OS 5.0 Lollipop 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.
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.2.3 release, the min android OS support has moved to android OS Lillipop or API-21. 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.
[20200418] 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 that you experienced problem with aTalk, you can forward this log information to help the developer to identity the cause of the problem, and to provide solutions in the next release if possible.
Android clear all the previoulsy logged info once you have exited aTalk. If you have exited aTalk after encoutered the problem, you need to perform all the steps again that are causing the problem to allow aTalk to re-captured the info. Otherwise the log sent will not have the info of the problem. The log contains only minimum information to help identify the problem. No personnel sensitive inform are being included.
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 and the steps to reproduce the problem happen is important. As the log contains only minimum info, and may not neccessary have the details that pin point the root cause. The description and the steps provided by you can help developer to recreate the problem and capture more log data in a developer software development environment.