Thanks Ryan, that makes sense! Some of the calls specifically where to an IVR system, and our long distance provider prompts for a PIN, which will probably account all of those cases. Will do a bit more poking around on it but that sounds like the cause.
<br><br><div><span class="gmail_quote">On 2/8/06, <b class="gmail_sendername">Ryan Ratliff</b> <<a href="mailto:rratliff@cisco.com">rratliff@cisco.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Many IVRs will not actually put the call into a Connected state until<br>you reach an agent. Also happens with carriers that ask you for a<br>pin when dialing long distance, etc.<br><br>I think Amex was one that generated a ton of cases back in the day
<br>because of dtmf issues when the voice path was established but the<br>call wasn't yet connected.<br><br>-Ryan<br><br>On Feb 8, 2006, at 10:32 AM, Ed Leatherman wrote:<br><br>Was looking through some CDRs to dig up some stats on a disputed long
<br>distance call.. Happened to notice there were a number of calls that<br>had a dateTimeOrigination that was normal, a dateTimeConnect which<br>was 0, and a dateTimeDisconnect that was normal and anywhere from 3<br>to 20 sec later than the Origination Time. Does this mean the call
<br>failed to connect? duration on all those calls is also 0. the<br>dateTimeConnect has me a little puzzled.<br><br>--<br>Ed Leatherman<br>IP Telephony Coordinator<br>West Virginia University<br>Telecommunications and Network Operations
<br>_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip">
https://puck.nether.net/mailman/listinfo/cisco-voip</a><br><br></blockquote></div><br><br clear="all"><br>-- <br>Ed Leatherman<br>IP Telephony Coordinator<br>West Virginia University<br>Telecommunications and Network Operations