possible bug in FastAGI_log.pl

[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

[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

[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.

[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?

[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.

[bobbymc]

i jsut hard coded it.. thx