Project

General

Profile

Actions

Feature #3445

open

SS/USSD: clean up the local GSM 04.80 API

Added by fixeria over 5 years ago. Updated over 5 years ago.

Status:
Stalled
Priority:
Normal
Assignee:
-
Category:
SS/USSD
Target version:
-
Start date:
08/03/2018
Due date:
% Done:

50%

Resolution:
Spec Reference:

Description

Since the SS/USSD related changes have been merged, OsmoMSC doen't process the
SS/USSD requests internally. This is why some part of the local GSM 04.80 API
has become useless. Would be great to clean it up, and keep only the most
important functions there...

Actions #1

Updated by fixeria over 5 years ago

  • % Done changed from 0 to 50

Some work was already done: https://gerrit.osmocom.org/10327/

Actions #2

Updated by fixeria over 5 years ago

  • Status changed from New to Feedback

Also, I think it makes sense to move the USSD notification VTY commands to OsmoHLR.
They are working outside the GSM 09.11 API in OsmoMSC, so it requires one to establish a silent call first...

What do you think?

Actions #3

Updated by laforge over 5 years ago

On Fri, Aug 03, 2018 at 09:47:27AM +0000, fixeria [REDMINE] wrote:

Also, I think it makes sense to move the USSD notification VTY commands to OsmoHLR.

Yes, it does!

Actions #4

Updated by fixeria over 5 years ago

  • Status changed from Feedback to In Progress

Before changing the code, I would like to clarify: how should I integrate the new VTY commands?

In OsmoMSC we currently do have the USSD notification commands integrated with the subscriber
management commands, i.e. 'subscriber ID_TYPE ID ussd-notify [...]'.

Should I follow the same approach in OsmoHLR?
Or should the SS/USSD related commands be somehow separated?

Actions #5

Updated by fixeria over 5 years ago

  • Status changed from In Progress to Stalled
  • Assignee deleted (fixeria)
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)