I am trying to understand legs_json to review some of the more perplexing call log entries
I am trying to understand legs_json to review some of the more perplexing call log entries. My original assumption was that each leg represented a step in a calls journey through the system, such as call, pickup transferred, hung up. This might be partially true, but only leads to confusion.
I want to share my assumptions either as they were, or where they are now. The list is incomplete even if it were correct. I’d love to hear what anyone else can help explain. And, this might only be true for these calls.
One thing that help was this paragraph in Detailed Call Log Data:
Inspecting Multi-Leg Calls
Inspecting the
legsproperty of the multi-leg call, we can see two differentlegTypeproperties, the most recent (legs[0]) was theAcceptwhich occurred when the call was accepted on your SoftPhone, while the former (legs[1]) was thePstnToSipwhich occurred when the inbound call from my celluar device was pointed by RingCentral to the IVR setup within my account. Thefrom.nameproperty would not make sense if you were to neglect looking at the call legType.
Also, of the 3 links in
the first 2 do not exist. The 3rd requires permission. I asked but have not yet received.
I’ve been querying the data (imported into postgresql). Here’s one interesting query, give me there amount of steps, what percentage of inbound calls have that many steps, and what percentages of outbound calls have that many steps. It returned 27 rows ending on 46 steps. Here’s the first 7.
| legs | in | out |
|---|---|---|
| 1 | 3.38% | 95.94% |
| 2 | 21.73% | 4.04% |
| 3 | 17.44% | 0.02% |
| 4 | 51.20% | 0.00% |
| 5 | 4.26% | 0.00% |
| 6 | 1.46% | 0.00% |
| 7 | 0.17% | 0.00% |
Assumption #1: The first leg is always the master. False
| leg | in | out |
|---|---|---|
| 1 | 99.57% | 99.97% |
| 2 | 0.43% | 0.03% |
When it was step 2, step 1 was almost always SipToPstnMetered for Inbound (5 cases of Accept though), and outbound was RingOutClientToSubscriber about 75% of the time, and SipToPstnUnmetered in the rest.
Assumption #2: When the first step is outbound, all steps are outbound. True
All outbound legs are working toward that outbound call.
Assumption #3: When the first step is Inbound, all steps are Inbound. False
When an Inbound call comes in, if the answerer is already connected, there should be just one leg. If they enter a queue, that is a second leg. Both of those would be Inbound. If the answerer is not connected to the system, when they answer, they first connect to the system. This is considered Outbound. After the connection to the system when they then connect to the actual caller, that is another Outbound leg.
Another few things i seem to have learnt:
When a call goes into a queue, it may ring more than one person (based on the rules setup for the system). Even for the person, it may ring multiple devices, such as a physical phone and a sip phone. When the call is picked up, all the others are Stopped.
When a call goes straight to voicemail, there are two legs. One for the call in, a second for the transfer to vm.
When the person is transferred to a queue, the from name is [queue name] [caller name]. To get the caller name, you have to remove the queue name, which can be found as the to name in the step where it transfers to the queue.
When the from name and to name are the same person, it indicates an internal call (such as to another phone or ghosting a call).
Again, all these are assumptions. If they are true, i hope they help others trying to figure this stuff out.