> By the way, I noticed the Q.931 code needs some work for Euro ISDN,
> which Q.931 implementation was it written for?
I wrote it because I was curious what was in some ISDN trace (I think it
was one Gilbert sent out), and was curious what Q.931 was about.
So, if you could argue that it was written for some particular flavor of
Q.931 - which I'm not sure you can, given that it does nothing with
shift information elements - it was written for whatever flavor
Southwestern Bell uses, possibly one of the Bellcore National ISDN
flavors.
The code probably needs
1) a way for the user to specify which particular ISDN flavor is
being used, unless it can reliably determine that;
2) something to actually use the code set information it
maintains;
3) code to understand the stuff various flavors send.
Some protocol dissectors probably need ways for the user to tell them
something the dissector can't figure out by itself (e.g., ATM figuring
out what soft of traffic is going over a particular VPI/VCI; what port
protocol XXX is using; etc.). There are a couple of UIs I could see for
this:
1) a scrollable list of all protocols, along the line of
Olivier's list of plugins ("all protocols" includes
compiled-in *and* plugin protocols), with the ability to
select one and pop up a dialog box for its particular set of
user-supplied information;
2) if the set of protocols with user-supplied information is
sufficiently small, a tabbed dialog box - but I could imagine
that the set wouldn't be small, if we allow *any* protocol to
have associated with it a display filter expression
specifying which packets should be analyzed as that type of
protocol, as per what Olivier's code allows for plugins.
