https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4588
Gerasimos Dimitriadis <dimeg@xxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dimeg@xxxxxxxxxxx
--- Comment #3 from Gerasimos Dimitriadis <dimeg@xxxxxxxxxxx> 2010-03-19 10:49:30 PDT ---
As far as I know, RANAP is the only protocol having this different encoding of
MNC. I'd say that it was not in the original intentions to change in 25.413 the
way that the MCC/MNC pair gets encoded. The corresponding text in 25.413 can be
considered as holding even in the case of an MNC encoded according to 24.008.
But in the end, the actual MNC encoding in RANAP is done according to the most
reasonable interpretation of the standard. The above theory is based on the
fact that it seems absurd to mandate a different variation for the MNC
encoding, without having something to gain.
Regarding the _in_address() variant of the decoding function, it is used in
cases of Global Title addresses encoded according to E212, which essentially
means that in cases of 2 digits long MNC, no filler digit is used. I think that
the places were _in_address() is invoked are checked, calling the correct
variant.
Sorry for delaying in responding, things have been pretty busy this week at
work. If you do not plan on working on it Anders, I could start working on this
bug.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
