Comment # 3
on bug 9057
from Chico
(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.
You are receiving this mail because:
- You are watching all bug changes.
