... 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."
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:
GGSNPDPRecord ::= SET
{
recordType [0] CallEventRecordType,
networkInitiation [1] NetworkInitiatedPDPContext
OPTIONAL,
anonymousAccessIndicator[2] BOOLEAN OPTIONAL,
servedIMSI [3] IMSI,
ggsnAddress [4] GSNAddress,
chargingID [5] ChargingID,
sgsnAddress [6] SEQUENCE OF GSNAddress,
accessPointNameNI [7] AccessPointNameNI,
pdpType [8] PDPType,
servedPDPAddress [9] PDPAddress,
remotePDPAddress [10] SEQUENCE OF PDPAddress
OPTIONAL,
dynamicAddressFlag [11] DynamicAddressFlag OPTIONAL,
listOfTrafficVolumes [12] SEQUENCE OF ChangeOfCharCondition,
recordOpeningTime [13] TimeStamp,
duration [14] CallDuration,
causeForRecClosing [15] CauseForRecClosing,
diagnostics [16] Diagnostics OPTIONAL,
recordSequenceNumber [17] INTEGER OPTIONAL,
nodeID [18] NodeID OPTIONAL,
recordExtensions [19] ManagementExtensions OPTIONAL,
localSequenceNumber [20] LocalSequenceNumber OPTIONAL,
apnSelectionMode [21] APNSelectionMode
}
Charging is very sensitive issue. Vendors rather prefer to share TAP3
records to pure CDR - it's easier and safer. 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.
My proposal is still present. With pleasure I would add subroutines to
dissect other charging record if I have description.
Regards, Michal
-----Original Message-----
From: ext Denis A. Doroshenko [mailto:d.doroshenko@xxxxxxxxxxx]
Sent: Monday, October 22, 2001 15:08
To: Michal.Melerowicz@xxxxxxxxx
Cc: ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] Ethereal 0.8.20 and WSP/GTP
hello,
excuse me, i didn't understand you. if we look at GSM 12.15 or ETSI TS
101 393 (i use the later for refereces), we see all format is described
there, since it is ASN.1 format it should be pretty simple to parse and
using the specification to name parameters (see Chapter 8 of the
specification).
the specification allows using non-ASN.1 format, in that case special
dissector is needed. so from your words i conclude that Nokia uses non-
ASN.1 format and that you've implemented a dissector for it. right?
what's regarding ASN.1, AFAIK SNMP uses ASN.1 encoded data, and ASN.1
decoding subrotines are in the Ethereal's source tree, so it should be
not difficult to add ETSI standardised CDR format parsing. but i'd
better be silent, since i seem to be incapable to do it myself at the
moment.
On Mon, Oct 22, 2001 at 10:17:43AM +0300, Michal.Melerowicz@xxxxxxxxx wrote:
> Hi
>
> Ethereal dissects only Nokia CDR's. Each vendor interprets GSM ETSI 12.15
> different, and none of fields inside of CDR is TLV or TV - there are just
> V's, so if you are so kindly to share with me description of other vendors
> CDRs, I will add this to GTP dissector. Regs
>
> Michal
--
Denis A. Doroshenko [GPRS engineer] .-. _|_ |
[Omnitel Ltd., T.Sevcenkos st. 25, Vilnius, Lithuania] | | _ _ _ .| _ |
[Phone: +370 9863486 E-mail: d.doroshenko@xxxxxxxxxxx] |_|| | || |||(/_|_
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
