Asterisk + sipcapture

Asterisk Asterisk Support
1

Hello,

I want to start using the homer, but not everything works out.

I tested it on version Asterisk 14.6 and everything works. But when you try to analyze traffic on version 13.6, or what does not work. TCPDUMP look it:
Asterisk 14.6
IP 10.23.100.9.59110 > 192.168.10.205.9060: UDP, length 585
E…e…@.?.62
.d …
…#d.QTVHEP3.I… .
Y.M…
.
.
.g…
…

.d …
… foo…*07cba3e2-b9ea-49e2-9b2d-fb4963f91c5d…OPTIONS sip:192.168.180.8:5060 SIP/2.0
Via: SIP/2.0/UDP 10.23.100.9:5060;rport;branch=z9hG4bKPj179d0728-3f8f-450e-b55c-41210a0162a7
From: sip:from_lime_angarsk@10.23.100.9;tag=29806ed3-3f4d-4338-90a7-cbf5213f1530
To: sip:192.168.180.8
Contact: sip:from_lime_angarsk@10.23.100.9:5060
Call-ID: 07cba3e2-b9ea-49e2-9b2d-fb4963f91c5d
CSeq: 37497 OPTIONS
Max-Forwards: 70
User-Agent: Asterisk PBX 14.6.0
Content-Length: 0

…
IP 10.23.100.9.59110 > 192.168.10.205.9060: UDP, length 486
E…@.?.6B
.d …
…#d…U.HEP3…Fq…A… .
Y.M…
.
…rK…
…

.d …
…M… foo…*34e000b9-cde5-4767-8b47-fd11fc70ea00…V{“sender_information”:{“ntp_timestamp_sec”:“1503087888”,“packets”:977,“ntp_timestamp_usec”:“94736”,“octets”:156320,“rtp_timestamp”:66306856},“ssrc”:1381157176,“type”:200,“report_blocks”:[{“source_ssrc”:1476498262,“highest_seq_no”:18224,“fraction_lost”:0,“ia_jitter”:3,“packets_lost”:0,“lsr”:“3411028606”,“dlsr”:85065}],“report_count”:1}…
IP 10.23.100.9.59110 > 192.168.10.205.9060: UDP, length 493
E… .#@.?.6+
.d …
…#d…"^HEP3…C…A… .
Y.M…
.
…
…

.d …
…M… foo…*17ab03e9-7a39-4523-80af-4c6eb1a76bed…]{“sender_information”:{“ntp_timestamp_sec”:“1503087888”,“packets”:11491,“ntp_timestamp_usec”:“167929”,“octets”:1838560,“rtp_timestamp”:-677196568},“ssrc”:1528099911,“type”:200,“report_blocks”:[{“source_ssrc”:-457470284,“highest_seq_no”:41769,“fraction_lost”:0,“ia_jitter”:1,“packets_lost”:0,“lsr”:“3414499983”,“dlsr”:334954}],“report_count”:1}…

This dump contain sip header

Asterisk 13.6
IP 185.128.105.204.54417 > 192.168.10.205.9060: UDP, length 509
E…@.?.c…i…
…#d…HEP3…9;…Mq… .
Y.M]…
.
…
…

.]d…
…i… foo…;5c66d19c01893bb01506ce67007fb491@185.128.105.204:5060…{“sender_information”:{“ntp_timestamp_sec”:“1503087965”,“packets”:9001,“ntp_timestamp_usec”:“463464”,“octets”:1440160,“rtp_timestamp”:1267828248},“ssrc”:1673005473,“type”:200,“report_blocks”:[{“source_ssrc”:456102912,“highest_seq_no”:24480,“fraction_lost”:0,“ia_jitter”:20,“packets_lost”:0,“lsr”:“3419960726”,“dlsr”:327680}],“report_count”:1}…
IP 185.128.105.204.54417 > 192.168.10.205.9060: UDP, length 375
E…@.?.d…i…
…#d…`.HEP3.w…3I…B… .
Y.M]…
.
…
…

.]d…
…i… foo…;7bbe7960579a3c367a0f67af0475bebe@185.128.105.204:5060…{“sender_information”:{“ntp_timestamp_sec”:“1503087965”,“packets”:251,“ntp_timestamp_usec”:“468867”,“octets”:40160,“rtp_timestamp”:-328458912},“ssrc”:1788769252,“type”:200,“report_blocks”:[],“report_count”:0}…
IP 185.128.105.204.54417 > 192.168.10.205.9060: UDP, length 385
E…@.?.dx…i…
…#d…HEP3…B…3I… .
Y.M]…
.
…
…
…i…

.]d… foo…;7bbe7960579a3c367a0f67af0475bebe@185.128.105.204:5060…{“sender_information”:null,“ssrc”:1440362653,“type”:201,“report_blocks”:[{“source_ssrc”:1788769252,“highest_seq_no”:5154,“fraction_lost”:0,“ia_jitter”:22,“packets_lost”:0,“lsr”:“3420289031”,“dlsr”:0}],“report_count”:1}…
IP 185.128.105.204.54417 > 192.168.10.205.9060: UDP, length 509
E…@.?.c…i…
…#d…\HEP3…,…B#… .
Y.M]…
.
…
…

.]d…
…i… foo…;111812654e5d74fb19d752c8004aecb3@185.128.105.204:5060…{“sender_information”:{“ntp_timestamp_sec”:“1503087965”,“packets”:1000,“ntp_timestamp_usec”:“498933”,“octets”:160000,“rtp_timestamp”:-2051067888},“ssrc”:1424072571,“type”:200,“report_blocks”:[{“source_ssrc”:1109803059,“highest_seq_no”:32520,“fraction_lost”:0,“ia_jitter”:0,“packets_lost”:0,“lsr”:“3419963096”,“dlsr”:327614}],“report_count”:1}…

Not contain sip header.

What could be wrong?

2

but that’s related to the way you are capturing with tcpdump, not with asterisk. Try to dump to a file or use SNGREP to see it on console.

3

i’m sorry. It’s not sip dump. it’s dump module res_hep.so when listen on port 9060.

tcpdump -nqt -s 0 -A -i any port 9060 and host 10.23.100.9

4

HEP is an encapsulated package to be used by HOMER so maybe that’s why you didn’t see the headers, Better to use simple tcpdump or sngrep if you want to see it on the Linux console.

5

Well, the fact is that it is encapsulated in the 14 and 13 versions of the asterisk different data. In 14 version hep contain sip header. 13 version not contain. On dump it’s see.

6

OK. I will explain why this is necessary. I have already found out that the sip headers are transmitted only when using the PJSIP and the module res_hep_pjsip.so. It all works cool right out of the box. So instead of using captagent by Homer.
But the whole tale is corrupted when it comes to talking about WSS. The Captagent becomes helpless. From here and there is a desire to perform this task by the forces of an asterisk. And to avoid unnecessary modules in the system