External USSD interface development

[Vadim Yanitskiy]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180114/728f9423/attachment.htm>