External USSD interface development

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Rowan Phipps phippsr at cs.washington.edu
Tue Jan 16 07:21:08 UTC 2018


Hi Alexander,

Most of the work I did was based off the libosmocore fairwaves/sup-ussd
branch.   As that branch stands, the first USSD message and its response
are handled fine, where it breaks down, is if the service requests more
information from the user.  On subsequent messages, it looks like the phone
leaves out a few critical bytes including the opcode.  After reading the
standards documents I still do not understand why this is the case but it
was observed on multiple handsets and seems to be normal.  Most of the
modifications I had to make involved handling the other USSD message types
and dealing with the fallout from having the opcode missing.  I also added
some additional fields to the ss_request struct to track the text length,
message type and component type.  I changed the max string length from 31
to 160 but I'm not sure if it should be longer.  USSD strings are
transmitted in a 7 bit packed format where the maximum length is 160
bytes.  When expanded out into standard ascii this ends up around 182
characters so maybe the max size should be 182 characters.

To tie into an external USSD service, I set up osmo-nitb to forward USSD
requests to a python script using sup.  This script would then forward the
USSD message to another program, ussd_airflow, via a http post request.
Ussd_airflow is a Django web server that handles USSD requests and can be
configured using YAML files.

The version of libosmocore used was forked from the master branch in
October and has not been kept up to date since then, although I doubt any
of the USSD code has been changed much since then.
link: https://github.com/rowanphipps/libosmocore

The version of openbsc used was forked from the fairwaves/sup-ussd branch.
 It was not modified very much although that branch had not been touched
since October 2015 so it is reasonably old.
link: https://github.com/rowanphipps/openbsc

I made some modifications to the ussd_airflow web server to allow it it
handle multiple different service codes but the original would work fine as
well.
documentation: https://django-ussd-airflow.readthedocs.io/en/latest/
original: https://github.com/mwaaas/ussd_airflow
modified: https://github.com/rowanphipps/ussd_airflow

And here is the repo with my python script to link all the parts together:
https://github.com/rowanphipps/sup_airflow

As for creating an external interface, the current sup interface could be
left exposed with the idea that people could just write scripts to parse
these messages and forward them as needed.  If this is chosen then the sup
protocol needs to be better documented and standardized.  Sup seems to have
been changed in more recent branches and now functions differently and in a
way that the old fairwaves code does not work with.  The main advantage of
keeping sup is that it is very simple to extend to use with other USSD
systems.

Let me know if you have any questions regarding the changes I made and how
it works.


On Mon, Jan 15, 2018 at 4:54 PM Alexander Chemeris <
Alexander.Chemeris at fairwaves.co> wrote:

> On Sun, Jan 14, 2018 at 3:16 PM, Kurtis Heimerl
> <kheimerl at cs.washington.edu> wrote:
> > I wanted to speak up and second the need to fix the USSD system, as Vadim
> > notes it's actually just broken at the moment and doesn't meet the
> standard.
> > A student in my lab (Rowan, cc'd) recently had to extend it to be able to
> > interface with ussd_airflow, I believe building off of earlier fairwaves
> > patches. We'd also like to be able to upstream those fixes to the
> community,
>
> Do you have a repo with this integration? This might be interesting
> for us as well. We're currently implementing USSD services in Erlang
> but a more non-programmer friendly YAML might be a good option in some
> cases.
>
> --
> Regards,
> Alexander Chemeris.
> CTO/Founder, Fairwaves, Inc.
> Skype: Alexander.Chemeris
> Mobile: +1(424)400-7626 <(424)%20400-7626>
> https://fairwaves.co
>
> Subscribe to Fairwaves news: http://eepurl.com/baL_pf
>


-- 
Thanks!
    - Rowan Phipps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180116/30c2a1f9/attachment.htm>


More information about the OpenBSC mailing list