["Luis EG Ontanon" <luis.ontanon@xxxxxxxxx>]

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
>


-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan