Страница 1 из 1

AEL. При ошибке не переходит в 'e' экстеншен.

СообщениеДобавлено: 08 авг 2018, 17:29
GoG
Доброго времени.

Есть диалплан на AEL:

Код: выделить все
context from-pstn-custom{
   _X.=> {   
   //  Get 1C
      Set(HASH(GETMANAGER_1C)=${ONES_GET_MANAGER_1C_2(${CALLERID(num)})});
      Log(NOTICE, GETMANAGER_1C(${CALLERID(num)})  = ${HASHKEYS(GETMANAGER_1C)},  ExistsManager?: ${HASH(GETMANAGER_1C,managername)}, ${HASH(GETMANAGER_1C,firmkod)}, ${HASH(GETMANAGER_1C,ContactInfo)}, ${HASH(GETMANAGER_1C,ContactInfo2)});
      Set(HASH(GETMANAGER,firmkod)=${HASH(GETMANAGER_1C,firmkod)});
   
   GetCBX:
     // Get CBX info:
      Agi(agi://127.0.0.1/cbx?to=${DST}&from=${CALLERID(num)}&name=${HASH(GETMANAGER_1C,ContactInfo)}&firmkod=${HASH(GETMANAGER_1C,firmkod)}&comment=${HASH(GETMANAGER_1C,ContactInfo2)}&isCompany=${IF($EXISTS(${HASH(GETMANAGER_1C,firmkod)})?true)}&manager=${HASH(GETMANAGER_1C,managername)});

      &locatemanager();

   }
       e => {
      NoOp(------------------> ERROR!!! <------------------);
      NoOp(------------------> $EXCEPTION(reason) <------------------);
      NoOp(------------------> $EXCEPTION(context) <------------------);
      NoOp(------------------> $EXCEPTION(exten) <------------------);
      NoOp(------------------> $EXCEPTION(priority) <------------------);

      jump ${CALLERID(num)},GetCBX;
       }
};


${ONES_GET_MANAGER_1C_2(${CALLERID(num)})}) выполняется с ошибкой: - например у сервера с БД поменялся IP:

Код: выделить все
[2018-08-08 14:53:37] WARNING[16379][C-0000068e]: res_odbc.c:958 odbc_obj_connect: res_odbc: Error SQLConnect=-1 errno=0 [unixODBC][Microsoft][ODBC Driver 11 for SQL Server]Login timeout expired
[2018-08-08 14:53:37] WARNING[16379][C-0000068e]: res_odbc.c:958 odbc_obj_connect: res_odbc: Error SQLConnect=-1 errno=0 [unixODBC][Microsoft][ODBC Driver 11 for SQL Server]Login timeout expired
[2018-08-08 14:53:37] ERROR[16379][C-0000068e]: func_odbc.c:835 acf_odbc_read: Unable to execute query [SELECT TOP 1 '1C' as 'datasource', f.[FirmKod] as firmkod, cast(f.[FirmName]as varchar(200)) as ContactInfo, f.[Manager] as managername, cast(f.[Text] as varchar(100)) as ContactInfo2 FROM [OdinC_Connection_test].[dbo].[Mirror_1C_Firm] f inner join [OdinC_Connection_test].[dbo].[Mirror_1C_Tel] t on t.[FirmKod] = f.FirmKod and t.[Tel]='xxxxxx']
[2018-08-08 14:53:37] ERROR[16379][C-0000068e]: func_odbc.c:835 acf_odbc_read: Unable to execute query [SELECT TOP 1 '1C' as 'datasource', f.[FirmKod] as firmkod, cast(f.[FirmName]as varchar(200)) as ContactInfo, f.[Manager] as managername, cast(f.[Text] as varchar(100)) as ContactInfo2 FROM [OdinC_Connection_test].[dbo].[Mirror_1C_Firm] f inner join [OdinC_Connection_test].[dbo].[Mirror_1C_Tel] t on t.[FirmKod] = f.FirmKod and t.[Tel]='xxxxxx']
    -- Executing [xxxxxx@from-pstn:6] Set("PJSIP/VEGA-00001ec1", "HASH(GETMANAGER_1C)=") in new stack
    -- Executing [h@from-pstn:1] NoOp("PJSIP/VEGA-00001ec1", "------------------> ERROR!!! <------------------") in new stack


Я хочу обойти проблемный участок при возникновении ошибки. Моя проблема в том, что при ошибке обработка переходит в екстеншен 'h', а я надеялся на то, что перейдет в 'e'.
Что я делаю не так?

Re: AEL. При ошибке не переходит в 'e' экстеншен.

СообщениеДобавлено: 08 авг 2018, 20:11
virus_net
Подобные вещи надо выполнять через AGI, где можно и нужно сделать человеческий обработчик ошибок.

Re: AEL. При ошибке не переходит в 'e' экстеншен.

СообщениеДобавлено: 09 авг 2018, 16:42
GoG
virus_net писал(а):Подобные вещи надо выполнять через AGI, где можно и нужно сделать человеческий обработчик ошибок.


Спасибо за внимание к теме, но это не ответ на мой вопрос.
Еще раз вопрос: - почему при возникновении ошибки обработка передается экстеншену 'h' а не 'e'?

Re: AEL. При ошибке не переходит в 'e' экстеншен.

СообщениеДобавлено: 09 авг 2018, 17:31
Repz
потому что ловите hangup, вот и попадаете в h
вангую что hangap прилетает из &locatemanager();

Re: AEL. При ошибке не переходит в 'e' экстеншен.

СообщениеДобавлено: 10 авг 2018, 17:50
GoG
Ванговать нет необходимости - есть логи в которых видно что до макроса дело не дошло. В том макросе hangap нет, он тут вообще не при чем.