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
