Wireshark-bugs: [Wireshark-bugs] [Bug 7042] The MSISDN is not seen correctly in GTP packet
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7042
--- Comment #17 from Anders Broman <anders.broman@xxxxxxxxxxxx> 2012-04-10 22:50:22 PDT ---
(In reply to comment #11)
> Is the "+" in the MSISDN just a display convention?
Yes and perhaps not a good one :-)
> If so, perhaps we should,
> as per an item in the Wireshark development wishlist:
>
> http://wiki.wireshark.org/Development/Wishlist
>
> add an FT_TBCD field type, with a display prefix or something of that sort
> pointed to by its hf[] entry, and, in a display filter for an FT_TBCD field, if
> the value it's being compared with begins with the same display prefix, strip
> it off, so that, for example, you could do either
>
> gtp.msisdn == "+966590381372"
>
> or
>
> gtp.msisdn == "966590381372"
>
> and have them work in the same fashion. If there's more than one
> interpretation of 0xA through 0xE, that could be specified by an ENC_ argument
> for proto_tree_add_item().
Yes overdecadic digits has different meaning in different parts of the
telephone
network and may differ nationally. On a subscriber line * # are often used
in subscriber services on international lines # may mean "operator assistance -
as examples.
>
> BTW, a comment in the Q.825 ASN.1:
>
>
> http://www.itu.int/ITU-T/formal-language/itu-t/q/q825/1998/Q825-CDR-ASN1Module.html
>
> says
>
> -- TBCD-STRING ::= OCTETSTRING
> -- This type (Telephony Binary Coded Decimal String) is used to represent
> digits from 0
> -- through 9, *, #, a, b, c, two digits per octet, each digit encoded 0000
> to 1001 (0 to 9),
> -- 1010 (*) 1011(#), 1100 (a), 1101 (b) or 1110 (c); 1111 (end of pulsing
> signal-ST); 0000 is
> -- used as a filler when there is an odd number of digits.
> -- The most significant address signal is sent first. Subsequent address
> signals are sent in
> -- successive 4-bit fields.
>
> However, unless there's an explicit digit count, or if 1111 is an
> end-of-digit-string value, I don't see how 0000 can be used as a filler, as I
> don't see how it can be distinguished from the digit 0.
There is information preceeding the TBCD string (odd/even indicator)
>
> The entry in the development wishlist says
>
> -- TBCD-STRING ::= OCTET STRING
> -- This type (Telephony Binary Coded Decimal String) is used to
> -- represent several digits from 0 through 9, *, #, a, b, c, two
> -- digits per octet, each digit encoded 0000 to 1001 (0 to 9),
> -- 1010 (*), 1011 (#), 1100 (a), 1101 (b) or 1110 (c); 1111 used
> -- as filler when there is an odd number of digits
> -- bits 8765 of octet n encoding digit 2n
> -- bits 4321 of octet n encoding digit 2(n-1) +1
>
> which speaks of 1111 as the filler. That matches ETSI TS 100 974 V7.15.0
> (2004-03), a/k/a 3GPP TS 09.02 version 7.15.0 Release 1998 (GSM MAP).
>
> However, the Dgt_tbcd in packet-ansi_map.c is
>
> static dgt_set_t Dgt_tbcd = {
> {
> /* 0 1 2 3 4 5 6 7 8 9 a b c d e */
> '0','1','2','3','4','5','6','7','8','9','?','B','C','*','#'
> }
> };
>
> which is a different encoding - maybe the ANSI encoding differs from the ITU-T
> encoding here, but it looks as if that might be ANSI T1.114-1988, which costs
> USD 300, which I'd rather not spend if I didn't have to. :-)
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
