SS MM Messages (Call forwarding etc)

Keith Whyte keith at
Tue Jul 5 14:49:15 UTC 2016

Hi All,

A few weeks ago, I wrote to the list about a handset that was opening
and holding an lchan after doing IMSI attach.
After some investigation I see this phone is querying the network for
call forwarding status. This phone then cannot send any more USSD codes,
or make calls, although it can receive, but for some reason insists on
doing the query again after call termination.

Doing the same from other handsets, by dialling such codes as *#21# in
each case gives the same result of eternal lchan usage, although some
(more modern) phones seem to eventually timeout, releasing the channel
while others do not.
I connected numerous phones and did the same on each one and pretty soon
I have a kind of DOS situation on the network in that SDCCH is at capacity.

The last log message resulting from the request is
/openbsc/openbsc/src/libmsc/gsm_04_08.c:3586 Dispatching 04.08 message,
although strangely with one phone, this is followed shortly by:
libosmocore/src/gsm/gsm0480.c:219 USSD Request is too short.
openbsc/openbsc/src/libmsc/ussd.c:55 Unhandled SS
so for that one phone, it would seem handle_rcv_ussd() is being called
from gsm0408_dispatch()

I have been going through the code, basically adding more debug output
to try to verify what is being called from where, and I also found the
functionality in libosmocore such as gsm0480_decode_ss_request(),
although this is not called at anytime from the nitb.
This is an enormous project!

I notice these lines in openbsc/openbsc/src/linmsc/gsm_04_08.c in

    /* we will send a MM message soon */
    conn->expire_timer_stopped = 1;

It would seem that we don't ever send this MM message.

It's not clear to me where I might try to check again on the status of
this MM request, or if the problem is a lack of full implementation of
these supplementary service requests.

Would anybody be interested in working on this with me?


More information about the OpenBSC mailing list