Homer incorrect decodes SIP-I ISUP (Content-Type: application/isup;version=itu-t92+) using decoder_shark tshark
mmyshko opened this issue · 9 comments
I installed on Oracle Linux Server release 8.8 homer-app VERSION: 1.4.56 from RPM and configure "decoder_shark": { "bin": "/usr/bin/tshark"}.
TShark - v2.6.2
I observe problem when try see ISUP part of SIP-I message in Homer-app because incorrect called number and Nature of address indicator.
Information about Calling Party Number is absent at all.
I dumped this SIP-I message on my kamailio and decoded it using tshark - v2.6.2.
Tshark correctly decoded:
Called Party NumberCalled Party Number: 632107608
Mandatory Parameter: Called party number (4)
Pointer to Parameter: 2
Parameter Length: 7
1... .... = Odd/even indicator: odd number of address signals
.000 0011 = Nature of address indicator: national (significant) number (3)
1... .... = INN indicator: routing to internal network number not allowed
.001 .... = Numbering plan indicator: ISDN (Telephony) numbering plan ITU-T E.164 (1)
Called Party Number: 632107608
.... 0110 = Address signal digit: 6 (6)
0011 .... = Address signal digit: 3 (3)
.... 0010 = Address signal digit: 2 (2)
0001 .... = Address signal digit: 1 (1)
.... 0000 = Address signal digit: 0 (0)
0111 .... = Address signal digit: 7 (7)
.... 0110 = Address signal digit: 6 (6)
0000 .... = Address signal digit: 0 (0)
.... 1000 = Address signal digit: 8 (8)
E.164 Called party number digits: 632107608
Pointer to start of optional part: 9
Parameter: (t=10, l=9) Calling party number: Calling party numberCalling Party Number: 8780637304473
Optional Parameter: Calling party number (10)
Parameter Length: 9
1... .... = Odd/even indicator: odd number of address signals
.000 0010 = Nature of address indicator: unknown (national use) (2)
0... .... = NI indicator: complete
.001 .... = Numbering plan indicator: ISDN (Telephony) numbering plan ITU-T E.164 (1)
.... 00.. = Address presentation restricted indicator: presentation allowed (0)
.... ..11 = Screening indicator: network provided (3)
Calling Party Number: 8780637304473
Please check.
The Decode feature pipes the message through tshark and simply offers the JSON it produces back.
I dumped this SIP-I message on my kamailio and decoded it using tshark - v2.6.2.
Please try with JSON output and confirm its there using that format. This is tshark vs tshark.
If make pcap dump on the kamailio server and decod it using tshark as isup with json output, then everithing is ok. But if you download a pcap file from a Homer interface and decode it using tshark, then the ISUP is displayed incorrect. I guess that there are problems with the heplify server or the HEP protocol, since the kamailio sends the trace to the Homer using the HEP protocol.
Please star this repository to motivate the developers and to get higher priority! ⭐
If make pcap dump on the kamailio server and decod it using tshark as isup with json output, then everithing is ok. But if you download a pcap file from a Homer interface and decode it using tshark, then the ISUP is displayed incorrect. I guess that there are problems with the heplify server or the HEP protocol, since the kamailio sends the trace to the Homer using the HEP protocol.
I don't think so, because we don't touch nor modify SIP message and ISUP body. Please check one more time with JSON output.
Hello Alexandr,
I have made new test and saved pcap from kamailio and from Homer UI. Dumpes attached.
Archive.zip
I decoded both pcap file used tshark -T json and I see incorrect "Called Party Number" for file from Homer. "Calling Party Number" is absent at all.
What could be the reason?
tshark -r /tmp/kamailio.pcap -T json -Y isup
...
"Called Party NumberCalled Party Number: 637304473": {
"isup.parameter_type": "4",
"isup.mandatory_variable_parameter_pointer": "2",
"isup.parameter_length": "7",
"isup.isdn_odd_even_indicator": "1",
"isup.called_party_nature_of_address_indicator": "3",
"isup.inn_indicator": "1",
"isup.numbering_plan_indicator": "1",
"isup.called": "637304473",
"isup.called_tree": {
"isup.called_party_odd_address_signal_digit": "6",
"isup.called_party_even_address_signal_digit": "3",
"isup.called_party_odd_address_signal_digit": "7",
"isup.called_party_even_address_signal_digit": "3",
"isup.called_party_odd_address_signal_digit": "0",
"isup.called_party_even_address_signal_digit": "4",
"isup.called_party_odd_address_signal_digit": "4",
"isup.called_party_even_address_signal_digit": "7",
"isup.called_party_odd_address_signal_digit": "3",
"e164.called_party_number.digits": "637304473"
}
},
"isup.optional_parameter_part_pointer": "9",
"Parameter: (t=10, l=4) Calling party number: Calling party numberCalling Party Number: 5050": {
"isup.parameter_type": "10",
"isup.parameter_length": "4",
"isup.isdn_odd_even_indicator": "0",
"isup.calling_party_nature_of_address_indicator": "2",
"isup.ni_indicator": "0",
"isup.numbering_plan_indicator": "1",
"isup.address_presentation_restricted_indicator": "0",
"isup.screening_indicator": "3",
"isup.calling": "5050",
"isup.calling_tree": {
"isup.calling_party_odd_address_signal_digit": "5",
"isup.calling_party_even_address_signal_digit": "0",
"isup.calling_party_odd_address_signal_digit": "5",
"isup.calling_party_even_address_signal_digit": "0",
"e164.calling_party_number.digits": "5050"
}
},
...
tshark -r /tmp/export_from_HOMER.pcap -T json -Y isup
...
"Called Party NumberCalled Party Number: 5050": {
"isup.parameter_type": "4",
"isup.mandatory_variable_parameter_pointer": "7",
"isup.parameter_length": "4",
"isup.isdn_odd_even_indicator": "0",
"isup.called_party_nature_of_address_indicator": "2",
"isup.inn_indicator": "0",
"isup.numbering_plan_indicator": "1",
"isup.called": "5050",
"isup.called_tree": {
"isup.called_party_odd_address_signal_digit": "5",
"isup.called_party_even_address_signal_digit": "0",
"isup.called_party_odd_address_signal_digit": "5",
"isup.called_party_even_address_signal_digit": "0",
"e164.called_party_number.digits": "5050"
}
},
"isup.optional_parameter_part_pointer": "54"
}
...
Thanks!
Ok, I see the problem- ISUP is malformed and looks like during reassambling and storing into DB it was corrupted. Need to check if it postgres or golang. Can you check the stored message in pgsql ?
In attachment select from postgres:
SELECT * FROM public.hep_proto_1_call where sid = 'aaa93eb3-a188-123c-1f8e-0050569d49c8';
data-1689865098898.csv
Tables in DB were created by docker conteiner heplify-server.
Hello Alexandr,
Do you have any updates on this issue ?
@mmyshko not yet, need check why postgresql converts binary symbols. Probably need to store message in base64, but this is not good idea.... We will recheck it again in our lab