Unraveling the mysteries of the CSTA
In Logging the CSTA message I referred to differences between the way TASIM produces the CSTA and the way that a real TIM does it. The differences are so significant that you have to really pay attention if you want to test for answering machine and such.
For example with TASIM the CSTA uses a <localConnectionInfo> node if the call is accepted places the call results in a <cause> node as shown below. If the call is not answered then the <LocalConnectionInfo> node is not in the CSTA and the <cause> node will contain "callNotAnswered".
<EstablishedEvent xmlns="http://www.ecma.ch/standards/ecma-323/csta/ed2">
<monitorCrossRefID>1</monitorCrossRefID>
<establishedConnection>
<callID>1</callID>
<deviceID typeOfNumber="dialingNumber">919043901567</deviceID>
</establishedConnection>
<answeringDevice>
<deviceIdentifier typeOfNumber="dialingNumber">919043901567</deviceIdentifier>
</answeringDevice>
<callingDevice>
<deviceIdentifier typeOfNumber="dialingNumber">5555555555</deviceIdentifier>
</callingDevice>
<calledDevice>
<deviceIdentifier typeOfNumber="dialingNumber">919043901567</deviceIdentifier>
</calledDevice>
<lastRedirectionDevice>
<numberDialed />
</lastRedirectionDevice>
<localConnectionInfo>connected</localConnectionInfo>
<cause>normal</cause>
</EstablishedEvent>
In a real world TIM the <cause> node will contain "networkSignal" if the call connects to something and you will need to check the <callAnalyis> node to determine if it is a human or answering machine etc. If the call is not answered then all you get is "callNotAnswered" in the <cause> node. If you are paying attention then you should have noticed that the <callAnalyis> node is only present when a connection to the remote end is made. The relevant parts of the CSTA will look like this if a connection is made (i.e. someone or something answers the phone)
//<![CDATA[
<cause>networkSignal</cause>
<networkCallingDevice>
<deviceIdentifier>8006772208</deviceIdentifier>
</networkCallingDevice>
<networkCalledDevice>
<deviceIdentifier>19043901567</deviceIdentifier>
</networkCalledDevice>
<associatedCalledDevice>
<deviceIdentifier>4</deviceIdentifier>
</associatedCalledDevice>
<extensions>
<privateData>
<private>
<callAnalysis xmlns="http='http://schemas.microsoft.com/speech/2003/08/CSTAPrivateData">answeringMachine://schemas.microsoft.com/speech/2003/08/CSTAPrivateData">answeringMachine</callAnalysis>
</private>
</privateData>
</extensions>
//]]>
In order to get the call type out so that you know how to proceed you will need code similar to this:
if (cstaMsg != null)
{
// set the namesspace
cstaMsg.ownerDocument.setProperty("SelectionNamespaces",
"xmlns:pri='http://schemas.microsoft.com/speech/2003/08/CSTAPrivateData'" xmlns:csta="http://www.ecma.ch/standards/ecma-323/csta/ed2");
// Set the call status for report purposes
cause = cstaMsg.selectSingleNode("/csta:EstablishedEvent/csta:cause").text;
// if succesful connection then get the call analysis data
if(cause == "networkSignal")
{
cause = cstaMsg.selectSingleNode("/csta:EstablishedEvent/csta:extensions/csta:privateData/csta:private/pri:callAnalysis").text;
}
siConnectionStatus.value = cause;
// for answering machines we want to read the data twice then hangup
//if((cause == "answeringMachine") || (cause == "notKnown") || (cause == "other"))
if(cause != "humanVoice")
answeringMachine = true;
// Uncomment following lione for debugging
//answeringMachine = false;
}
else
{
// if for some weir reason we get no cstaMsg then
// we'll play it safe and treat this as an asnwering machine
answeringMachine = true;
}
Values I have found using the Intervoice TIM are:
humanVoice
answering Machine
facsimileMachine
callNotAnswered
busy
notKnown
numberUnallocated
I've been after Microsoft to change the call status values TASIM uses and the CSTA format so that they are in line with real world TIMS. We will have to wait and see if they fix this.
Hopefully you will find this useful.
Please post your comments if you have questions, suggestions or find anything wrong with this post.