Well, actually, there are two strange behaviors...

I'm using a NMS CG6060 board with NA 2005-1 SP5 drivers. I've been trying to perform 2B-Transfers with no success 'til now (see viewtopic.php?t=547) so I'm testing the channel switching mechanism.

I've setup the T1, in coordination with the telco, to receive up to 15 incoming calls in the first 15 channels, so I have 8 outgoing channels to perform the call to the Customer Interaction Center (CIC).

For the switching I used a variation of the TransferDemo2 applications, with these differences:

• I'm not using a database to register the requests, just plain text files on a shared directory: CallinPool in port n sets a request for a transfer, like "rq.n" and when the CalloutPool application running in port m sees that request, deletes it (to avoid another CalloutPool to get it), places the outbound call and performs the channel switch to n. Similarly, when the agent in channel m hangs up, channel m creates "rs.n" so channel n knows when it should hangup.
• The destination number is not hard-coded; it's actively being read from an XML configuration file just before the Place Call step, so the CIC number can be altered at any time (by editing the file) and be used right away without restarting any channel.

Channel switching works just fine, but I'm seeing two strange behaviors when the server is under certain load of incoming calls (let's say from 4 to 10 concurrent incoming calls):

1. A call is not answered by the IVR; instead, it's automatically being answered by the customer representatives (at the CIC)

2. A call is supposedly being answered, but the caller does not hear the IVR menu,but just silence

For situation [1] I've checked with the telco and they confirm they are not autoforwarding calls to the CIC destination number when the T1 has no more free channels.

For situation [2] I'm not really sure if it's being answered by the IVR.

My questions: Have you seen any of those behaviors before? What would you do to diagnose what's going on? Do you think it's possible for the telco to look in realtime the caller ID of every incoming call, so as to know which channel answered a specific call (the one that exhibits any of these behaviors)?

The first thing you should check is that every Switch step resolves to a Switch Disconnect at some point. Having Switch connections that survive the duration of the call can cause this type of behaviour.

Situation 2 is possible with the Switch step, although I can't say for sure if that's what's happening to you. The best way to tell, is if you can have a look at the TFMonitor when this is happening. If you can figure out which port should have the accepted that call and if it is "moving", in other words the Steps displayed are changing, then it is possible your switch connection was not properly disconnected.

Beware of the "Listen only" check-box on the Switch step. For your purposes, you never want to check that box. That causes only 1/2 the connect to be made, as in the port that executes the step can only listen to the other port, it can't "talk". Conversely, the port it is connected to will only be able to talk. It can't hear anything.

Situation 1 does not sound possible. In order for the NMS card to auto-forward to the agent, it seems to me it would have to answer first, ie: go off hook. You should check this... do the agents have handsets that are always off-hook? Some equipment works this way. The PBX (or ACD or something) is continuously communicating with the handset. The agent is alerted via ring-tones or flashing lights when they have a new caller to talk to. Under this scenario, the previous call the agent had would never end (from the perspective of the handset connected to an IVR port). Under that scenario, it sounds more plausible that a persisting Switch connection is causing the behaviour.

On the other hand... that last paragraph was a lot of speculation on my part. I have not looked at this in a long time.

Switch Disconnect: Checked (it's been there all the time, not an issue).

Listen only check-box: Checked (well, actually, unchecked , it's been always unchecked).

Operator handsets or headsets: Regular ones, normally on-hook.

I'm about to start some controlled tests (previous results were obtained by our customer by performing unmonitored tests, so I can't really know what happened).

I'll post results after studying the captured logs (yes, now I'm capturing everything unlimited on a partition with 50GB of free disk space). I've also instructed the testers to annotate the time and result for each call, time previously synched with the IVR server's time, so I can pinpoint specific failures they might notice.

I'm also suggesting 3 scenarios: A low-load scenario just to verify 100% is attended just fine, a full-capacity load scenario to verify that at least 95% is attended and to checkout the transfer request & answer times and a final over-capacity load to check for missing calls, the strange auto-transfers, dropped calls and the like.

This sounds like a good approach.

When checking for Switch Disconnect steps, its important to keep in mind the paths that TeleFlow can follow unexpectedly, such as your hangup handlers and error handlers. Also, note that it is possible to redefine either or both of these. Make sure the handler in question is actually the one that gets used, and that it is reset to the previous handler after it no longer applies.

You were absolutely right about checking out the unexpected routes!

There was one scenario where situation [1], the "auto-transfer" behavior, could happen and was solved by taking care of the customer hangup before he gets switched to the CIC agent. Thanks a lot for that!

Situation [2] also happened because, when "auto-transfered" (situation [1] now fixed), CIC agents did not answer fast enough... To diagnose, I put a "ringing out" WAV file which showed just how slow they were at getting the call.

So, for now both issues are gone and I'm still expecting the results of a final call-load test now with these fixes.