Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 7042] The MSISDN is not seen correctly in GTP packet

Date: Tue, 10 Apr 2012 22:50:22 -0700 (PDT)
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.