External USSD interface development

Dear Harald, In this mail I would like to express my thoughts and ideas regarding to the 'external interface for USSD'. To provide some background for other mailing list members, who are not aware of this topic, I'll explain it in a few sentences. We already have an external interface for SMS - SMPP. But unfortunately, the same cannot be said about USSD. There is no built-in support of any interface, which could be used to handle USSD requests in a separate application. So, at the moment we only handle *#100# (own number request), which is implemented as a part of both OsmoMSC and legacy OsmoNiTB. And if one would like to implement additional USSD commands, it's required to modify and recompile the whole project :/ Fairwaves team already have some draft implementation for legacy OsmoNiTB, which relays on the libosmocore's GSM 04.80 API. And having the external interface in the mainline would be great not only for Fairwaves, but for the whole Osmocom project and its users. The problem is that the current libosmocore's GSM 04.80 API is not complete and requires some critical modifications, which of course cannot be integrated immediately. Moreover, this implementation doesn't follow Osmocom coding style, for example, unlike other functions, where return code rc = 0 means success, there it means error... So, first of all, we need to know, how many projects are using the current API, especially non-Osmocom projects. After that (taking it into account), it shall be decided: - Should we keep the old API / ABI and maintain all new features among with it. This way would force us to duplicate the existing code and use different symbols. Then the old API would continuously became deprecated... - Should we make all the critical changes in the current API (increasing the libosmocore version?). This way would break builds of dependent projects and would suppose fixing compatibility with the new API. But, at the same time, the implementation would be cleaner and closer to the specification, without any deprecated duplication... Personally, I prefer the second way. At the same time, I want to make the modification as much transparent as possible. Speaking about Osmocom projects, the only users of the GSM 04.80 API are OsmoMSC and legacy OsmoNiTB. Both projects utilize it for '*#100#' handling only :/ To be more convincing, let's look at the following code: #define MAX_LEN_USSD_STRING 31 struct ss_request { uint8_t opcode; uint8_t ss_code; uint8_t ussd_text[MAX_LEN_USSD_STRING + 1]; uint8_t transaction_id; uint8_t invoke_id; }; This is what the current API allows you to obtain from a SS-request (e.g. '*#100#') coming from user. And what's wrong here? - The 'ss_request' doesn't indicate a part of the library it comes from. Would be better to use 'gsm0480_ss_request'. - The 'ussd_text' length doesn't follow the specification, where USSD OCTET STRING length is 160 bytes. So, the amount of characters depends on used coding scheme. - The information about SS-message type, component type, text length and used DCS (Data Coding Scheme), etc. is missing. Despite it could be important for the external application. So, let's discuss together all the 'pros and cons', and decide together, how should we facilitate the external USSD interface development. With best regards, Vadim Yanitskiy.