I have a very odd issue. An agent takes a call, i single step a recording device and am able to record the call. After the call ends, i clear the recording device. I then request a snapshot of the recording device and it says the device is idle and in service. Three mins later, the agent takes another call. I attempt to single step the same recording device and get a media stopped event. I attempt to single step the call again after 300ms and get another media stopped event. I don't get a single step conf event and therefore miss the call. This is affecting 1% of the total volume of calls.

This really isn't a problem to discuss in the forums effectively please consider opening a ticket.

when you clear the call, do you get a media stopped event?
What other activity do the AES logs show for the recording device in the interval between the first and second calls if any?
What is the traffic load on AE Services?
Does this impact random agents or a certain pool?
Does this impact random recorders or a certain pool?
Is it reproducible in a lab environment?

If calls are coming on over a SIP trunk, you may be experiencing a problem that became apparent last year. If the SSC request arrives very quickly after the agent answers the call it may arrive while the call is being shuffled. This can cause problems like you are seeing.

The solution is to upgrade Communication Manager to the latest version. It will then reject the SSC request if it is received while the call is being shuffled. The application can then retry the SSC after 200-300mS.

A workaround/test is to disable shuffling on the incoming trunk. I think the parameter for this is "Initial IP-IP Direct Media?" on page 1 of the signaling-group that is used by the trunk. Change this to "n" to disable shuffling.

Martin

Martin thx for the response. I already had code to work around the bug. I am currently servicing 1200 concurrent agents and i think load may be an issue. I have added another piece of code that will wait 2 secs and try again. This new code is working better but i'm still seeing issues where no matter how many times i try, i cannot single step the call.

you may be running out of Communication Manager VoIP resources. Have you checked what the consumption is? at the sat use the list measurements commands to look for resource exhaustion.

Martin, what would happen if i try to single step a call but the port i specified for audio to come in on, was already being used. Would that explain this?

relative to your question about the port being in use at the recorder, Communication Manager doesn't know that the port is in use, and would try to setup the connection and I believe you would see the media start event (which you say you are not). Of course the port wouldn't accept the packet traffic so you wouldn't get audio for the call. my bet is on Communication Manager blocking the SSC request for some reason.

VoIP Resource exhaustion is one reason that could happen.
Additionally, you could look at the display events (type denial) to see if you are seeing denial reasons in the time period the SSCs are failing.

John you once suggested the following query to me:
"list measurements ip dsp-resource hourly 1 Page 1"

Would that help indicate the exhaustion problem?

yes, that is one of a couple of 'list measurement' commands that would indicate VoIP resource exhaustion was occurring.

John, Martin, i believe i found what the issue may be. I did not know that there was another application recording the same agents. I assume that media resources are shared and not pooled. Unless either of you believe otherwise, i think this matter is closed.

A second recorder is allowed.l One case that creates a issue is if you were running up against the 6 party limit. Communication manager views the recorder as a party in the call. There are other features that could be activated like exclusion, that would have prevented another party from joining the call.

I am happy dropping this if stopping the other recorder allows your recorder to 'work.'

We are seeing this issue of getting a media stopped event happen right after we attempt to single step. We had the client pull the dmcc log files and we are seeing the following error and code

Error Code 33: Device was not available for this operation

What does this error code mean? could it be the reason for why i can't single step?

When using services from the call control group, be aware that they come from TSAPI and thus the TSAPI for Communication Manager Programmer's documentation is a valuable reference.

In this case under the Single Step Conference method description the error code 33 is described (sometimes you need to look in Appendix B)

RESOURCE_BUSY (33) (CS0/17) – The deviceToBeJoin is busy or not in the idle state.

Thus, my guess is that you are SSC'ign in a device that is in use recording another call, or you are not allowing a sufficient interval between releasing it from one call before adding it into another call (500ms should be adequate under normal load), or you are using recording devices that are not yet fully registered yet.

John, i looked at a particular softphone that i am using to try and single step and what i have seen is that for some reason today (after a restart of my application) i have been unable to single step with that phone. I was able to do so previous to the restart. I also verified that i got a successful terminal registration (no resource busy error) and I have verified that there are mins in between single step conference requests. I am at a loss as to what i am doing wrong.

So you have a soft phone (A) and that soft phone can call some other device successfully (B) and establish a talk path. Right?
While that call is established, you try to SSC in your DMCC recorder (C) on behalf of party B.

That fails with Resource Busy (33) indication?

Am I the same page with the use case you are executing?
I would start with a SAT list trace station <B> in the interval that you are SSCing in the recorder C.
I would also try mimicking the application's behavior using the DMCC dashboard (included in the DMCC .NET SDK download) so i understood if I had a switch side issue or application side issue.