SS MM Messages (Call forwarding etc)

Holger Freyther holger at freyther.de
Tue Jul 5 16:32:33 UTC 2016


> On 05 Jul 2016, at 16:49, Keith Whyte <keith at rhizomatica.org> wrote:
> 
> Hi All,

Hi!


> 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
> gsm48_rx_mm_serv_req()
> 
>    /* 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?

sure. Can you extract that USSD query dialogue in a pcap file for us? The "expire timer stopped" is related to periodic LUs[1] and most likely not linked to anything you are seeing.

I don't know the SS codes by heart but your phone most likely queries for something like call barring, forwarding state and waits for an answer and we are happy to keep the channel open. Which means the "invokeId" is blocked in the phone.. which most likely means it will not try to use a different invokeId for the next call.

The right way is to reject it. But once we have the PCAP file we can see which message to reject (or returnResultLast to).


holger



[1] With periodic LU a phone needs to report every X interval to the system unless it had some form of contact in between. We use expire_timer_stopped to remember that we had contact and when the subscriber connection is gone/closed we update the DB with NOW + X interval (+ margin) as the time we want to expire the subscriber.


More information about the OpenBSC mailing list