["Anders Broman" <a.broman@xxxxxxxxx>]

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