When an alias uses port 0 to indicate "any port", the alias is correctly shown in the Search results for all the IP addresses (and optionally capture IDs) indicated by the alias.
However, when drawing the call flow, the relationship with the alias is broken, and the call flow shows the IP:port combination instead of the alias.
This is caused by the alias_cache hash using only the IP address as the key, when the port is 0, e.g. [10.0.10.1] => 'proxy_1', while the data for the call flow contains also the captured port, e.g. 10.0.10.1:5070.
The patch proposed, in case of failure of matching the data with the alias_cache key, extracts the IP address from the data and tries again to match it with an alias_cache key.
In my example, it would extract 10.0.10.1 from 10.0.10.1:5070 and will match it with the key [10.0.10.1], returning proxy_1.
When an alias uses port 0 to indicate "any port", the alias is correctly shown in the Search results for all the IP addresses (and optionally capture IDs) indicated by the alias. However, when drawing the call flow, the relationship with the alias is broken, and the call flow shows the IP:port combination instead of the alias. This is caused by the alias_cache hash using only the IP address as the key, when the port is 0, e.g.
[10.0.10.1] => 'proxy_1'
, while the data for the call flow contains also the captured port, e.g.10.0.10.1:5070
. The patch proposed, in case of failure of matching the data with the alias_cache key, extracts the IP address from the data and tries again to match it with an alias_cache key. In my example, it would extract10.0.10.1
from10.0.10.1:5070
and will match it with the key[10.0.10.1]
, returningproxy_1
.