| Author |
Message |
|
|
|
jaydstein
Joined: Feb 1, 2017
Messages: 7
Offline
|
1. I have an active call between two parties.
2. I make use of CallControlService.consultationCall to place the current call on hold and spin-up a new call with another party.
3. If I release the newly-created consultation call with the other party and try to unhold the original call, I get a ResourceBusyException. This is unexpected, what am I missing here? How can I recover the original call?
|
|
|
 |
|
|
|
MartinFlynn
Joined: Nov 30, 2009
Messages: 1922
Online
|
What are you doing to take the call off-hold?
|
|
|
|
|
|
|
jaydstein
Joined: Feb 1, 2017
Messages: 7
Offline
|
CallControlService retrieveCall.
|
|
|
|
|
|
|
JohnBiggs
Joined: Jun 20, 2005
Messages: 1139
Location: Rural, Virginia
Offline
|
do you wait for the consultation call to clear (get a notification back for ConnectionCleared) before sending the retrieve? Is it possible that the retrieve is being done while the consultation call is still active?
|
|
|
|
|
|
|
jaydstein
Joined: Feb 1, 2017
Messages: 7
Offline
|
Yes, I'm definitely waiting for the call to clear. I'm using snapshotservice.snapshotDevice to get a list of all connections for my deviceId, the previously existing consultationCall isn't even in this list, just the original call that I'm expecting. With the appropriate HOLD and CONNECTED states as expected.
Do you guys have any ideas for troubleshooting the state of this call? I logged into AES and found some entries in the logs to verify my ResourceBusyException, but it's not enough information.
<135>Jan 9 21:00:17 clt-a7-aes-01 DmccMain[7398] -05:00 2018 923 1 com.avaya.aes | :CstaUnMarshalerNode-4: com.avaya.api.cmapi FINE - invokeID= 26 Routing request=session[session 5F97E82643FBB0642B84860CB6553FE3-150] ch.ecma.csta.binding.SnapshotDevice@40ffdb
<135>Jan 9 21:00:17 clt-a7-aes-01 DmccMain[7398] -05:00 2018 947 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.api.cmapi FINE - invokeID= 26 Sent response session[session 5F97E82643FBB0642B84860CB6553FE3-150] ch.ecma.csta.binding.SnapshotDeviceResponse@8b5004
<135>Jan 9 21:00:17 clt-a7-aes-01 DmccMain[7398] -05:00 2018 955 1 com.avaya.aes | :CstaUnMarshalerNode-1: com.avaya.api.cmapi FINE - invokeID= 27 Routing request=session[session 5F97E82643FBB0642B84860CB6553FE3-150] ch.ecma.csta.binding.RetrieveCall@16e7783
<132>Jan 9 21:00:18 clt-a7-aes-01 DmccMain[7398] -05:00 2018 047 1 com.avaya.aes | :DistributeCSTAEvent: com.avaya.async.impl.AsyncCallbackImpl WARNING - A service method threw an Exception when invoked!#012ServiceMethod: com.avaya.platform.broker.impl.AsyncServiceMethodImpl@b07ac6[com.avaya.cmapi.extsvc.CallControlServicesImpl@1213671, public void com.avaya.cmapi.extsvc.CallControlServicesImpl.retrieveCall(ch.ecma.csta.binding.RetrieveCall,com.avaya.api.async.AsynchronousCallback) throws ch.ecma.csta.errors.CstaException]#012Exception: ch.ecma.csta.errors.ResourceBusyException: Device was not available for this operation: error code 33#012Request: session[session 5F97E82643FBB0642B84860CB6553FE3-150] ch.ecma.csta.binding.RetrieveCall@16e7783
<135>Jan 9 21:00:18 clt-a7-aes-01 DmccMain[7398] -05:00 2018 048 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.api.cmapi FINE - invokeID= 27 Sent response ch.ecma.csta.errors.ResourceBusyException: Device was not available for this operation: error code 33
|
|
|
|
|
|
|
JohnBiggs
Joined: Jun 20, 2005
Messages: 1139
Location: Rural, Virginia
Offline
|
Enable TSAPI tracing, make sure that the right connection ID is being sent (for the party that has the held call), that somehow you are not using an incorrect connection ID.
Enable 'list trace station XXXX' at the sat while you are trying to retrieve the call, see if you get any denial events.
clear software proc_errors (I think the SAT command is 'clear software' or 'clear error') then as quickly as possible once that completes run the retrieve operation, and then do display software and see if there are any software errors you can reliably reproduce when you do the retrieve.
Are you attempting to reproduce this issue with the DMCC Dashboard or some super simplified known to work test tool, or just your application? Is this a standalone lab with nothing else going on, or a production environment and you may be fighting with other applications?
RESOURCE_BUSY (33) The switch is busy with another CSTA request. This
can happen when two TSAPI Services are issuing requests (for example, Hold
Call, Retrieve Call, Clear Connection, Conference Call, etc.) to the same
device.
The description of that error code implies you are fighting with another application... why that would occur consistently in a test environment with only one app running ...?IDK? but there is a lot about your environment that is not covered here. I would start with the TSAPI Exerciser or DMCC Dashboard and try to replicate the retrieve operation and see if anything is different as compared to your application.
|
|
|
|
|
|
|
jaydstein
Joined: Feb 1, 2017
Messages: 7
Offline
|
I'm not even sure I understand the problem well enough to explain it clearly, but it ended up being an issue of the held call not not being properly terminated via SIP. I ended up having to 'BYE' the sipConnection AFTER holding and BEFORE initiating the consultation call.
|
|
|
|
|
|
|
JohnBiggs
Joined: Jun 20, 2005
Messages: 1139
Location: Rural, Virginia
Offline
|
Good to know it is addressed. I wasn't even thinking about SIP being a potential part of the problem.
|
|
|
|
![[WWW]](https://www.devconnectprogram.com/forums/templates/bootstrap4/images/icon_www.gif){kind=icon}