<div>Mike, my friend, you have hit the nail on the head - and thanks for the support - it's good to know I'm not alone with this issue.</div>
<div> </div>
<div>I am working with 4 customer callcentre sites to resolve this problem. 3 sites are in Melbourne (Aus) and one in Auckland. The Auckland site is dialing international back to Australia.</div>
<div> </div>
<div>Oddly, the telco in New Zealand is providing a much richer PROGRESS indication set for internationally dialled numbers than I am getting for the same numbers dialled locally from here in Melbourne. Although it's not true for all numbers, the ones in question have no cause code associated with the PROGRESS indication and they all seem to have voice treatment during the PROGRESS indication - kindly telling me that I have dialled a wrong number, or that it is going to divert off somewhere else.
</div>
<div> </div>
<div>All sites have requested out of band indications for PRI, but it looks like the only way to resolve this issue once and for all telcos is to assume that we are going to hang up immediately we receive a PROGRESS indication. I know this is not ideal and will result in quite a few false positives but it is likely to be right for more numbers than it is going to be wrong.
</div>
<div> </div>
<div>I'd be grateful for your thoughts on this direction. Your comments so far have been very useful. </div>
<div> </div>
<div>As for the telco's saying PRI is "good but not perfect" - I would struggle to understand how they would improve on this position. I mean what else is available for multi-channel exchange termination?</div>
<div> </div>
<div>cheers,</div>
<div> </div>
<div>Mark.</div>
<div> </div>
<div><br><br> </div>
<div><span class="gmail_quote">On 1/23/07, <b class="gmail_sendername">Michael Collins</b> <<a href="mailto:mcollins@fcnetwork.com">mcollins@fcnetwork.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> The correct way to determine the ending cause of a call is the<br>> ${HANGUPCAUSE} variable that Dial creats. Just to be sure, set
<br>> priindication=outofband in /etc/asterisk/zapata.conf. HANGUPCAUSE<br>> should always be set.<br>><br><br>HANGUPCAUSE is indeed always set. The question is, Set with what data?<br>The problem is that the telco doesn't consistently and uniformly send
<br>back the Q.931 hangup cause. Believe me, I've pored over mountains of<br>Q.931 logs, both with inband and outofband signaling. The telcos just<br>plain suck at delivering this information consistently. They usually
<br>get it right, but when you are making tens of thousands of dial attempts<br>per day and the telco is giving you accurate info 90% of the time then<br>you still have 100's of call records with suspect data. Garbage in,
<br>garbage out.<br><br>My work around is to make multiple attempts on so-called invalid numbers<br>and to keep track of the results. If I dial a phone number and get<br>hangup cause 16 less than two seconds after the dial attempt, and if I
<br>can repeat that result, then I assume it is truly a disconnected or<br>otherwise invalid number.<br><br>-MC<br>_______________________________________________<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">
Easynews.com</a> --<br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users
</a><br></blockquote></div><br><br clear="all"><br>-- <br>regards,<br><br>Mark P. Edwards