Page 1 of 1

possible bug in FastAGI_log.pl

PostPosted: Mon Apr 22, 2013 1:17 pm
by bobbymc
there is a line that starts like this

Code: Select all
if ( ($PRI =~ /^PRI$/) && ($callerid =~ /\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d/)


And i understand its logic, what my issue is, some calls get a dialstatus called CANCEL. When this happens the lead is kept as NEw which in my opinion is not correct. it should be NA.

Maybe im not understanding the process right but the definition of CANCEL in voip-info is

CANCEL: Call is cancelled. The dial command reached its number but the caller hung up before the callee picked up.


This means the dialer hit the dial timeout seconds. but if this was the cause for all calls all should be kept as NEW and never set to NA.


Matt can you possible shed some light on this please?


Thank you

Re: possible bug in FastAGI_log.pl

PostPosted: Mon Apr 22, 2013 1:18 pm
by bobbymc
FASTagiout.2013-04-22:2013-04-22 5:26:55|VDfastAGI|call_log|-- VD_hangup Local DEBUG: |PRI: PRI|callerid: V4220526190142319912|Dialstatus: CANCEL|hangupcause: 0|
FASTagiout.2013-04-22:2013-04-22 6:52:25|VDfastAGI|call_log|-- VD_hangup Local DEBUG: |PRI: PRI|callerid: V4220651480142319912|Dialstatus: CANCEL|hangupcause: 0|


its strange but the hangup cause is 0

Re: possible bug in FastAGI_log.pl

PostPosted: Mon Apr 22, 2013 1:41 pm
by mflorell
CANCELs are a code of 0 because it is not the carrier that is stopping the call, so there is no code received.

Most of the called leads that still show up as NEW status are not CANCELs, but in more recent code now show up as LRERR status, because they are Local/ channel resolution errors.

Re: possible bug in FastAGI_log.pl

PostPosted: Mon Apr 22, 2013 1:54 pm
by bobbymc
unfortunately i have a bit older version due to the customization we did for this customer. i have no issue going in and fixing it. what do you suggest i do with these CANCEL requests? add a if statement in there to let the logic happen as if it was congestion and other types and handle the logic in there or do i fix the CANCEls somewhere else?

Re: possible bug in FastAGI_log.pl

PostPosted: Mon Apr 22, 2013 6:22 pm
by williamconley
What we have done in a few cases is piggyback the CPD code just above that (or below, I forget). Choose a CPD disposition you would like to assign to this call type (in this case something that simply represents No Answer) and tell the system that Sangoma chose this status with the appropriate variable. Then the system will clear the call out properly for that call type and in older systems it will be much more efficient than a regular NA status.

Re: possible bug in FastAGI_log.pl

PostPosted: Tue Apr 23, 2013 6:58 pm
by bobbymc
i jsut hard coded it.. thx