Alright, thank you for writing back to me. I will ask a few follow-up questions related to my own needs and information I believe should be documented in the interest of public understanding. I apologise if this is difficult to read but I have not been able to figure out how to use your convenient reply format.
1: I believe you are correct. Is this configuration default? Are the other best-practice implementations discussed on that page already incorporated into Linphone?
2: Understood. I will look into MIKEY myself at a later date if necessary.
3: This is somewhat concerning. The checkbox is clickable in GUI when DTLS is selected, which seems to provide a false sense of security. I don't know how the code is arranged but this interface logic seems inappropriate. Users need the option to specify allowed/required methods in order of preference by default (globally), per server/network, and per contact. This may be easiest to implement in a configuration file for the time being but I would really like to see it in the GUI, at least until SIP encryption methods are more standardised. Encryption status should be displayed on the main window, perhaps unobtrusively at the bottom, and users should be actively notified of potential down-grade events, either resulting from an attack or technical malfunction.
4: That is perfect, thank you. I assume the negotiation prefers the first method to appear and methods not listed will never be accepted. As per the previous topic three, session encryption methods could be configured in the same manner.
6: Ok, I have read about LIME but my understanding of programming and cryptography is fairly poor. If LIME is used for text messages and ZRTP is used for voice/video, do they share the same ZRTP cache? I understand that "secret validity period is not yet implemented" means that there is currently no provision for forward secrecy. This is probably not an urgent priority but I hope it is still on your radar. I actually prefer LIME's similarity to ZRTP over OTR from a logistical standpoint but, assuming LIME is not compatible with OTR, perhaps it would be worth implementing OTR for compatibility since it seems to be the preferred method for other SIP clients.
6.1: I understand that LIME will not actually encrypt anything until the first voice/video call is transacted; this is a significant down-side for users without the technical means to field the initial call, or who would prefer to conduct a conversation exclusively through text. I presume some voice/video data is used to seed the initial encryption key, which would render encryption useless if, for example, the call were muted due to user ignorance; perhaps you could provide a feature to hash this from a different random source and exchange the keys silently and transparently to the users?
7: Composition indication seems to be implemented through "pixmaps", which appears in Linphone's GitHub. Again, I am not a programmer but I would assume this means message composition is supported in Linphone but not through Liblinphone. That said, the feature list for Liblinphone does say that it supports RFC3994. Is this what you meant by "works independently"? Regardless of how it is implemented, I think it would be good to provide for configuration in the same manner as presence in the GUI, since they are logically similar. This is obviously not a priority but some people may not want to let certain contacts know when they are typing, or perhaps they do not want to let anyone know when they are typing. It is a matter of personal _expression_ so it will have implications on user comfort.
8: I understand that Linphone does use Liblinphone. Does "library only feature" mean users need to configure it in the library source code, compile the new library, and then install it? Which header is used in the software available to users on your website?
9: So this would also need to be configured, compiled, and reinstalled to enable/disable, but it is enabled in the software on your website? Do you actually use the method I provided? I found a link (included below) that says you use HTTP as described in section 220.127.116.11 of GSMA's Rich Communications Service P.D.F. Perhaps the information I found is out of date but this method is very different since "...the file transfer is based in [sic] storing the file in a publicly available server and then sharing the location using standalone messaging...". If I understand this correctly, it would mean file transfers are never P2P and may be terribly insecure, depending on what server is used and how it is configured. Perhaps you serve the file from a local HTTPS socket?