Antisipate, our first GNU Free Call client, is not like most other sip user agents. We have chosen to simply the operation of the agent, and make it more chat friendly, rather than trying to simulate a “telephone” ui, like many do. We are looking to support functionality for voice, video, chat, file, and screen sharing in a single client, and secure end-to-end media with GNU zrtp. This should give some idea of what this client may look like and where we are going with the ui design, as well as offer an opportunity for others to consider and offer improvements in what we are trying to do.
Login is very simple. If you have sipwitch on a local server, it is even almost automatic, as we use zeroconf. Otherwise, saying firstname.lastname@example.org for an identity will also work, especially if there is a srv record for the somewhere.somedomain, or that is a fqhd of a sip service. This was meant to truly simplify sip. I remember the first time I setup a sip account with Twinkle, there were more than a half-dozen options that had to be set, and most other sip ua’s have not improved much over that. All I believe that is needed is the identity and the secret, and the rest can be determined as needed.
While not shown here, there is also a tray icon. Antisipate is a tray application, and will minimize to it. Eventually tray icons will be used to convey current application state, and we will make use of osd notifications.
The main UI would be an address book and a text bar to enter what you are dialing. It either defaults to dial or chat mode, depending on view. In chat mode, it creates an instant message session with an arbitrary uri. Antisipate would fill in sip:…@somewhere.somedomain if an incomplete uri is entered to reference other people on the same server as you. When we populate the address book, one will be able to also click on entries in that directly.
The address book itself is to be composed both of “bookmarks”, which are just stored uri’s with a speed dial they are mapped to, and sip “subscriptions”, which give live status. Ultimately both of these will also reside in sipwitch, so one can subscribe to a users own roster, and receive both through notify messages back from sipwitch. This will make the roster live with the user identity on the server, rather than stored locally with each client you have.
When a chat or call session is created, each instance will have it’s own active ui. For pure chat sessions, the voice related options will be hidden, expanding the text space. Pure chat sessions can be converted to sip call sessions through the call button. For incoming sessions, the “Call” button becomes “Answer”. For ZRTP there is space for presenting a sas. We also are going to try to have avatars within sip.
The lock icon will be used for setting otr sessions. Yes, I think otr, or at least some means of strong and effective cryptographic privacy, is a fundamental requirement for any Internet connected chat system these days, and systems that fail to provide for this completely fail for their users.
This should give some idea of what antisipate will be like, and how it’s ui will operate. Our goal was simplicity. We already have worked on packaging for Debian. One reason was to make sure that it is possible to get antisipate in before Jessie freeze. Similarly, we think Antisipate may be ready to introduce into Fedora in the time-frame of F21. If this appears to be the case, we will likely propose a changes for this for Fesco to consider along with by then sipwitch 2.0.