You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using ATAPI to monitor Cisco phones. During a conference scenario we are sporadically getting an issue where ATAPI reported zero calls on monitored line although there was a call on physical phone. After adding logs in ATAPI source we found a race condition for updating the TapiCall::CallsMap dictionary. Log file : ATAPI_Logs_Log4net.txt
Below is the scenario:
A call is delivered on monitored line.
Answer the call
The calling party adds this call to conference
On getting OnCallStateChange callback with state as Conferenced, from within the callback we call the GetRelatedConferenceCalls to see all calls in the conference on the line.
From the logs/source code of GetRelatedConferenceCalls, we can see that this function created a new TapiCall and added to CallsMap. Soon, the LineCallback recceived TapiEvent.LINE_APPNEWCALL which also tried to add a new TapiCall to CallsMap but got exception "An item with the same key has already been added." As a result of this exception, TapiAddress::HandleNewCall was not called and there was no entry made in TapiAddress::_calls. So in the logs we still see the total call count =2 instead of 3 after call is added to conference: Log snippet : "hCall-66515 On LineId-515-TotalCallCount-2".
When the conferencing party drops out, the ATAPI library reported zero calls on line 515 as it missed this new call due to the exception.
Proposed changes:
Create a new function TapiCall::FindOrCreateCallByHandle to be used from TapiCall::GetRelatedConferenceCalls() and TapiLine::LineCallback() which locks the CallsMap and creates a new TapiCall if there is not already.
When calling GetRelatedConferenceCalls(), we sometimes saw call GUID as all zeros string. To fix this we need to update the TapiCall constructor to add the call to CallsMap at the very end.
TapiAddress::AddCall() needs to first check if there is a call with GUID already present before adding an entry to the _calls list.
Add try-catch block and traces to help debugging
These changes are in our local repo. I'm not able to create a branch on markjulmar/atapi.net to post the changes for your review.
Could you please share the information on submitting a pull-request to this repo ?
Best Regards,
Adinath
The text was updated successfully, but these errors were encountered:
Hi @markjulmar,
We are using ATAPI to monitor Cisco phones. During a conference scenario we are sporadically getting an issue where ATAPI reported zero calls on monitored line although there was a call on physical phone. After adding logs in ATAPI source we found a race condition for updating the TapiCall::CallsMap dictionary. Log file : ATAPI_Logs_Log4net.txt
Below is the scenario:
From the logs/source code of GetRelatedConferenceCalls, we can see that this function created a new TapiCall and added to CallsMap. Soon, the LineCallback recceived TapiEvent.LINE_APPNEWCALL which also tried to add a new TapiCall to CallsMap but got exception "An item with the same key has already been added." As a result of this exception, TapiAddress::HandleNewCall was not called and there was no entry made in TapiAddress::_calls. So in the logs we still see the total call count =2 instead of 3 after call is added to conference: Log snippet : "hCall-66515 On LineId-515-TotalCallCount-2".
When the conferencing party drops out, the ATAPI library reported zero calls on line 515 as it missed this new call due to the exception.
Proposed changes:
These changes are in our local repo. I'm not able to create a branch on markjulmar/atapi.net to post the changes for your review.
Could you please share the information on submitting a pull-request to this repo ?
Best Regards,
Adinath
The text was updated successfully, but these errors were encountered: