Hello Luis,
I add a look to the SCCP association, and I must say that it is a good
idea to have a uniq code for all this kind associations. So I agree on
your proposal.
I will analyze deeper how works the SCCP association and the se_tree, to
see what changes are needed.
In my last mail, I said that I will have a look to the se_tree later, it
is just because I will be out of office in the next weeks, not because I
am not interresting to merge the code.
So, I will work on it, if you accept, in september.
Regards
Florent
Luis EG Ontanon wrote:
TCAP uses the same mechanism for mantaining sessions that SCCP uses
(also SUA, ALCAP, GTP-C and others do)
A->B SETUP (orig-key=keyA)
B->A SETUP-CONFIRM (orig-key=keyB, dest-key=keyA)
...
A->B MSG (dest-key=keyB)
B->A MSG(dest-key=keyA)
...
A->B RELEASE ([orig-key=keyA],dest-key=keyB)
B->A RELEASE-COMPLETE ([orig-key=keyB],dest-key=keyA)
all these protocols use uint32 keys, The SCCP implementation (mine) I
needed originally to be able to decode payload over SCCP in
Connection-Oriented messages that do not carry an SSN. Later I used it
for to a single (articicial) filter for a connection and to add RANAP
and BSSAP to have the The VoIP Calls Dialog (yes I know that neither
BSSAP nor RANAP are VoIP, but then Neither is ISUP that is in there
anyway).
I been thinking in adding MAP, INAP, and CAMEL [and may be ALCAP] to
the VoIP Calls as well that woul nmean tht I shoyuld re-use the code I
use for tracing SCCP for TCAP, that code
would do (almost) the same that this code does.
Should we unite efforts and come up with a single se_tree-based
persistent transaction handling of TCAP transactions that can be used
for filtering, tracing and statistics?
Luis
On 7/30/07, Florent Drouin <florent.drouin@xxxxxxxxxxxxxxxxx> wrote:
Hi,
I have found the problem, so I did add the same protection, found in
expert.c, again "read filter" in the tcap tap. Thanks for pointing this bug.
I did rename the decoding function for ANSI and ITU as suggested.
And by the way, I did correct when a dissector want's to unregister it's
ssn.
As the ITU, and ANSI table for sccp.ssn is common, you can not
unregister an ssn(ITU) in the SCCP table if it is used by an ANSI
subdissector.
For the use of se_tree, I will see, but a bit later..
Regards
Florent
Jeff Morriss wrote:
Wow, that was fast, thanks!
By the way, why not rename these functions with "ANSI" and "ITU" in the
name?
+/*
+ * Call ITU Subdissector to decode the Tcap Component
+ */
static int
dissect_tcap_TheComponent(gboolean implicit_tag _U_, tvbuff_t *tvb, int offset, asn1_>
[...]
+/*
+ * Call ANSI Subdissector to decode the Tcap Component
+ */
+static int
+dissect_tcap_TheComponentPDU(gboolean implicit_tag _U_, tvbuff_t *tvb, int offset, as>
(maybe there's a good reason they're named that way, but...)
Also, while I was testing the patch on an ANSI TCAP capture I had handy,
I noticed that if I use a read filter ("wireshark -r /some/file -Rsccp"
for example), none of the TCAP statistics stuff works--I get a bunch of
noise about sessions starting in frame 0 and the responses don't get
matched to the queries. Maybe there's some code in there that assumes
that frame numbers are continuous (e.g., frame 3 follows frame 2) which
may not be the case if you have a read filter? If you don't have any
immediate ideas, maybe I'll file a bug report so we don't forget.
One other thing that I've read before:
http://anonsvn.wireshark.org/viewvc/viewvc.py?view=rev&revision=20758
is that the g_hash's should be replaced with se_tree's (see
README.binarytrees). Something to think about going forward.
Anyway, checked in rev 22415, merci!
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
