Anders, Jeff,
As a regular user of the MAP, INAP, CAMEL, TCAP dissectors. I feel that
the issue here is under an unusual network you may have a protocol not
running on its usual SSN, also there is potential that two differing
protocols could be running on the same SSN however very unlikely these
days.
Extract from a very old 3gpp doc 3GPP TSG-CN Plenary Tdoc 3GPP N-99143
In September 1998 at ETSI SMG 12 (Rome), the Japanese companies
indicated that there was a
problem with assigning SSN=5 for CAP. The problem was that the ITU-T had
already assigned
SSN=5 as a globally standardised SSN number for MAP.
However I don't see this as a problem, and requiring a range of SSNs is
definitely not required for MAP as it usualy runs on "6,7 and 8" I have
not seen it run on any other SSNs outside the lab. INAP however runs on
differing SSNs depending on the manufacturer of the equipment.
To explain the protocol stack further TCAP in the case of MAP is like
RPC, and the "address" to the code that will handle the "call" (begin)
includes the SSN, ACN and OPCODE. Once that combination is "pointing" at
a handling piece of code it can receive the payload and reply.
However a complete implementation of this would result in a complete
"SS7" analyzer and not a "TCP" analyzer.
The method of attaching dissectors into the dissecting tree, should be a
combination of all these parameters, ideally configurable, to handle
"manufacturers extensions".
Tim
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Anders Broman
(AL/EAB)
Sent: 17 March 2005 15:41
To: Ethereal development
Subject: RE: [Ethereal-dev] GSM MAP: register for range of SSNs
Hi,
I don't opose the patch as sutch, just wondering what's the *right*
thing to do. If many differnt ssn "users" occure in the same trace there
might be problems with overlap as well I suppose. Eventhough I made some
work on the gsm-map dissector I'm not looking at gsm-map traces myself.
So you guys decide. If no one objects I'll check in your patch
tonight(time permitting).
Best regards
Anders
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Jeff Morriss
Sent: den 17 mars 2005 16:24
To: Ethereal development
Subject: Re: [Ethereal-dev] GSM MAP: register for range of SSNs
Hi,
> I put that preference there as I received a trace where the ssn was
> outside of the range predefined in the previous dissector, my
> reasoning for making it individual ones rather than a range was that I
> though the ssn:s used could be "any" rather than a range, I haven't
> found any documentation giving certain applications fixed ssn numbers.
> Is there sutch a document or any convention used? ( GSM-MAP, INAP,
> CCBS ....) or is it totally up to the administration?
Hmmm, I don't know.
However, I do tend to get questions like: "Why isn't Ethereal decoding
my GSM MAP message as GSM MAP? I thought it understood GSM MAP." I
look and find they're using (in their testing) some unusual SSN (either
because that SSN is their favorite number or because they got forced off
the "usual" SSNs because someone else is testing on those).
> Perhaps only two ssn number are realy needed for any particular trace?
Probably yes.
> I suppose all dissectors based on ssn should be made the same in this
> respect?
I would think so (I was thinking of looking at doing that if this patch
were accepted).
(Another reason for the patch is simply that I tend to prefer the
look-n-feel of one preference with a range to N uint preferences...)
Regards,
-Jeff
> -----Original Message-----
> From: ethereal-dev-bounces@xxxxxxxxxxxx
> [mailto:ethereal-dev-bounces@xxxxxxxxxxxx]On Behalf Of Jeff Morriss
> Sent: den 17 mars 2005 01:12
> To: Ethereal Development List
> Subject: [Ethereal-dev] GSM MAP: register for range of SSNs
>
>
>
> I saw today that the GSM MAP dissector now has a preference for up to
> 5
> TCAP SSNs. Rather than do that I think it would be better if it used
> the new range preference type.
>
> The attached patch does that and (sorry, I know it makes the patch
> harder to read) cleaned up some indenting around the code I was
changing
> (which results in the actual code being easier to read).
>
> I didn't register the old prefs as obsolete since README.developer
> doesn't suggest doing that any more; should it (both my patch and the
> README)?
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
