Log call_id instead of session_id so we can match SIP calls
Description
Description
Details
Details
- Provenance
adigeo Authored on May 19 2020, 6:45 PM - Parents
- rMPf45f4623ea49: Added missing dependency
- Branches
- Unknown
- Tags
Event Timeline
Comment Actions
@adigeo: Why do you put the call-id everywhere? It is pointless and was explicitly designed to NOT put it everywhere so the log lines are not unreadable. You can easily find it: [session 5be48a9a-0609-4d95-8088-c31bb0e975ec] created (call-id: 5be48a9a-0609-4d95-8088-c31bb0e975ec from-tag: e571bafe-adc0-43e4-afd1-bfc80446e5ef). Then you know the session and the callid.
Is this case the callid is not very big, but it could be.
Now you reverted all the changes here and in CDRTool....
Comment Actions
Call-id is the unique key id accross all applications during a call. This must be logged always.
Using grep you can find all lines belonging to a call on multiple applications, instead of starting a forensic investigation that takes lot of time and knowledge.
Our customers have no clue how to relate the logs one to another while by doing a simple grep they are capable of finding all logs.
Same for CDRTool, in the web page with the list of active calls it was displayed some mediaproxy internally generated session_id that cannot be corelated with anything, as the cdrs and the database do not have such session id.
When I do grep call_id on journal all lines must appear not just bit an pieces liem it was.
Comment Actions
log lines are not unreadable. <-- I disagree, before they were not readable, now they are, as the call_id is in each line not just in the first line and customers can find all logs belonging to a call without buzzing us.