Fun with outbound, v2...
Wow, 2 years since my last post! I'll see if I can be a bit more regular.
A lot of what bridgeSpeak (my company) does is outbound. Ever since the original Speech Server JDP, it seems we're one of the few (very few I'm told) partners doing outbound via analog. It has been a rough road at times... Anyone who remembers the original SQL Server Notification Services triggering mechanism and/or v1 TIMs knows what I'm talking about.
Anyway, now we've been moving along with OCS Speech Server and I can't quite decide if I miss the "good old days" of outbound on 2004 R2, or if we're moving forward. It's difficult to tell in an analog world! So I thought I'd outline some of the challenges we've seen, some of the solutions we've found, and provide a jumping off point for anyone else in a similar situation.
One of the main challenges we face is that the gateways that provide the interface to the PBX/PSTN were not really built for this purpose (outbound IVR in particular). I'm not a telephony guy, so anyone can feel free to tell me I'm wrong. But just a simple comparison from the previous technology seems to make that case. With a Dialogic D41JCTLS card, you got some call progress analysis, answering machine detection, etc. You do not really get this in the gateway. Our initial thought was just to continue using the (more expensive) cards along with the TIMC. BUT the TIMC requires a TIM, and the TIM vendors are no longer licensing/supporting their TIMs. So the only scenario that the TIMC is good for that I'm aware of is to migrate an existing licensed 2004 deployment to 2007.
We have bounced back and forth between the AudioCodes (MP114FXO) and Dialogic. It seems that both manufacturers are working towards making their gateways more comparable to some of the telephony cards. They are introducing more call progress, tone detection, etc. We are happy to see this evolution, but it can still be a bit tricky. One hurdle we've had to jump is in regard to early media. Both gateways have some sort of 'instant' or 'voice detection' mode. When the setting is instant (early media), as soon as the call is initiated or set up the gateway sends the 200 OK back and starts streaming the call back to OCS. As far as OCS knows, the call is connected. Voice detection mode only starts streaming the data to OCS once it determines that something has answered the call, or some preconnect analysis (busy for example) prevents the call from being connected.
Here's the trouble. Since the gateways don't currently support answering machine detection, the application must do it. If you are using the DetectAnsweringMachineActivity and use the voice detection mode on the gateway, a 'hello' is generally going to be 'eaten' by the gateway's voice detection and will not be streamed to the app. So an end-user is generally going to have to say 'hello' twice in order for the application to determine that a human answered. This isn't as much of an issue if an answering machine answers because it is generally still talking when the DetectAnsweringMachine activity's turn starts. We have attempted to solve this by wrapping the DetectAnsweringMachine activity in a do-while loop. We set a configurable max number of times for it to loop, and continue looping while the activity's DetectionResult is none:
private
void whileNoneLoop_CodeCondition(object sender, ConditionalEventArgs e)
{
if (detectAnsweringMachineActivity1.DetectionResult == DetectionResult.None && loopCount < loopQuantity)
{
loopCount++;
e.Result = true;
return;
}
else
{
e.Result = false;
return;
}
}
The key here is that the gateway must be set to the 'Instant' mode so that it starts streaming data back to the application immediately. That way all utterances are availble to the application for analysis. This can present some issues with preconnect call analysis (busy, SIT, etc), and we are still working through some of those with the gateway vendors. If we get to the max loop count and the DetectionResult is still None, we just make an assumption about what it is and go from there.
We have also experimented with a very promising product from Paraxip, their NetBorder Call Analyzer. This is a software solution that can basically interject itself between the gateway and OCS (or any SIP UA I suppose) and provides Call Progress information. The trouble we have had here seems to be related to our analog lines. When we analyze the recorded SIT tones we get back, for example, the frequencies do not match up with the standard defintions and so the Call Analyzer is not recognizing them. Does anyone else use analog lines and have trouble detecting tones, etc? In any case, the Paraxip product looks very promising and their support has been very good.
We have also experienced some issues with the outbound message queue locking up (the queue itself works fine, but OCS stops pulling messages) and message priorities being ignored. Those have both been acknowledged as bugs from Microsoft and we are waiting on a fix to test those.
Anyway, I think this is long enough for now. I'd love to hear other people's feedback about using OCS for outbound calls!