Wireshark · Ethereal-dev: Re: [Ethereal-dev] Ethereal 0.8.20 and WSP/GTP

["Denis A. Doroshenko" <d.doroshenko@xxxxxxxxxxx>]

[i am not entirely sure whether the discussion belongs to the Ethereal's
 dev maillist, however our discussion is basically about implementing
 GPRS CDR dissction...]

Michal, what are you trying to do? are you trying to tell me TLV/TV
coding is better than ASN.1? i ask this because my awful skills of
English prevent me from understanding the meaning of the following:

On Mon, Oct 22, 2001 at 05:15:28PM +0300, Michal.Melerowicz@xxxxxxxxx wrote:
> ... What some book says:
> 
> "As we saw for the tabular notation from which it was derived, this TLV
> approach  gives many advantages in the design of basic encoding rule.
>   The presence of a distinct (at least within an enclosing SEQUENCE) "T"
> part enables a decoder to recognise the presence or absence of OPTIONAL
> elements.
>   The presence of a length field allows elements that are arbitrarily many
> repetitions of a single type (an ASN.1 "SEQUENCE OF" construction).
>   The presence of a length field makes it easy to make value parts variable
> length when appropriate, for example character strings.  But it also allows
> integer values to be transmitted with as many octets as are needed, rather
> than forcing the concept of  "short" (two octet) and "long" (four octets)
> and "super-long" (rather more!) integers into the language.  ASN.1 has just
> one INTEGER type."

if this indeed is an attempt to ensure me the ASN.1 is worse (more
complicated etc.) it won't play :-) just because i can ask you several
simple questions, for example: why, however TLV/TV was used throughout
ISUP and MAP2, newer additions are ASN.1 (for example MAP3)? why does
ETSI suggest all new stuff to be ASN.1 coded? why all people talk about
XML nowadays (do not wonder, it's related)? the answer is simple: ASN.1
(like XML) is self-describing data definition format. with ANS.1 i can
write generic parser, which while being incapacle of naming and
interpreting somehow appropriately various data fields will be able to
spearate them and tell me "i don't know what it means, but this is ASCII
string, and this is number and this is array of bits etc." the only
thing i have to do then, just say "this id is Cell ID, this one is IMSI
etc." and voila, i have it all dissected. with TLV/TV it's impossible to
write generic parser, just because it must know TV IE to be able to
reach the next one. also, when we talk about security, TLV/TV is the
wrost case: lose one byte (that is, let all data be shifted by one
byte), and i'll see how your TLV/TV parser will work around that! with
ASN.1 it's not a problem, since i can always skip data till i find the
begining sequence, which tells me where the record begins. i can tell
you, that Siemens has its CDRs in ASN.1 for years (more than five for
now), and that is cool. we've wrote parser for it, and even when
Siemens' format was changed (some fields added) that same parser was
capable to parse records, it just noticed that there are several unknown
fields of particular type... i do not know who the hell pushed this
crazy TLV/TV stuff to ETSI, it must be some vendor... *shrug*

what about other books, like ITU-T X.208/X.209 (outdated a bit) and
X.608/X.609? :-)

> None of CDR fields is TLV or TV, so if some vendor (Nokia, Ericsson, Siemens
> etc) decided to remove one or more OPTIONAL fields from its charging record,
> you can only guess what is missing. For example GGSNPDPRecord:

i cannot agree with you on that. i would like to see Siemens' CDRs, but
it's not a top secret, they are ASN.1. and i will try to see what i can
do with that to add parsing of GTP' CDRs (in ASN.1) to Ethereal. when i
read the specification, i can't see the things that can be differently.
some defintions (like IMSI in ASN.1) are defined in other ETSI
documents, so we just need to look there, but most of stuff looks pretty
clear...

> GGSNPDPRecord 	::= SET
> {
[snip]
> }
> 
> Charging is very sensitive issue. Vendors rather prefer to share TAP3
> records to pure CDR - it's easier and safer.

we don't know what is TAP3, you know, we're not billing engineers here,
but what's related to safety, please read my comments above. TLV/TV may
be easier to implemet a decoder, not safer. or have i lost the point?

> I haven't seen installation
> with SGSN and GGSN from different vendors, so there is no problem of
> incompatibilty. Problem is when 3rd party tries to interpret GTP'. If I'm
> wrong please correct me.

SGSN/GGSN vendors may differ, that's not a problem (think about GPRS
roaming). the most important thing is SGSNs of different vendors within
the same PLMN. well, how about collating inter-SGSN RAU (Routing Area
Update) CDRs? when different SGSNs use different CDR formats... that
should be wild crazy. not even 3rd party tools, but your billing system
must be *very* comprehensive to collate all fetched CDRs correctly.
if different vendors use different protocols for CDRs, that can be the
reason to stick with SGSNs of one vendor. but i don't believe that. all
vendors should be acting as defined by ETSI in the specification,
otherwise there will be a lot of problems (hell, that is why there is
such thing -- standards). BTW, we know operators, that have equipment of
different vendors with different parts of their network...

> My proposal is still present. With pleasure I would add subroutines to
> dissect other charging record if I have description. 

well, i would like to provide you with the data you need, but believe
me, i may not. it's the commercial network and none of its parameters
and any information that will allow you to guess anything, may be
disclosed. if you do smth., i will test it against the data i have
here and tell the results. sorry, i bound to act thins way :-)
for example current Ethereal doesn't handle our CDRs, it just dissects
GPT' and doesn't even show there's something after the GTP' header
(though in hex-dump we see the CDR in hex)...

> Regards, Michal

-- 
Let the Force be with You!..
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Denis A. Doroshenko                    internet services, unices, m$ os
System programmer and administrator    programming, administering, consulting
mailto:cyxob@xxxxxxxxxxxxxxxx          do you BSD? --> http://www.OpenBSD.org