Wireshark-bugs: [Wireshark-bugs] [Bug 7042] The MSISDN is not seen correctly in GTP packet
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Tue, 10 Apr 2012 20:35:53 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7042

--- Comment #15 from Guy Harris <guy@xxxxxxxxxxxx> 2012-04-10 20:35:52 PDT ---
The Microsoft stuff appears to be describing a data structure used in APIs, not
a protocol.  The data structure contains an address type value:

enum WAP_ADDRESS_TYPE{
    WAP_ADDRESS_TYPE_UDP = 1,
    WAP_ADDRESS_TYPE_GSM_SMS
};

and a string.  For WAP_ADDRESS_TYPE_UDP, the string is a dotted-quad IP
address; for WAP_ADDRESS_TYPE_GSM_SMS, the string is "an MSISDN phone number in
international format, for example, +1.425.555.0112".  I guess if the + is
omitted, it's still a number, just not one guaranteed to be a fully-qualified
international number (e.g., just "555.0112").

In any case, that's not the way an MSISDN is represented in TBCD - the "."s and
"+" are omitted in TBCD.

Note also that the process described in RFC 2916 eventually strips out the "+";
it sounds as if the only purpose the "+" serves is to cause the
phone-number-to-FQDN process to put "e164.arpa" at the end of the domain name:

2.1 Special note about the '+'

   The '+' is kept in stage 2 in section 2 to flag that the number which
   the regular expression is operating on is a E.164 number.  Future
   work will be needed to determine how other numbering plans (such as
   closed ones) might be identified.  It is possible, but not definite,
   that they would use a similar mechanism as the one described in this
   document.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.