<div dir="ltr"><div><span style="font-size:13px;color:rgb(33,33,33)">Hi </span><span class="inbox-inbox-lG" style="font-size:13px;background-color:rgba(251,246,167,0.5);outline:transparent dashed 1px;color:rgb(33,33,33)">Alexander</span><span style="font-size:13px;color:rgb(33,33,33)">,</span></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>link: <a href="https://github.com/rowanphipps/libosmocore" target="_blank">https://github.com/rowanphipps/libosmocore</a></div><div><br></div><div>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.</div><div>link: <a href="https://github.com/rowanphipps/openbsc" target="_blank">https://github.com/rowanphipps/openbsc</a></div><div><br></div><div>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.</div><div>documentation: <a href="https://django-ussd-airflow.readthedocs.io/en/latest/" target="_blank">https://django-ussd-airflow.readthedocs.io/en/latest/</a></div><div>original: <a href="https://github.com/mwaaas/ussd_airflow" target="_blank">https://github.com/mwaaas/ussd_airflow</a></div><div>modified: <a href="https://github.com/rowanphipps/ussd_airflow" target="_blank">https://github.com/rowanphipps/ussd_airflow</a></div><div><br></div><div>And here is the repo with my python script to link all the parts together: <a href="https://github.com/rowanphipps/sup_airflow" target="_blank">https://github.com/rowanphipps/sup_airflow</a></div><div><br></div><div><div><span style="color:rgb(33,33,33);font-size:13px">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.  </span><span style="color:rgb(33,33,33)">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.  </span><span style="color:rgb(33,33,33)">The main advantage of keeping sup is that it is very simple to extend to use with other USSD systems.</span></div><div><span style="color:rgb(33,33,33);font-size:13px"><br></span></div><div>Let me know if you have any questions regarding the changes I made and how it works.</div></div><div dir="ltr"><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 15, 2018 at 4:54 PM Alexander Chemeris <<a href="mailto:Alexander.Chemeris@fairwaves.co" target="_blank">Alexander.Chemeris@fairwaves.co</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Jan 14, 2018 at 3:16 PM, Kurtis Heimerl<br>
<<a href="mailto:kheimerl@cs.washington.edu" target="_blank">kheimerl@cs.washington.edu</a>> wrote:<br>
> I wanted to speak up and second the need to fix the USSD system, as Vadim<br>
> notes it's actually just broken at the moment and doesn't meet the standard.<br>
> A student in my lab (Rowan, cc'd) recently had to extend it to be able to<br>
> interface with ussd_airflow, I believe building off of earlier fairwaves<br>
> patches. We'd also like to be able to upstream those fixes to the community,<br>
<br>
Do you have a repo with this integration? This might be interesting<br>
for us as well. We're currently implementing USSD services in Erlang<br>
but a more non-programmer friendly YAML might be a good option in some<br>
cases.<br>
<br>
--<br>
Regards,<br>
Alexander Chemeris.<br>
CTO/Founder, Fairwaves, Inc.<br>
Skype: Alexander.Chemeris<br>
Mobile: <a href="tel:(424)%20400-7626" value="+14244007626" target="_blank">+1(424)400-7626</a><br>
<a href="https://fairwaves.co" rel="noreferrer" target="_blank">https://fairwaves.co</a><br>
<br>
Subscribe to Fairwaves news: <a href="http://eepurl.com/baL_pf" rel="noreferrer" target="_blank">http://eepurl.com/baL_pf</a><br>
</blockquote></div></div><br clear="all"><br>-- <br><div dir="ltr" class="m_-3292217104920496164gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Thanks!</div><div>    - Rowan Phipps</div></div></div></div>