Wireshark · Wireshark-dev: Re: [Wireshark-dev] Improve Tcap session management

[Florent Drouin <florent.drouin@xxxxxxxxxxxxxxxxx>]

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 <a.broman@xxxxxxxxx> 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: wireshark-dev-bounces@xxxxxxxxxxxxx
> > [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] 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 <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
> > > >
> > > >
> > > >
> > > >
> > > >         
> > >
> > >       
> > _______________________________________________
> > Wireshark-dev mailing list
> > Wireshark-dev@xxxxxxxxxxxxx
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >
> > _______________________________________________
> > Wireshark-dev mailing list
> > Wireshark-dev@xxxxxxxxxxxxx
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >
> >     
>
>
>