Summary:	ASTERISK-25352: res_hep_rtcp correlation_id is different then res_hep
Reporter:	Kevin Scott Adams (nivek)	Labels:
Date Opened:	2015-08-28 14:45:21	Date Closed:	2016-05-14 09:49:29
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Resources/res_hep_rtcp
Versions:	13.4.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	CentOS 6 x86_64	Attachments:
Description:	When trying to correlate data using Web Homer there seems to be no RTCP data with the call flow. When researching further the data is in the Homer database but the res_hep is using call_id and res_hep_rtcp is using the channel name, so the Homer SQL lookup shows no data.
Comments:	By: Asterisk Team (asteriskteam) 2015-08-28 14:45:23.163-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: Rusty Newton (rnewton) 2015-09-05 11:39:42.876-0500 Kevin, can you attach a database dump showing the issue? (or a screenshot would probably suffice) I'll ping Matt Jordan (who wrote the modules) to have him take a look. By: Matt Jordan (mjordan) 2015-09-05 14:46:45.669-0500 The issue is correct - {{res_hep_pjsip}} tracks things by {{Call-ID}} (as we won't have a channel name when the {{INVITE}} request is first processed) and {{res_hep_rtcp}} tracks by Channel name, as it is independent of {{res_hep_pjsip}}. So, to tie both together, we really can't use the Channel name :-( With a small tweak in {{chan_pjsip}}'s {{dialplan_function}}, we can expose the SIP Call-ID. In {{res_hep_rtcp}}, we can then check the channel technology type and attempt to get the SIP Call-ID if the underlying channel type is a SIP ({{chan_sip}} or {{chan_pjsip}}) channel. If it's neither, we can always fall back to channel name. By: Matt Jordan (mjordan) 2015-09-05 15:25:11.863-0500 Note that the first patch that will need to be done is just to {{chan_pjsip}}, in order to extract the SIP call-id. By: Matt Jordan (mjordan) 2015-09-05 19:16:01.253-0500 So, before I go all crazy and starting changing things... {{res_hep_pjsip}} will currently change the UUID when it can find the channel name. That will currently correlate to {{res_hep_rtcp}}'s UUID. The only thing that will be missed in this is the initial INVITE request that creates the channel. Clearly, changing this in {{res_hep_pjsip}} would be a breaking change... I'm just not sure that we'd care. Before I make a code change, please let me know if you see any value in having {{res_hep_pjsip}} switch the UUID from the Call-ID to the channel name. By: Kevin Scott Adams (nivek) 2015-09-08 11:37:22.343-0500 Gentlemen, Thank you for looking at this issue. Now, I have my opinion but you guys have more experience with SIP and RTP. I believe it should be the Call Id due to outside influences like I have. I am using Audiocodes, ACME Packet with Kamailio in the middle doing LCR and load balancing acts, that's why I think it should be the Call Id. The Channel ID would disconnect the Kamailio HEP data from Asterisk  data. Your thoughts? Thanks again, TheKev aka The Grand Wazoo (God I wish I could type) By: Matt Jordan (mjordan) 2015-09-29 16:36:31.712-0500 Sorry for not getting back on this quicker. I'm okay with going to the Call-ID and keeping it consistent with that. I'll work on a patch over the next few days.