Project

General

Profile

Actions

Bug #4324

closed

SMS-over-GSUP: inconsistent SM-RP DA/OA coding

Added by fixeria about 2 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
SMS
Target version:
-
Start date:
12/13/2019
Due date:
% Done:

100%

Resolution:
Spec Reference:

Description

The existing TTCN-3 test cases for SMS over GSUP currently do not check the contents of SM-RP DA (Destination Address) and OA (Originating Address) IEs. I did a quick investigation, and as it turns out: in different code parts of OsmoMSC encoding of these IEs is different.

By definition, both DA and OA IEs may contain either of the following identities: IMSI, SMSC Address, MSISDN (that's what we support so fat, there is also LMSI and roaming number). However, unlike IMSI, MSISDN (SMSC Address is also MSISDN) is not just a set of digits. There is also a small (1 octet) header in front containing NPI (Numbering Plan Identification, 4 bit), ToN (Type of Number, 3 bit) and an Extension bit. Thanks to this header, we can have alphanumeric extensions in SMS. The problem is that in some cases OsmoMSC omits that header (I am not even sure if it gets NPI/ToN from the HLR), and sometimes includes the length of the encoded BCD number instead.

Here is what I implemented in TTCN-3:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16565 library/GSUP_Types.ttcn: fix MSISDN / SMSC coding in SM-RP-OA/DA [WIP]
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16566 MSC_Tests.ttcn: fix: verify the contents of SM-RP DA/OA for MO SMS

Before I start changing the code in OsmoMSC and fixing the test expectations, let's first discuss the following:

  • Should we include the length octet together with MSISDN / SMSC Address? This is what we do for OSMO_GSUP_MSISDN and OSMO_GSUP_IMEI IEs (see records GSUP_MSISDN and GSUP_IMEI respectively), so we can use gsm48_decode_bcd_number2() without messing around with transitional buffer and memcpy(). On the other hand, since SM-RP DA/OA is a TLV, adding an additional L looks redundant to me. We could introduce generic decode_bcd_number() function that would not require the L part (preferred).
  • What are the default NPI / ToN values for MSISDNs that we have in OsmoHLR? Can I just use NPI='0001'B (ISDN/Telephony Numbering), ToN='001'B (International Number)?

Checklist

  • OsmoMSC: fix MSISDN encoding for MO SMS
  • Check SM-RP-DA/OA in the existing TTCN-3 test cases
  • Update the Wireshark dissector to show ToN/NPI
  • Update GSUP documentation

Related issues

Related to OsmoMSC - Bug #2883: GSUP encoding of MSISDN is wrongNew01/26/2018

Actions
Related to Cellular Network Infrastructure - Support #4333: GSUP binary compatibility: add GSUP protocol version IE?Feedback12/16/2019

Actions
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)