Project

General

Profile

Bug #2930

MSC_Tests TTCN problem with odd-length MSISDN numbers

Added by laforge 9 months ago. Updated 3 days ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/11/2018
Due date:
% Done:

0%

Resolution:
Tags:

Description

There's a bug somewhere related to matching of odd-length MSISDN numbers in the OsmoMSC TTCN-3 test suite.

For example, in f_mt_call(), the following section works with an even digitlength (123456) but not with an odd digit length (12345):

+       //FIXME: odd digits var CallParameters cpars := valueof(t_CallParams('12345'H, 0));
+       var CallParameters cpars := valueof(t_CallParams('123456'H, 0));

History

#1 Updated by laforge 6 months ago

  • Tags set to TTCN3

#2 Updated by laforge 3 months ago

  • Assignee changed from laforge to stsp

#3 Updated by stsp 7 days ago

The underlying problems seems to be that '12345'H is expanded to '12345F'H somehow:

15:55:14.419444 12 BSC_ConnectionHandler.ttcn:442 Matching on port BSSAP .dtap.msgs.cc.setup_NW_MS.callingPartyBCD_Number.digits := '12345F'H 
with '12345'H unmatched: First message in the queue does not match the template:

#4 Updated by stsp 6 days ago

The encoder is being told to pad the digits string with '1' bits:

type record CallingPartyBCD_Number {
  OCT1  elementIdentifier, // '5C'O -table 9.70
  LIN1  lengthIndicator, // 1..12
  CallingOrCalled_Number_oct3   oct3,
  hexstring  digits  optional
} with { variant (lengthIndicator) "LENGTHTO (oct3,digits)";
         variant (digits) "PADDING(yes)";
         variant (digits) "PADDING_PATTERN('1'B)"};

This results in an '12345F'H hexstring:

                    callingPartyBCD_Number := {
                        elementIdentifier := '5C'O ("\\"),
                        lengthIndicator := 4,
                        oct3 := {
                            numberingPlanIdentification := '0001'B,
                            typeOfNumber := '001'B,
                            ext1 := '1'B,
                            screeningIndicator := omit,
                            spare1_3 := omit,
                            presentationIndicator := omit,
                            ext2 := omit
                        },
                        digits := '12345F'H
                    },

I am unsure how the receiver is supposed to detect whether padding is present.

Are any 'F' digits simply invalid?

Can we derive the presence of padding from the lengthIndicator field (4)? If so, how?

#5 Updated by stsp 3 days ago

This patch adds trailing 'F'H to odd-length digit strings and
makes the related tests pass with such strings:
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11743

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)