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

["Kukosa, Tomas" <tomas.kukosa@xxxxxxxxxxx>]

Hi,

BTW the H.450 is reimplemented now with similar structure like Q.932/QSIG.
See attached picture.

Regards,
  Tomas

 

> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx 
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of 
> Anders Broman
> Sent: Monday, July 30, 2007 9:24 PM
> To: 'Developer support list for Wireshark'
> Subject: Re: [Wireshark-dev] Improve Tcap session management
> 
> 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
>

Attachment: ROSE.png
Description: ROSE.png