Camel IDP filtering problem

This issue was migrated from bug 9057 in our old bug tracker.

Original bug information:

Reporter: Chico
Status: RESOLVED FIXED
Product: Wireshark
Component: Dissection engine (libwireshark)
OS: All
Platform: All
Version: 1.10.1

Attachments:

CallingNatureOfAddress.zip: Camel IDP NatureOfAddress
CallingNatureOfAddress_-_1.pcap: CallingNatureOfAddress - second example

Chico said:

Created attachment 11414

Camel IDP NatureOfAddress

Build Information:

Built using Microsoft Visual C++ 10.0 build 40219

When I try to apply a filter to the Nature of Address from callingPartyNumber, the filter is not correctly applied since it also filters the Nature of Address from the originalCalledPartyID.

From what I could figure out this happens because both fields use the same dissector "isup.calling_party_nature_of_address_indicator".

This also applies to all the other number properties.

Shouldn't this fields have different dissectors to be possible to apply a filter to them? Shouldn't this dissectors be part of camel instead of isup?

Please find in attach the *.pcap file and 2 screen shots.

Thanks

added enhancement libwireshark version1.10 labels

Anders Broman said:

Well the rationale for the decoding is that all (most?) Camel "numbers are defined as something like:
CallingPartyNumber {PARAMETERS-BOUND : bound} ::= OCTET STRING (SIZE(
	bound.&minCallingPartyNumberLength .. bound.&maxCallingPartyNumberLength))
-- Indicates the Calling Party Number. Refer to ETSI EN 300 356 1 [23] for encoding.

From a programing point of view it then becomes efficent to call the same
dissection routine for all numbers with the same encoding like in this case
dissect_isup_calling_party_number_parameter().

Would a filter like (camel.callingPartyNumber) && (isup.calling_party_nature_of_address_indicator == 4) serve the same purpose?

I'm not convinsed that it's worth the effort to have different filters for all
the different numbers.

Chico said:

Created attachment 11415 CallingNatureOfAddress - second example

Chico said:

(In reply to comment #1)  
> Well the rationale for the decoding is that all (most?) Camel "numbers are  
> defined as something like:  
> CallingPartyNumber {PARAMETERS-BOUND : bound} ::= OCTET STRING (SIZE(  
> 	bound.&minCallingPartyNumberLength .. bound.&maxCallingPartyNumberLength))  
> -- Indicates the Calling Party Number. Refer to ETSI EN 300 356 1 [23] for  
> encoding.  
>  
> From a programing point of view it then becomes efficent to call the same  
> dissection routine for all numbers with the same encoding like in this case  
> dissect_isup_calling_party_number_parameter().  
>  
> Would a filter like (camel.callingPartyNumber) &&  
> (isup.calling_party_nature_of_address_indicator == 4) serve the same purpose?  
>  
> I'm not convinsed that it's worth the effort to have different filters for  
> all  
> the different numbers.  

Hi,

Thanks for your comment.
If we could use different filters to select what we want than it would be great.
The problem now is that until now I was not able to create a filter that gets mt only the callingPartyNumbers that Nature of address are National (3).

I followed your suggestion and applied the filter "(camel.callingPartyNumber) &&
(isup.calling_party_nature_of_address_indicator == 3)", the only change was 3-National instead of 4-International.

In attach there is a new .pcap file with 2 frames, one has the CallingPartyNumber in national and the other international. If you apply the above filter both frames. The one that is international appears because it also has the originalCalledPartyID as national.
So that filter is not working.

Another question, we are talking about Calling and Called Numbers that are mapped in the same isup Calling structure, is this correct?

Many thanks.

Anders Broman said:

fixed inhttps://code.wireshark.org/review/#/c/28158/

closed