Using ESL, all RTCP events are to and from 127.0.0.1

[noahmehl]

Even though all RTP parties have public IP addresses...

[lmangani]

@noahmehl this is entirely depending on whatever your ESL is providing the script with, see code:

srcIp: e.getHeader('variable_local_media_ip') ? e.getHeader('variable_local_media_ip') : '127.0.0.1',
dstIp: e.getHeader('variable_remote_audio_ip_reported') ? e.getHeader('variable_remote_audio_ip_reported') : '127.0.0.1',
srcPort: parseInt(e.getHeader('variable_local_media_port')) ? parseInt(e.getHeader('variable_local_media_port')) : 0,
dstPort: parseInt(e.getHeader('variable_remote_media_port')) ? parseInt(e.getHeader('variable_remote_media_port')) : 0,

[noahmehl]

@lmangani you're right, that it would depend, but even when reviewing the code, we don't understand how this would even find a correlation between an "RECV_RTCP_MESSAGE" and the actual details of " CHANNEL_CREATE" etc. Here's an example of the RECV_RTCP_MESSAGE payload from our Freeswitch ESL (connected via telnet):

`Content-Length: 954 Content-Type: text/event-plain

Event-Name: RECV_RTCP_MESSAGE Core-UUID: 0f60a212-44e4-11e8-a82b-7d807349e5e1 FreeSWITCH-Hostname: sbc-02-us-west-1.domain.com FreeSWITCH-Switchname: sbc-02-us-west-1.domain.com FreeSWITCH-IPv4: 1.2.3.4 FreeSWITCH-IPv6: %3A%3A1 Event-Date-Local: 2018-04-21%2014%3A21%3A28 Event-Date-GMT: Sat,%2021%20Apr%202018%2014%3A21%3A28%20GMT Event-Date-Timestamp: 1524320488427683 Event-Calling-File: switch_core_media.c Event-Calling-Function: switch_core_media_read_frame Event-Calling-Line-Number: 2337 Event-Sequence: 8686 Unique-ID: KRqfehm05nAYsbBwZCxGfM-zo9eZZoOf SSRC: 00000000 NTP-Most-Significant-Word: 0 NTP-Least-Significant-Word: 0 RTP-Timestamp: 0 Sender-Packet-Count: 0 Octect-Packet-Count: 0 Last-RTP-Timestamp: 0 RTP-Rate: 48000 Capture-Time: 1524320488440287 Source0-SSRC: 00000000 Source0-Fraction: 0 Source0-Lost: 0 Source0-Loss-Avg: 0 Source0-Highest-Sequence-Number-Received: 0 Source0-Jitter: 0 Source0-LSR: 0 Source0-DLSR: 0`

The function from: https://github.com/sipcapture/hepipe.js/blob/09fb9e6dde8b3b8e3b5b87c95995ac6556d6b24a/esl-client.js#L165 seems to be expecting two more headers from this message:

variable_local_media_ip variable_remote_audio_ip_reported

We're wondering if either:

1. There's some kind of Freeswitch or dial plan setup that's expected to include those variables in the "RECV_RTCP_MESSAGE" EVENT?
2. We need to correlate the values from previous events to make up this data? However, other events don't share the same variable names. For instance, in "CHANNEL_ANSWER" has the following headers:

variable_local_media_ip: 1.2.3.4 variable_remote_media_ip: 10.2.1.2

This is interesting because the code is looking for "variable_remote_audio_ip_reported", which doesn't exist in our events, at all...

[lmangani]

There's quite a lot of correlation ongoing in the background and being stored in memory to link and backfill details between events of different type. I didn; t have a chance to review your workflow but I'm quite certain we have a number of users successfully extracting data so perhaps you can plant a few debug hooks in the code and/our better outline the current vs. expected results with the specific details.

[lmangani]

If you end up identifying the missing correlation step you can pull a cached CID as in the following example:

db.get(e.getHeader('Other-Leg-Unique-ID')).cid

[noahmehl]

@lmangani We see where Receptacle is being used to set some values:

https://github.com/sipcapture/hepipe.js/blob/09fb9e6dde8b3b8e3b5b87c95995ac6556d6b24a/esl-client.js#L93-L115

However, as far as we can tell, none of the aforementioned headers are being set.

Is there another place this is happening?

[noahmehl]

I think we understand, and we're working on a PR for this.

[noahmehl]

https://github.com/sipcapture/hepipe.js/pull/20

[noahmehl]

Any update on this?