Call Leg 'Final Remote Session ID' values changing between API methods

[BlakeR]

Hello,

We use two different API methods to collect Webex Calling call legs for analytical reporting for our customers.

The 1st method used is the `v1/cdr_feed` GET API call. See: https://developer.webex.com/docs/api/v1/reports-detailed-call-history/get-detailed-call-history
We try to gather data in near real-time for our customers and this allows us to gather the last 48 hours of call legs in near real-time.

The 2nd method is the for call legs older then 48 hours is scheduling and downloading the `Webex Calling Detailed Call History` report using the API calls listed under this link: https://developer.webex.com/docs/api/v1/reports.
We will run this report after 24 hours to make sure that the cdr_feed did not miss any call legs.

We have noticed that upwards of 20% of the call legs gathered using the 1st method will have a null `Finale Remote Session ID` values that are updated to not null values in the 2nd method.

This hampers our ability to provide accurate cradle-to-grave analytics for call legs for 'today'.

Can you provide additional information into why the values change between the two API methods?

[lucasmeier599]

I think the difference in processing between the two APIs explains the inconsistent values. For real time analytics, matching records by report id seems like the most reliable approach until Cisco provides more detailed documentation.

[cdrguru]

@BlakeR  Likely the same CDR at two processing stages: cdr_feed before Final Remote Session ID is populated, and the report after. Cisco does not document this enrichment. Match by Report ID to verify. For continuous ingestion, use cdr_stream, which filters on database-write time rather than call start time.

-Paul (CDRGuru)