The ASN1 definition for the ANSI Tcap seems to be currently outdated. (no [PRIVATE 18] decoding ) So that a good thing to update the ANSI part, (the ITU part seems to be ok). But, on the other hand, I have seen tcap stack using the old syntax. For example, I have seen Abort with [PRIVATE 24]. So, maybe in a first step, we can take the last ANSI Tcap definition, and see if we can have an optional decoding for the old definition ?
Regards Florent Luis EG Ontanon wrote: > It would be lovely to have TCAP applications registering by OID > instead of using the SCCP SSN. > > On 7/30/07, Anders Broman <[EMAIL PROTECTED]> wrote: > >> Hi, >> I have plans to change the TCAP dissection to use the original unchanged >> ASN1 code and to split it into ITU TCAP and ANSI TCAP with heuristic >> Determination of ANSI TCAP i.e ITU TCAP will be the main dissector. >> Doing this also means a slight change to the TCAP dependent >> Dissectors - dissection will start after "local code" probably >> Looking quite like the QSIG implementation. However I need some time to >> complete this transition and to check the feasibility. It also involves >> Changes to CAMEL, INAP, GSM MAP and ANSI MAP. >> >> Does any one have thoughts on the subject? >> Regards >> Anders >> >> -----Ursprungligt meddelande----- >> Från: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] För Florent Drouin >> Skickat: den 30 juli 2007 14:09 >> Till: Developer support list for Wireshark >> Ämne: Re: [Wireshark-dev] Improve Tcap session management >> >> 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 <[EMAIL PROTECTED]> 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 >>>> [email protected] >>>> http://www.wireshark.org/mailman/listinfo/wireshark-dev >>>> >>>> >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> Wireshark-dev mailing list >> [email protected] >> http://www.wireshark.org/mailman/listinfo/wireshark-dev >> >> _______________________________________________ >> Wireshark-dev mailing list >> [email protected] >> http://www.wireshark.org/mailman/listinfo/wireshark-dev >> >> > > > _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
