ASTERISK-26430: res_hep: will fail, when an IPv6 interface is enabled on the installed server

[Home]

Summary: ASTERISK-26430: res_hep: will fail, when an IPv6 interface is enabled on the installed server

Reporter: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) Labels:

Date Opened: 2016-10-01 09:17:17 Date Closed:

Priority: Major Regression?

Status: Open/New Components: Resources/res_hep Resources/res_rtp_asterisk

Versions: GIT Frequency of
Occurrence Constant

Related
Issues:

Environment: Attachments:

Description: When trying to utilize res_hep, while the server has an IPv6 IP address defined, the HEP report will fail, notifying the console:

[Oct 1 13:56:37] NOTICE[14719]: res_hep.c:466 hep_queue_cb: Unable to send packet: Address Family mismatch between source/destination

Additional information:

In order to investigate, I've added a couple of ast_log entries, in order to ascertain the actual discrepancy. The following is observed when the issue arises:

{noformat}
[Oct 1 13:56:37] NOTICE[14719]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
[Oct 1 13:56:37] NOTICE[14719]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 1 13:56:37] NOTICE[14719]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
[Oct 1 13:56:37] NOTICE[14719]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 1 13:56:37] NOTICE[14719]: res_hep.c:467 hep_queue_cb: Sending from: 1
[Oct 1 13:56:37] NOTICE[14719]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 10
[Oct 1 13:56:37] NOTICE[14719]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 1 13:56:37] NOTICE[14719]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 28
[Oct 1 13:56:37] NOTICE[14719]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 1 13:56:37] NOTICE[14719]: res_hep.c:468 hep_queue_cb: To server: 0
{noformat}

The above was generated using:

{code:java|borderStyle=solid}
int ast_sockaddr_is_ipv4(const struct ast_sockaddr *addr)
{
ast_log(AST_LOG_NOTICE, "My address family is: %d\n", addr->ss.ss_family);
ast_log(AST_LOG_NOTICE, "My address family should be: %d\n", AF_INET);
ast_log(AST_LOG_NOTICE, "My address length is: %d\n", addr->len);
ast_log(AST_LOG_NOTICE, "My address length should be: %u\n", sizeof(struct sockaddr_in));

return addr->ss.ss_family == AF_INET &&
addr->len == sizeof(struct sockaddr_in);
}
{code}

Now, if I disable IPv6 on the machine, using the following:

{noformat}
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1
{noformat}

Now, the Asterisk output is as following:

{noformat}
[Oct 1 14:07:25] NOTICE[14975]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
[Oct 1 14:07:25] NOTICE[14975]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 1 14:07:25] NOTICE[14975]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
[Oct 1 14:07:25] NOTICE[14975]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 1 14:07:25] NOTICE[14975]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
[Oct 1 14:07:25] NOTICE[14975]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 1 14:07:25] NOTICE[14975]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
[Oct 1 14:07:25] NOTICE[14975]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
{noformat}

So, this is somewhat of an issue, as most cloud providers these day will enable by-default IPv6 addressing on the servers, making the module unusable till it's disabled - which is somewhat counter productive.

In order to validate potential configuration issues, I've tried changing my HEP server from IP:PORT combo, to only IP address - that caused Asterisk to go completely nuts. Recommendation, separate host ip and port to two separate configuration items, to avoid confusion.

Comments: By: Asterisk Team (asteriskteam) 2016-10-01 09:17:18.733-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Joshua C. Colp (jcolp) 2016-10-04 12:32:41.261-0500

I believe [~gjoseph] asked this on IRC but what Linux distribution is this under? We both run under this environment and see no problems, so it's probably something very environment specific. As well I assume using chan_sip?
By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2016-10-06 05:39:34.517-0500

Here is the information:

{noformat}
[root@vultr ~]# cat /etc/issue
CentOS release 6.8 (Final)
Kernel \r on an \m
[root@vultr ~]# uname -a
Linux vultr.guest 2.6.32-642.4.2.el6.x86_64 #1 SMP Tue Aug 23 19:58:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
{noformat}

Currently using chan_sip, not chan_pjsip - simply because it's a simple machine.
The code is applied with the patch from issue ASTERISK-26427, which corrects support for chan_sip and homer.

I'm using vultr.com vitrual host for this test, and my current platform shows:

{noformat}
[root@vultr ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Virtual CPU 714389bda930
stepping : 1
microcode : 1
cpu MHz : 3499.996
cache size : 4096 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc up rep_good xtopology unfair_spinlock pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm arat xsaveopt fsgsbase bmi1 avx2 smep bmi2 erms invpcid
bogomips : 6999.99
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:

[root@vultr ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 56:00:00:38:2b:53 brd ff:ff:ff:ff:ff:ff
inet 45.76.0.142/23 brd 255.255.254.0 scope global eth0
inet6 fe80::5400:ff:fe38:2b53/64 scope link
valid_lft forever preferred_lft forever

{noformat}

By: Matt Jordan (mjordan) 2016-10-06 13:18:33.260-0500

I think this may be in whatever code is calling this.

res_hep uses pretty standard Asterisk constructs to determine if something is an IPv4 or an IPv6 address:

{code}
if (ast_sockaddr_is_ipv4(&capture_info->src_addr)) {
INITIALIZE_GENERIC_HEP_CHUNK_DATA(&hg_pkt.ip_family,
CHUNK_TYPE_IP_PROTOCOL_FAMILY, AF_INET);

INITIALIZE_GENERIC_HEP_CHUNK(&ipv4_src, CHUNK_TYPE_IPV4_SRC_ADDR);
inet_pton(AF_INET, ast_sockaddr_stringify_addr(&capture_info->src_addr), &ipv4_src.data);

INITIALIZE_GENERIC_HEP_CHUNK(&ipv4_dst, CHUNK_TYPE_IPV4_DST_ADDR);
inet_pton(AF_INET, ast_sockaddr_stringify_addr(&capture_info->dst_addr), &ipv4_dst.data);

packet_len += (sizeof(ipv4_src) + sizeof(ipv4_dst));
} else {
INITIALIZE_GENERIC_HEP_CHUNK_DATA(&hg_pkt.ip_family,
CHUNK_TYPE_IP_PROTOCOL_FAMILY, AF_INET6);

INITIALIZE_GENERIC_HEP_CHUNK(&ipv6_src, CHUNK_TYPE_IPV6_SRC_ADDR);
inet_pton(AF_INET6, ast_sockaddr_stringify_addr(&capture_info->src_addr), &ipv6_src.data);

INITIALIZE_GENERIC_HEP_CHUNK(&ipv6_dst, CHUNK_TYPE_IPV6_DST_ADDR);
inet_pton(AF_INET6, ast_sockaddr_stringify_addr(&capture_info->dst_addr), &ipv6_dst.data);

packet_len += (sizeof(ipv6_src) + sizeof(ipv6_dst));
}
{code}

What is the address in {{capture_info->src_addr}}? That should tell us why Asterisk believes it is an IPv4 address.
By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2016-10-06 16:37:20.122-0500

Well,

I added the following code to res_hep.c:

{noformat}
if (ast_sockaddr_is_ipv4(&capture_info->src_addr) != ast_sockaddr_is_ipv4(&capture_info->dst_addr)) {
ast_log(AST_LOG_NOTICE, "Unable to send packet: Address Family mismatch between source/destination\n");
ast_log(AST_LOG_NOTICE, "Sending from: %d\n", ast_sockaddr_is_ipv4(&capture_info->src_addr));
ast_log(AST_LOG_NOTICE, "To server: %d\n", ast_sockaddr_is_ipv4(&capture_info->dst_addr));
ast_log(AST_LOG_NOTICE, "Sending from: %s\n", ast_sockaddr_stringify(&capture_info->src_addr));
ast_log(AST_LOG_NOTICE, "To server: %s\n", ast_sockaddr_stringify(&capture_info->dst_addr));
return -1;
}
{noformat}

Now, the output on the CLI shows the following:

{noformat}
-- Executing [500@default:1] Playback("SIP/test-00000001", "demo-abouttotry") in new stack
[Oct 6 21:32:08] NOTICE[31965][C-00000002]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
[Oct 6 21:32:08] NOTICE[31965][C-00000002]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 6 21:32:08] NOTICE[31965][C-00000002]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
[Oct 6 21:32:08] NOTICE[31965][C-00000002]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
-- <SIP/test-00000001> Playing 'demo-abouttotry.gsm' (language 'en')

Got RTCP from 87.69.126.26:4001
PT: 200(Sender Report)
Reception reports: 0
SSRC of sender: 4121665413
NTP timestamp: 1475789527.2756153344
RTP timestamp: 1866069119
SPC: 2 SOC: 17

Got RTCP from 87.69.126.26:4001
PT: 202(Unknown)
Reception reports: 1
SSRC of sender: 4121665413
Received an SDES from 87.69.126.26:4001
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 10
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 28
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 6 21:32:08] NOTICE[31870]: res_hep.c:466 hep_queue_cb: Unable to send packet: Address Family mismatch between source/destination
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 6 21:32:08] NOTICE[31870]: res_hep.c:467 hep_queue_cb: Sending from: 1
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 10
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 28
[Oct 6 21:32:08] NOTICE[31870]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 6 21:32:08] NOTICE[31870]: res_hep.c:468 hep_queue_cb: To server: 0
[Oct 6 21:32:08] NOTICE[31870]: res_hep.c:469 hep_queue_cb: Sending from: 87.69.126.26:4001
[Oct 6 21:32:08] NOTICE[31870]: res_hep.c:470 hep_queue_cb: To server: [::1]:10645
* Sent RTCP SR to 87.69.126.26:4001
Our SSRC: 1545079116
Sent(NTP): 1475789533.3833950208
Sent(RTP): 240000
Sent packets: 250
Sent octets: 30021
Report block:
Their SSRC: 4121665413
Fraction lost: 0
Cumulative loss: 0
Highest seq no: 25233
IA jitter: 0.0066
Their last SR: 1096264780
DLSR: 4.9930 (sec)

[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 10
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 28
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 6 21:32:13] NOTICE[31870]: res_hep.c:466 hep_queue_cb: Unable to send packet: Address Family mismatch between source/destination
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 10
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 28
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 6 21:32:13] NOTICE[31870]: res_hep.c:467 hep_queue_cb: Sending from: 0
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
[Oct 6 21:32:13] NOTICE[31870]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 6 21:32:13] NOTICE[31870]: res_hep.c:468 hep_queue_cb: To server: 1
[Oct 6 21:32:13] NOTICE[31870]: res_hep.c:469 hep_queue_cb: Sending from: [::1]:10645
[Oct 6 21:32:13] NOTICE[31870]: res_hep.c:470 hep_queue_cb: To server: 87.69.126.26:4001
{noformat}

It would appear that Asterisk identifies itself using the IPv6 local address, while it identifies the remote UA as an IPv4
address correctly.
By: Matt Jordan (mjordan) 2016-10-06 17:21:15.102-0500

That didn't quite answer my question :-)

In your tests, what is the source address, and what is the destination address? Which one is IPv4, and which one is IPv6?

The code *does* make an assumption that the source/destination addresses are of the same family, which *may* be what is causing your problem. If so, it's a pretty easy fix, and doesn't involve changing any aspect of {{ast_sockaddr_is_ipv4}} or {{ast_sockaddr_is_ipv6}}. Knowing *what* those addresses actually are, however, would help answer that question.
By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2016-10-10 07:36:53.677-0500

Oh, sorry, allow me to re-share:

SIP UA: 2.53.146.150
Asterisk: 45.76.0.142

Generated the following output:

{noformat}
[Oct 10 12:32:31] NOTICE[20314]: res_hep.c:466 hep_queue_cb: Unable to send packet: Address Family mismatch between source/destination
[Oct 10 12:32:31] NOTICE[20314]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 2
[Oct 10 12:32:31] NOTICE[20314]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 10 12:32:31] NOTICE[20314]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 16
[Oct 10 12:32:31] NOTICE[20314]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 10 12:32:31] NOTICE[20314]: res_hep.c:467 hep_queue_cb: Sending from: 1
[Oct 10 12:32:31] NOTICE[20314]: netsock2.c:472 ast_sockaddr_is_ipv4: My address family is: 10
[Oct 10 12:32:31] NOTICE[20314]: netsock2.c:473 ast_sockaddr_is_ipv4: My address family should be: 2
[Oct 10 12:32:31] NOTICE[20314]: netsock2.c:474 ast_sockaddr_is_ipv4: My address length is: 28
[Oct 10 12:32:31] NOTICE[20314]: netsock2.c:475 ast_sockaddr_is_ipv4: My address length should be: 16
[Oct 10 12:32:31] NOTICE[20314]: res_hep.c:468 hep_queue_cb: To server: 0
[Oct 10 12:32:31] NOTICE[20314]: res_hep.c:469 hep_queue_cb: Sending from: 2.53.146.150:62456
[Oct 10 12:32:31] NOTICE[20314]: res_hep.c:470 hep_queue_cb: To server: [::1]:12257
> 0x7f478800bf30 -- Probation passed - setting RTP source address to 2.53.146.150:62453
{noformat}

It would seem that the RTCP reports are generated with the Asterisk server referring to the IPv6 localhost,
instead of the IPv4 external address.

By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2016-10-10 07:44:29.638-0500

Well, I tried commenting out the following block:

{noformat}
/*
if (ast_sockaddr_is_ipv4(&capture_info->src_addr) != ast_sockaddr_is_ipv4(&capture_info->dst_addr)) {
ast_log(AST_LOG_NOTICE, "Unable to send packet: Address Family mismatch between source/destination\n");
ast_log(AST_LOG_NOTICE, "Sending from: %d\n", ast_sockaddr_is_ipv4(&capture_info->src_addr));
ast_log(AST_LOG_NOTICE, "To server: %d\n", ast_sockaddr_is_ipv4(&capture_info->dst_addr));
ast_log(AST_LOG_NOTICE, "Sending from: %s\n", ast_sockaddr_stringify(&capture_info->src_addr));
ast_log(AST_LOG_NOTICE, "To server: %s\n", ast_sockaddr_stringify(&capture_info->dst_addr));
return -1;
}
*/
{noformat}

Coming to think about it, why would an RTCP report care what are the to/from senders? after all, the correlation is call-id based, and that will normally be unique for the machine itself, thus, making this check somewhat counter-productive, no?

Also, when I think about it deeper, this check actually prevents Asterisk from working as an IPv4/v6 bridging device,
when it comes to HEP reporting - which means, there is a chance that code shouldn't be there all.
By: Joshua C. Colp (jcolp) 2016-10-10 08:16:02.387-0500

Each side of a call is completely independent. Even if one side was IPv4 and the other side was IPv6 in a 2 channel Dial() scenario it would still be fine. The source address refers to the source Asterisk IP address, and the destination is the remote.

As for your question about caring - RTCP itself doesn't. That address information, however, is placed into the HEP report. As it was a reasonable assumption that both source and destination will use the same address family [~mjordan] wrote the code as such. As I'm unfamiliar with the HEP protocol I'm not even sure it's possible to have a source and destination use different address families. I also can't even come up with a scenario where you would. Even if an IPv4 address is mapped, it's still an IPv6 address which goes back to the question:

Why is it an IPv6 address when it should be an IPv4. That's the core of the problem. It _should_ be IPv4. That's the real bug, HEP just exposed it because it uses it. That's what ultimately needs to be determined here.
By: Joshua C. Colp (jcolp) 2016-10-10 08:17:42.801-0500

I also think the sip.conf would be useful here. For example: are you using "udpbinaddr=::"?
By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2016-10-10 08:22:22.633-0500

Actually it's setup with the default:

{noformat}
udpbindaddr=0.0.0.0 ; IP address to bind UDP listen socket to (0.0.0.0 binds to all)
{noformat}

This is a stock vanilla install.

By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2016-10-10 14:55:10.892-0500

Well,

According to ngrep, our HEP packets looks like this:

{noformat}
U 45.76.0.142:59365 -> 178.62.4.230:9060
HEP3.V............................2......
W......
.
../.............
.........
WE~......
.........&yFOfLs.zxlm-3NLnPiV64mTXZJCEm7hN......{"ssrc":1304398795,"type":200,"report_blocks":[],"report_count":0,"sender_information":{"ntp_timestamp_sec":"1476128929","ntp_timestamp_usec":"4281174200","rtp_timestamp":286317630,"packets":0,"octets":0}}

U 45.76.0.142:59365 -> 178.62.4.230:9060
HEP3........
.............2..............
W......
.
..-.............
.....................................................&yFOfLs.zxlm-3NLnPiV64mTXZJCEm7hN.....U{"ssrc":909466674,"type":200,"report_blocks":[{"lsr":"1864485015","ia_jitter":260,"fraction_lost":0,"source_ssrc":1304398795,"dlsr":327614,"packets_lost":0,"highest_seq_no":6528}],"report_count":1,"sender_information":{"ntp_timestamp_sec":"1476128936","ntp_timestamp_usec":"535743","rtp_timestamp":236160,"packets":247,"octets":29408}}

U 45.76.0.142:59365 -> 178.62.4.230:9060
HEP3..............................2......
W......
.
...(............
.........
WE~......
.........&yFOfLs.zxlm-3NLnPiV64mTXZJCEm7hN.....Z{"ssrc":1304398795,"type":200,"report_blocks":[{"lsr":"1864927526","ia_jitter":108,"fraction_lost":0,"source_ssrc":909466674,"dlsr":79745,"packets_lost":0,"highest_seq_no":2570}],"report_count":1,"sender_information":{"ntp_timestamp_sec":"1476128936","ntp_timestamp_usec":"4287618111","rtp_timestamp":286636446,"packets":333,"octets":4691}}

U 45.76.0.142:59365 -> 178.62.4.230:9060
HEP3........
.............2..............
W......
.
../,............
.....................................................&yFOfLs.zxlm-3NLnPiV64mTXZJCEm7hN.....U{"ssrc":909466674,"type":200,"report_blocks":[{"lsr":"1864920259","ia_jitter":194,"fraction_lost":0,"source_ssrc":1304398795,"dlsr":220659,"packets_lost":0,"highest_seq_no":6779}],"report_count":1,"sender_information":{"ntp_timestamp_sec":"1476128941","ntp_timestamp_usec":"536218","rtp_timestamp":476160,"packets":497,"octets":59296}}

U 45.76.0.142:59365 -> 178.62.4.230:9060
HEP3..............................2......
W......
.
...^............
.........
WE~......
.........&yFOfLs.zxlm-3NLnPiV64mTXZJCEm7hN.....[{"ssrc":1304398795,"type":200,"report_blocks":[{"lsr":"1865255237","ia_jitter":114,"fraction_lost":0,"source_ssrc":909466674,"dlsr":57835,"packets_lost":0,"highest_seq_no":2801}],"report_count":1,"sender_information":{"ntp_timestamp_sec":"1476128941","ntp_timestamp_usec":"4294901858","rtp_timestamp":286857206,"packets":563,"octets":10196}}
{noformat}

Now, if I extract the JSON data only, it looks like this:

{noformat}
{
"ssrc": 1304398795,
"type": 200,
"report_blocks": [],
"report_count": 0,
"sender_information": {
"ntp_timestamp_sec": "1476128929",
"ntp_timestamp_usec": "4281174200",
"rtp_timestamp": 286317630,
"packets": 0,
"octets": 0
}
}

{
"ssrc": 909466674,
"type": 200,
"report_blocks": [
{
"lsr": "1864485015",
"ia_jitter": 260,
"fraction_lost": 0,
"source_ssrc": 1304398795,
"dlsr": 327614,
"packets_lost": 0,
"highest_seq_no": 6528
}
],
"report_count": 1,
"sender_information": {
"ntp_timestamp_sec": "1476128936",
"ntp_timestamp_usec": "535743",
"rtp_timestamp": 236160,
"packets": 247,
"octets": 29408
}
}
{noformat}

As far as I can tell, the HEP3 protocol has nothing to do with the actual IP addresses, and is mostly reliant
on the call-id for the RTCP correlation - which makes much sense to me.

Regardless of the above, the question of:

{quote}
Why is it an IPv6 address when it should be an IPv4. That's the core of the problem. It should be IPv4. That's the real bug, HEP just exposed it because it uses it. That's what ultimately needs to be determined here.
{quote}

is for sure the right question, but I believe that providing a means of bypassing the issue for stage 1 will be sufficient, as the true cause of the issue is being investigated. Sure, it's a little hacky, but I think it's a step forward.