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