Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: F: Billing STN отдает не верные данные
АРТКОМ Форум > Форумы для специалистов > Техническая поддержка iPECS-LIK & iPECS-UCP
Lex
Добрый день, форумчане. Имею ipecs-lik600 (MFIM/GS97M-5.6Bm JUL/16, Kernel Version-6.0Al, SLT32 - v.4.0Ne). Не могу найти место откуда по директиве F в LCR берутся не верные данные о внутреннем пользователе. F я использую для голосового "аон-а" на аналоговых аппаратах. Работает так- пользователь набирает код XXX, в lcr, используя F, к этому коду добавляется в начало трехзначный внутренний номер и эти 6 цифр отправляются на астериск, который отрезает последние 3 цифры и проговаривает голосом оставшиеся 3 первых цифры, которые и добавлялись при помощи F. Большинство номеров обрабатывается правильно, но с некоторых в астер улетают совсем не те внутренние номера ( точнее код+внутренний номер) с которых звоню. С астером проблем нет - он просто принимает, то что ему отправили и проговаривает, вижу в консоле астериска, что к нему с этих проблемных номеров прилетают не правильные цифры с атс. При звонке, например на системник, все номера определяются правильно. Подскажите, кто-то сталкивался с таким, как решали? Проблема наблюдается, как на аналоговых портах, так и на цифровых аппаратах (LIP-8002Е), например внутренний номер 102 улетает на астер как XXX302 и проговаривается 302, номер 799(цифровик) улетает как ХХХ327, номер 790(цифровой) улетает как ХХХ324, проговаривает 324, думаю, что с физическими номерами портов не связано, т.к. портов 324 и 327 не атс не существует. Может глаз замылился и не могу понять откуда берутся данные по F, кто в курсе подскажите пжлст.
Dron
Цитата(Lex @ 27.11.2013, 12:26) *
Добрый день, форумчане. Имею ipecs-lik600 (MFIM/GS97M-5.6Bm JUL/16, Kernel Version-6.0Al, SLT32 - v.4.0Ne). Не могу найти место откуда по директиве F в LCR берутся не верные данные о внутреннем пользователе. F я использую для голосового "аон-а" на аналоговых аппаратах. Работает так- пользователь набирает код XXX, в lcr, используя F, к этому коду добавляется в начало трехзначный внутренний номер и эти 6 цифр отправляются на астериск, который отрезает последние 3 цифры и проговаривает голосом оставшиеся 3 первых цифры, которые и добавлялись при помощи F. Большинство номеров обрабатывается правильно, но с некоторых в астер улетают совсем не те внутренние номера ( точнее код+внутренний номер) с которых звоню. С астером проблем нет - он просто принимает, то что ему отправили и проговаривает, вижу в консоле астериска, что к нему с этих проблемных номеров прилетают не правильные цифры с атс. При звонке, например на системник, все номера определяются правильно. Подскажите, кто-то сталкивался с таким, как решали? Проблема наблюдается, как на аналоговых портах, так и на цифровых аппаратах (LIP-8002Е), например внутренний номер 102 улетает на астер как XXX302 и проговаривается 302, номер 799(цифровик) улетает как ХХХ327, номер 790(цифровой) улетает как ХХХ324, проговаривает 324, думаю, что с физическими номерами портов не связано, т.к. портов 324 и 327 не атс не существует. Может глаз замылился и не могу понять откуда берутся данные по F, кто в курсе подскажите пжлст.

А не связано ли со Station CLI в 114 программе?
Lex
Цитата(Dron @ 27.11.2013, 13:42) *
А не связано ли со Station CLI в 114 программе?

В 114 Пгм, поле Station CLI стоит "честный" номер, например для номера 790 в пгм 114 стоит 790, на астер отправляется ХХХ324.
vitalii
Цитата(Lex @ 27.11.2013, 13:10) *
В 114 Пгм, поле Station CLI стоит "честный" номер, например для номера 790 в пгм 114 стоит 790, на астер отправляется ХХХ324.

абонент 790 на каком порту(случайно 324?)
Lex
Цитата(vitalii @ 27.11.2013, 16:41) *
абонент 790 на каком порту(случайно 324?)

Номер 799 находится на порту 322, определилось с использованием F, как номер 325. На порту с номером 325 никто не зарегистрирован - на этом порту железа нет и не было. Удивительно, но до перезагрузки видел номер 799 на порту отличном от 324, сейчас действительно он на 324 порту. Номер 102 с самого начала был на 302 порту. НО 799 тем не менее находится на порту 322, а F отдает 325. Если бы даже с номера 799 я услышал 322, не понял бы почему отдается номер порта, а не номер абонента на порту.
В пгм 114 Station CLI 1 прописаны правильные номера. Откуда в действительности F берет данные???
Завтра протестирую "F" еще с нескольких внутренних номеров.
Lex
Цитата(Lex @ 27.11.2013, 21:56) *
Номер 799 находится на порту 322, определилось с использованием F, как номер 325. На порту с номером 325 никто не зарегистрирован - на этом порту железа нет и не было. Удивительно, но до перезагрузки видел номер 799 на порту отличном от 324, сейчас действительно он на 324 порту. Номер 102 с самого начала был на 302 порту. НО 799 тем не менее находится на порту 322, а F отдает 325. Если бы даже с номера 799 я услышал 322, не понял бы почему отдается номер порта, а не номер абонента на порту.
В пгм 114 Station CLI 1 прописаны правильные номера. Откуда в действительности F берет данные???
Завтра протестирую "F" еще с нескольких внутренних номеров.

Проверил, еще несколько номеров - на 2-х sltm32 из 10. На остальных sltm32 не наблюдается такого. Прошивки на всех sltm32 одинаковые, но я не склонен грешить на железо, похоже либо на софт, либо кривые руки))). "F" выдает не правильные данные (номера), номер порта также не совпадает с тем, что выдает "F". При звонке на внутренний номер - все определяется правильно.
Уважаемые форумчане может кто-то знает откуда конкретно "F" берет данные о номере. Может это как-то связано с групповой "перепиской" номеров которую я делал через ПГМ105 поля Enter Station Range(диапазон) + Start Station Number? К сожалению сейчас этого проверить не могу.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2025 IPS, Inc.