Вопросы жизни - помогите ПОЖАЛУЙСТА:

Какой софт лучше использовать для биллинга Option11?
Поддерживает ли SMDR Tariff эту станцию?
или Существует ли другой freeware софт для биллинга?

yunkers пишет
Вопросы жизни - помогите ПОЖАЛУЙСТА:

Какой софт лучше использовать для биллинга Option11?
Поддерживает ли SMDR Tariff эту станцию?
или Существует ли другой freeware софт для биллинга?
Тут (http://www.turasw.com/forum/viewtopic.php?t=10) есть список ссылок на сайты писателей тарификаторов для М1.

Когда-то Urri по поводу freeware выдал гениальную мысль:
Urri пишет
Бесплатная прога учитывает только бесплатные вызовы

:D

Freeware = отсутствие сертификатов, а это означает что такой тарификатор нельзя использовать как АСР.
Обычно лицензии на бесплатный софт предполагают его некоммерческое использование, поэтому "Бесплатная прога учитывает только бесплатные вызовы".

Тут (http://www.cnews.ru/reviews/index.shtml?2007/10/17/270829) статья про "бесплатный" Линух.

Насчет отсутствия сертификатов - согласен. Но наличие у тарификатора сертификата еще не позволяет утверждать, что эту прогу можно использовать для тарификации любых АТС. В сертификате должен быть указан именно этот тип АТС (более того - для какого релиза математики АТС разрешено использование тарификатора). И наличие сертификата отнюдь не является свидетельством качества.

Что касается якобы обязательного наличия сертификата. В принципе, сертификат нужен только на ту часть комплекса, которая отвечает за добросовестное считывание информации (CDR) с порта АТС и записи ее на диск. И все! Если у абонента возникнут разногласия с оператором по поводу выставленных ему счетов, в суде будут рассматриваться, прежде всего, данные, непосредственно считанные с порта АТС. А всякого рода выходные данные с тарификатора являются всего лишь вспомогательными, поскольку им доверять далеко не всегда можно.

Поскольку любой, самый "отсертифицированный" тарификатор может выдавать чушь. Ведь он - всего лишь инструмент. А настраивают и используют результаты его работы люди.

vsorokin пишет
Насчет отсутствия сертификатов - согласен. Но наличие у тарификатора сертификата еще не позволяет утверждать, что эту прогу можно использовать для тарификации любых АТС. В сертификате должен быть указан именно этот тип АТС (более того - для какого релиза математики АТС разрешено использование тарификатора). И наличие сертификата отнюдь не является свидетельством качества.


Приведите, пожалуйста, конкретные примеры некорректной работы с меридианом текущих версий сертифицированных биллинговых программ.

Да практически все, которые работают только с одной CDR.
У Меридиана (и не только у него, при сложных вызовах и у других АТС - тоже) информация об одном вызове может быть разбросана по нескольким CDR (даже - десяткам CDR)! Да еще разного типа. Их нужно уметь правильно "склеить".
В подавляющем большинстве т.н. "универсальные" тарификаторы этого момента в принципе учесть не могут.

В то же время, одна CDR может содержать инфу о нескольких вызовах. В простейшем случае (обычный внутренний вызов) - о двух. Для абонента А - внутреннем исходящем. Для абонента Б - внутреннем входящем. Если вызов - внешний входящий транзитный или с использованием функции DISA - о четырех (см. пояснение на сайте TarifSV (http://7548.ru/tarifsv.htm) ).

Мне повторить вопрос ? Хорошо, я повторю. Приведите, пожалуйста, конкретные примеры некорректной работы с меридианом сертифицированных биллинговых программ последнийхверсий.

О чем вы спорите?
Кто-то рекламирует свою программу.
Кто-то изобретает велосипед.
А кто-то покупает готовый.
И каждый по-своему прав.

:)
мы (присоединюсь к jetc) не спорим
не рекламируем свою программу
не изобретаем велосипед
не покупаем готовый
про правых пропустим...
мы ждем ответа на конкретный вопрос (он на самом деле актуален для многих)

И исходя из своей практики утверждаю: для большинства случаев не надо заморачиваться с покупкой т.н. универсального (т.е. якобы подходящего для многих типов АТС) тарификатора для М1. Используйте любой халявный, если вы предполагаете применять его только от случая к случаю. Но будьте готовы, что он просто-напросто не обработает и пропустит много вызовов!

Для постоянного использования среди бесплатных и не очень дорогих лучше TarifSV (http://7548.ru/tarifsv.htm) не найдете! Эта прога специально "заточена" под Meridian 1 / Succession CSE 1000.
При правильной настройке она обрабатывает практически все вызовы. В том числе - самые сложные. По самым изощренным тарифным планам и с учетом постоянных абонентских и прочих платежей.

P.S. Спасибо Gluker-у за размещение информации о тарификационных прогаммах для М1 на своем сайте!

Вы практически вынуждаете меня повторить вопрос в третий раз. Может быть, он вам непонятен ? Почему в качестве ответа вы все время пытаетесь привести общие рассуждения про платность ,бесплатность, сертифицированность и несертифицированность ?
О них в вопросе не было ни слова.

Приведите, пожалуйста, конкретные примеры неправильной работы с меридианом последнихверсий сертифицированных программ. Т.е. примеры тестовых вызовов, строки CDR, результат их обработки корректно настроенными сертифицированными программами текущих версий, результаты обработки вашим изделием.

jetc пишет
Вы практически вынуждаете меня повторить вопрос в третий раз. Может быть, он вам непонятен ? Почему в качестве ответа вы все время пытаетесь привести общие рассуждения про платность ,бесплатность, сертифицированность и несертифицированность ?
О них в вопросе не было ни слова.

Приведите, пожалуйста, конкретные примеры неправильной работы с меридианом последнихверсий сертифицированных программ. Т.е. примеры тестовых вызовов, строки CDR, результат их обработки корректно настроенными сертифицированными программами текущих версий, результаты обработки вашим изделием.

Отвечаю в третий раз:

- практически все, которые работают только с одной CDR.

Прошу ответить и на мой вопрос:
"Какую Вы знаете сертифицированную биллинговую программу, которая правильно и полно производит тарификацию ВСЕХ вызовов, прошедших через М1/CS1000?"

Кстати, примеры тестовых вызовов, обработанных TarifSV, Вы можете найти в документации на этот продукт. Я просмотрел документацию на множество платных и бесплатных программ тарификации, но нигде не нашел описания того, как они обрабатывают вызовы с АТС типа Meridian 1. В том числе - сложных вызовов. Если Вы знаете - подскажите, мне любопытно.

Вижу, вы хотите отвечать на те вопросы, которые сами себе задаете.

Я попросил вас привести список
конкретных неточностей, даже привел немудреные требования к списку.

Раз вы утверждаете, что они неправильно считат, а вы - правильно, значит - у вас должны быть конкретные демонстрационные примеры неправильных расчетов.

Вы же хотите ответить на вопрос "какие неточности" словами "практически все программы, которые работают с одной строкой".

Читая ваши спаслания не могу отделаться от ассоциации с коммивояжером. Столько слов - и ни одного в прямой ответ на вопрос. Можете и в третий раз сообщить мне список названий тарификационных программ, только он не является ответом на заданный вопрос.
Документацию по CDR я и сам могу вам процитировать.

Я правильно понял, что у вас отсутствуют конкретные примеры ошибок в работе современных версий тех же барсума и фонекс про ?

Значит, я вас правильно понял, ничего в подтверждение своих слов относительно некорректной работы сертифицированных программ у вас нет.
Очень, очень жаль.
Раз уж вы так просите, приведу пример программы, которая тарифицирует ВСЕ вызовы: Барсум.
Интересно будет посмотреть, как вы это будете опровергать.
Кстати, с психологией у вас в данном случае так же, как и с конкретными примерами - т.е. никак.

Ребята, ну что вы тут сцепились. Все программы хороши - выбирай на вкус. А для vsorokin маленький советик: Не стоит такими фразами
vsorokin пишет
...Кстати, внедрение TarifSV позволило существенно сократить время на проведение расчетов и выставление счетов...
разбрасываться на публичных форумах. Даже если ваша программа самая правильная (я вполне это допускаю), у предприятия, использующего софт, не имеющий сертификата соответствия, для выставления счетов, могут быть большие проблемы. Или вы думаете, что связьнадзорские ребята не почитывают специализированные форумы? Им тока дай повод... А Вы этот повод своими высказываниями им даёте... Не поддавайтесь на провокации и не кипятитесь. Лучше тратьте время и силы на развитие программы. :)

Ну и для уважаемого jetc пожелание. Если уж вы защищаете какую - то точку зрения, то не скрывайте от народа, что у Барсума сертификат соответствия есть только на Bill Works, у которого порог вхождения в тему от 35 000 у.е. по 32 рубля за каждую у.е. Это же несопоставимые вещи. А на Барсум Про действующего сертификата нет.

P.S. Кстати, для справки, вот тут vsorokin пишет В принципе, сертификат нужен только на ту часть комплекса, которая отвечает за добросовестное считывание информации (CDR) с порта АТС и записи ее на диск. И все! Вы ошибаетесь. Это разные сертификаты. То, о чем Вы говорите называется АПУС и на неё идет отдельная сертификация. Вся дальнейшая обработка ведется с помощью софта, который законодатель называет АСР и это другой сертификат. Но в деятельности оператора он тоже нужен. Как один из примеров посмотрите хоть и старый, но актуальный топик тут тынц (http://electrosvyaz.com/forum/viewtopic.php?t=2184&highlight=%C0%CF%D3%D1)

традиционно для таких тем - каждый поговорил о своем :rolleyes:

Ну и для уважаемого jetc пожелание. Если уж вы защищаете какую - то точку зрения, то не скрывайте от народа, что у Барсума сертификат соответствия есть только на Bill Works, у которого порог вхождения в тему от 35 000 у.е. по 32 рубля за каждую у.е. Это же несопоставимые вещи. А на Барсум Про действующего сертификата нет.



На всякий случай: я не "барсум защищал". Я интересовался ровно тем, о чем спрашивал.

Спасибо, pvalera .

"АПУС - аппаратура повременного учета соединений, предназначенная для определения длительности телефонных соединений местных телефонных связей при взаимных расчетах между операторами связи и пользователями" см . "ПРОГРАММА И МЕТОДИКА ИСПЫТАНИЙ..." (http://www.aboutphone.info/lib/gost/45-008-97.html) ).
К считыванию с порта АТС информации о CDR и записи ее на диск это, похоже, прямого отношения не имеет?

Мне интересно, Meridian 1 имеет сертификат на АПУС?
Ведь он сам измеряет длительность соединения.


Кстати, еще и тут (http://www.electrosvyaz.com/forum/viewtopic.php?t=5229&postdays=0&postorder=asc&start=0) продолжилась дискуссия о том, какие такие сертификаты требует РСН (Россвязьнадзор).

Раз уж всё равно зафлеймили тему, отвечу тут же. Подчеркну особо, что всё, что я скажу - IMHO. Сослаться на документы я не смогу, ибо лень искать. :)

------------- IMHO On -------------------------
Если подходить с логической точки зрения, то АПУС должен заканчиваться не RS-232C или TCP/IP а каким - либо файлом, находящимся вовне АТС. По логике вещей работа АПУС должна состоять из двух составляющих. Одна часть АПУС (например АТС) выполняет измерение длительности соединения (вероятно, именно она называется СИДС), другая (например софтинка по RS-232C или посредством другого линка) эту инфу _корректно_ забирает и складывает во вне АТС.
На каждом из этих этапов есть потенциальная возможность ошибки, поэтому я считаю, что результатом работы АПУС должен является файл, который и подлежит проверке на правильность. Любая АПУС может пытаться гарантировать точность измерений _исключительно_ по каналам связи с соответствующей сигнализацией. Поставьте самую супер - пупер АПУС на аналоговые транки без переполюсовки и что? Правильно, а ничего. Ни о каких расчетах или _правильности_ можно даже не заикаться.

Я за свою долгую жизнь повидал достаточно логгеров, которые не совсем корректно работают с RS-232C. Ну и представьте себе, что например, АТС (то есть СИДС) отработала отлично, всё померила, но логгер облажался и байтик пропустил. Обычно этот процесс необратим. А что мы получим? Правильно, недостоверную информацию на выходе АПУС.

Поэтому, по логике вещей, утверждать о том, что АПУС ...К считыванию с порта АТС информации о CDR и записи ее на диск это, похоже, прямого отношения не имеет?... лично я бы не стал.

------------------ IMHO Off ---------------

Насчет сертификата на Меридиан, я где - то на форумах с этим сталкивался, да в принципе и в инете можно порыться например тут тынц (http://www.metrarus.ru/kip/element.php-ID=20137.htm) Это конечно не сертификат, но всё - же...
Хотя вот и действующий сертификат тынц (http://www.soft-tronik.ru/docs/bpwebsite3.asp?Url=/docs/Project2.dll/8771.htm) . Так что при должном усердии в Google найдется всё :p

Удачи вам, коллеги, в вашем нелегком труде. ;)

Большое спасибо, Валерий!

Вы подтвердили мое утверждение : "Что касается якобы обязательного наличия сертификата. В принципе, сертификат нужен только на ту часть комплекса, которая отвечает за добросовестное считывание информации (CDR) с порта АТС и записи ее на диск. И все!"

Далее все расчеты можно выполнять хоть на калькуляторе.
Главное - чтобы он правильно считал.

TarifSV не претендует на звание АСР. Но в качестве калькулятора, пожалуй, сойдет. Не знаю, подлежат ли поверке калькуляторы? Ведь это - не средство измерения, как АПУС.

Другое дело, что в состав комплекса входит TSVlite - та самая вторая часть СИДС, отвечающая за считывание и запись CDR на диск. Строго говоря, на нее нужен сертификат. Его нет. Поэтому мы держали на втором компе параллельно Phonexlite - аналогичную прогу от сертифицированного PhonexPro.

Еще раз спасибо Валерию за аргументированное и квалифицированное участие в дискуссии.

vsorokin, так, может быть,в ы все же прервете восхваление TarifSV и приведете конкретные примеры логов и неправильно их обработки текущими версиями, хотя бы, барсум и фонекс про ?

Уважаемый vsorokin Вы как то странно истолковали мои слова. Я нигде и никогда не говоил, что vsorokin пишет
Вы подтвердили мое утверждение : "Что касается якобы обязательного наличия сертификата. В принципе, сертификат нужен только на ту часть комплекса, которая отвечает за добросовестное считывание информации (CDR) с порта АТС и записи ее на диск. И все!"

Далее все расчеты можно выполнять хоть на калькуляторе.
Главное - чтобы он правильно считал.
Более того, я категорически его опровергаю. Не сравнивайте, пожалуйста теплое с мягким. Для того, чтобы оператор связи имел возможность выставлять счета своим абонентам на законном основании, он _обязан_ иметь еще и _сертифицированную_ АСР. Это тот самый _калькулятор_, как вы его называете. Так что на АПУС - один сертификат, на АСР другой, но это не взаимоисключающие, а взаимодополняющие системы. Это как весы и кассовый аппарат в магазине. Извините, если я не так очевидно изложил это в предыдущих постах.

jetc пишет
vsorokin, так, может быть,в ы все же прервете восхваление TarifSV и приведете конкретные примеры логов и неправильно их обработки текущими версиями, хотя бы, барсум и фонекс про ?

Попробую я еще спросить. В аллегорической форме.
Смотрите, некто приходит и говорит, что его чудодейственные пилюли очень хорошие и полезные, а все другие - вредные. Вот в этом и вопрос, действительно так? Можете подтвердить? Подтвердить, а не просто "уверуйте, чада, ибо истину глаголю". Потому как за другие пилюли уплочено и выкидывать их жалко.

Приношу всем свои извинения, что зафлудил тему.
Свой флуд убрал.

Всем спасибо.

vsorokin пишет
Свой флуд убрал.
хм... оригинально

Вопрос по существу звучал так: "Существует ли freeware софт для биллинга Option11?"
vsorokin дал исчерпывающий ответ.

Хотя теперь всплыл другой вопрос (присоединяюсь к jetc): в каких именно ситуациях Барсум лажает и неправильно тарифицирует вызовы? Или не достаточно полно отображает всю информацию о звонке.

Используем Barsum Pro ver 5.002.004 c 2 мя сборщиками на узловых станциях M61С + 10 М11С идут транзитом через М61-е на оператора Северо_Западный Телеком.Не корректно обрабатываются или вообще не попадают переведенные звонки и конференцсвязь при использовании транзита.Заявки по доработке протокола сделана в июле этого года -обещали к 31 августа выполнить.Прислали только вчера доработанный протокол.Но в итоге посмотрев обнаружил ,что остались нерешенными проблемы на которые я указывал.Только еще добавились ошибки с обработкой внутренних звонков.И вообще канитель с доработками протоколов(4 доработка) уже длится с начала установки тарификатора т.е. с января 2006 года.
Конкретно ошибки обработки можно увидеть в файлах.
Т.е. у нас сейчас некорректно обрабатываются E и L-записи.

svgus -у :

Я "навскидку" обработал Ваш "е"-файл (с которым не справился БАРСУМ) с помощью TarifSV (http://7548.ru/tarifsv.htm) .

Пож., посмотрите, правильно ли он был обработан?

Здесь:
- "Город" - условное обозначение городского номера, по которому звонили на АТС;
- 002 - маршрут внешний
- 35520 - внутренний номер
- № записи - порядковый номер первой CDR в Вашем файле, относящейся к данному вызову.

В файле "е" было обнаружено в 32-х CDR 13 вызовов :
7 - "простых" (одиночных) и 6 "сложных" (в ходе вызова была сделана переадресация на внешнего оператора связи).

Таким образом, протарифицировано 19 вызовов, из них:
- городских (внешних) входящих - 7;
- междугородних - 11 (1 из них - с непонятным кодом 817);
- международных - 1;

Сейчас посмотрел сколько за 1 один день разговоров E обработал Barsum. Вывод.Было 20 таких звонков :3 разговора обработано правильно( это те разговоры которые относятся к одной узловой станции и переводятся на внешние направления), 7 разговоров определился телефон как неизвестный -т.е некорректно обработан,а 10 вобще пропало-нет ни в тарифицированных ни в нетарифицированных.
Эти звонки связаны либо с транзитными звонками с M11-х,либо когда перевод звонка идет на(с) обоих внешних(городских или МГ) абонентов.

svgus пишет
... Используем Barsum Pro ver 5.002.004 ... ... Вложение: err_cdr.zip... Очень понравилось на скриншотах в файле e.jpg поле "Направление" значение "Выходной". :D
А вы говорите... :p

По приведенным данным - в первоисточнике e.txt
лично мне не совсем понятны первые две записи 024 и 057.

S 024 00 A002032 35520 10/01 11:31:30 00:00:24.0
& 000 000
&00:02 000 00 0 02

E 057 00 A002032 A002041 10/01 11:33:36 00:01:36.0
& 000 000
& 000 00 0 02

Скорее всего, там была еще одна существенная строчка, которая, вероятно, погибла при редактировании этого фрагмента лога. По эти двум строкам однозначно определить что же произошло, как мне кажется, невозможно. Входящий вызов с транка 002032 упал на 35520, далее он его оттрансферил наружу по транку 002041, но что при этом набрал - неизвестно. Или я не прав?

А еще мне почему - то показалось, что у svgus на маршруте 006 не включена регистрация входящих вызовов. Вероятно это рут, который на M61C смотрит в сторону M11C. Соответственно решили, а нафига нужно по нему CDR регистрить. Так? При этом первая строчка (входящий вызов от транзита) типа S не генерится, а есть только запись типа Е. Может из-за этого у барсумчега крыша едет? :p

Практика показывает, что лучше сделать всё единообразно, а то на руте 002 регистрация входящих есть, и тут транзит состоит из 3 записей, а на 006 регистрации нету и транзит состоит из двух записей. Тут у кого хочешь, крыша поедет :D

Хотя может просто эти записи погибли при подготовке фрагмента лога и я просто зря отвлек ваше внимание...
:rolleyes:

pvalera пишет
Очень понравилось на скриншотах в файле e.jpg поле "Направление" значение "Выходной". :D
А вы говорите... :p

...
Скорее всего, там была еще одна существенная строчка, которая, вероятно, погибла при редактировании этого фрагмента лога. По эти двум строкам однозначно определить что же произошло, как мне кажется, невозможно. Входящий вызов с транка 002032 упал на 35520, далее он его оттрансферил наружу по транку 002041, но что при этом набрал - неизвестно. Или я не прав?

А еще мне почему - то показалось, что у svgus на маршруте 006 не включена регистрация входящих вызовов. Вероятно это рут, который на M61C смотрит в сторону M11C. Соответственно решили, а нафига нужно по нему CDR регистрить. Так? При этом первая строчка (входящий вызов от транзита) типа S не генерится, а есть только запись типа Е. ...

...
:rolleyes:

Прекрасно, Валерий! Скорее всего, так оно и есть.
Кстати, у TarifSV "крыша" не поехала, и он спокойненько обсчитал оставшиеся записи! (опять Остапа понесло!):confused:

pvalera пишет
Скорее всего, там была еще одна существенная строчка, которая, вероятно, погибла при редактировании этого фрагмента лога. По эти двум строкам однозначно определить что же произошло, как мне кажется, невозможно. Входящий вызов с транка 002032 упал на 35520, далее он его оттрансферил наружу по транку 002041, но что при этом набрал - неизвестно. Или я не прав?


Да,действительно недоглядел.Вот она недостающая строка:
S 023 00 35520 T002041 10/01 11:31:50 00:00:04.5 A988143153719
& 000 000
& 000 01

А еще мне почему - то показалось, что у svgus на маршруте 006 не включена регистрация входящих вызовов. Вероятно это рут, который на M61C смотрит в сторону M11C. Соответственно решили, а нафига нужно по нему CDR регистрить.

И это так.С М11 снимаем исходящие. С входящими со всех маршрутов с М61 -х год бился. В этом случае тоже есть свои заморочки у Барсума.

При этом первая строчка (входящий вызов от транзита) типа S не генерится, а есть только запись типа Е.

Да только 2 записи в этом случае.3- я запись N (М11) или L(М61) существует, но выборки этих разговоров я не стал делать.
S 036 00 35520 T002052 10/01 11:54:33 00:00:03.5 A988142769042
& 000 000
& 000 01

E 077 00 A006053 A002052 10/01 11:57:35 00:02:54.5
&33538XXXXXXXXXXX 000 000
& 000 09 6 01



Может из-за этого у барсумчега крыша едет?
Согласен.
:p

vsorokin пишет
Пож., посмотрите, правильно ли он был обработан? Я хоть и не svgus но всё - же, раз уж вы говорите о своём софте, как о единственно правильном, рискну задать Вам вопросы.

1. У Вас всегда расчет длительности соединения выполняется верно?

В исходных данных, например по тем записям, которые я привел чуть выше, можно сказать, что длительность соединения составляла 1:36.0 или 96 сек. Даже если добавить сюда первую длительность 24 сек, получится 120 сек. Даже добавив 2 сек. ожидания получим 122 сек. в Вашем отчете 126 сек.

Я конечно понимаю, откуда они взялись. Время начала первого вызова - 11:31:30 время окончания второго - 11:33:36 вот вам и 126 сек. Но неужели Вы считаете, что это правильно? Реальное соединение, за которое присоединяющий оператор начислит деньги клиенту будет иметь длительность не 126 сек., а меньше. Сколько именно неизвестно, так как не хватает еще одной записи S типа.

Да, она будет находиться в диапазоне 96 - 126 сек. но с уверенностью точное значение указать нельзя.

Так что, если притягивать этот пример "за уши" можно начать громко кричать о том, что на "контрольном примере" погрешность Вашего варианта АПУС составила 126сек./96сек. = 31,25% :p И что "все бесплатные тарификаторы неправильно считают трафик", но это не наш путь. ;)

Я понимаю, что этот пример не очень характерен для CDR записей Меридиана, но всё - же, мне кажется, что такие записи лучше отправлять в отсев, для того, чтобы потом вручную привести их к общему знаменателю если будет такая возможность.

2. Да, и вот еще. В транзитах с рута 006, с отсутствующей S записью о входящем соединении, если уж в записи поле IANI имеет осмысленное значение, имеет смысл, вероятно, его использовать. Судя по всему, это номер абонента с M11C, так как пришёл он с 006 рута. По хорошему счету, его нужно показывать как оригинатора соединения и тарифицировать соединение по тому тарифному плану, который закреплен не за рутом, а за этим абонентом. Я же правильно понимаю, что Ваша система позволяет это сделать?

3. Кстати, как вы обрабатываете ситуации с Hot Choice выбором оператора МгМн связи? в этих примерах я таких вызовов не увидел, но всё - же. Просто чисто человеческое любопытство.

Буду очень рад, если Вы меня опровергнете. ;)

Так как наш диалог вышел уж очень далеко за пределы вопроса, заданного топикстартером, предлагаю дальнейшее обсуждение , если оно состоится, перенести в приват или другую ветку.

В заключение хочу сказать, что для _бесплатного_ тарификатора результат весьма достойный.

P.S. Хотя даже это не дает права использовать его у оператора связи для расчетов с абонентами. :p

Кстати, совсем забыл, в процессе дискуссии для топикстартера yunkers (да и для jetc на заметку) появилась единственно полезная информация - для Меридиана Барсум покупать не стоит, тем более, что на Барсум Про нет действующего сертификата. :D

pvalera пишет
Кстати, совсем забыл, в процессе дискуссии для топикстартера yunkers (да и для jetc на заметку) появилась единственно полезная информация - для Меридиана Барсум покупать не стоит, тем более, что на Барсум Про нет действующего сертификата. :D
Имхо это преждевременный вывод и к нему не хватает рекламы Коммуникационного Аудитора ;)
Не стоит топить продукт, если у него появились проблемы на одном объекте. Подозреваю, что эти глюки связаны с либо с неправильной настройкой станции либо с уже сделанными "доработками".

Честно говоря я в последние 5 лет чужие софтины не тестировал (т.к. появился Колокол), но перед этим не мало потратил времени на доведение до ума Фонекса и Барсума. На 2002 год обе софтины сносно обрабатывали меридианские трансферы, конференции и коды авторизации.

Для меня остается странным, почему за это время Рексофт не сделал (если не сделал) универсальный обработчик для меридианского лога.

Тема в очередной раз навеяла мысль о том, что надо писать свой тарификатор...

Вот этого не надо. Места на рынке и так уже мало...
:D

pvalera пишет
Я хоть и не svgus но всё - же, раз уж вы говорите о своём софте, как о единственно правильном, рискну задать Вам вопросы.

1. У Вас всегда расчет длительности соединения выполняется верно?

В исходных данных, например по тем записям, которые я привел чуть выше, можно сказать, что длительность соединения составляла 1:36.0 или 96 сек. Даже если добавить сюда первую длительность 24 сек, получится 120 сек. Даже добавив 2 сек. ожидания получим 122 сек. в Вашем отчете 126 сек.

Я конечно понимаю, откуда они взялись. Время начала первого вызова - 11:31:30 время окончания второго - 11:33:36 вот вам и 126 сек. Но неужели Вы считаете, что это правильно?
.....
2. Да, и вот еще. В транзитах с рута 006, с отсутствующей S записью о входящем соединении, если уж в записи поле IANI имеет осмысленное значение, имеет смысл, вероятно, его использовать. Судя по всему, это номер абонента с M11C, так как пришёл он с 006 рута. По хорошему счету, его нужно показывать как оригинатора соединения и тарифицировать соединение по тому тарифному плану, который закреплен не за рутом, а за этим абонентом. Я же правильно понимаю, что Ваша система позволяет это сделать?

3. Кстати, как вы обрабатываете ситуации с Hot Choice выбором оператора МгМн связи? в этих примерах я таких вызовов не увидел, но всё - же. Просто чисто человеческое любопытство.

Буду очень рад, если Вы меня опровергнете. ;)

Так как наш диалог вышел уж очень далеко за пределы вопроса, заданного топикстартером, предлагаю дальнейшее обсуждение , если оно состоится, перенести в приват или другую ветку.

В заключение хочу сказать, что для _бесплатного_ тарификатора результат весьма достойный.

P.S. Хотя даже это не дает права использовать его у оператора связи для расчетов с абонентами. :p

Спасибо, Валерий, за конструктивный диалог.

Отвечаю по пунктам.
1. Детальное изучение документации по CDR на Meridian 1/ CS1000 + огромный опыт тестирования (у нас CallCenter) позволяет сделать однозначный вывод: общая длительность вызова определяется разностью времен в Е и S - записях (без учета времени ожидания в очередях: Q - записей). TarifSV позволяет также учитывать и Q-записи.
Хотя, возможно, с необходимостью учета времени ожидания (в N и Е-записях) следует разобраться.

По первому из вызовов (не хватает еще одной S-записи) трудно сделать однозначный вывод, к чему относятся 96 сек.

2. Вы, очевидно, имели ввиду поле CLID в Е-записи? Его я не использую. Е-запись может закрывать множество S-записей и ее применяю только для идентификации окончания всей последовательности. CLID, естественно, я использую. Но беру его из S - записей. Вообще-то TarifSV позволяет осуществлять достаточно тонкую настройку на параметы записи и их модифицировать для однозначной идентификации ресурса.

3.Не вполне понял содержание вопроса. Если имеется ввиду идентификация оператора связи, через которого осуществлен вызов, то такая идентификация в TarifSV может быть осуществлена разными способами. Чаще всего я использую значение т.н. "префикса В" - анализируются первые несколько цифр набранного номера.
В качестве примера прикрепляю тот же файл, но с использованием этого приема. (Принял: если первая цифра набранного номера "8" - то выход осуществлен через "Ростелеком"). Там же по расценкам Ростелекома рассчитана стоимость каждого вызова (то, что выставит оператор связи за вызов).

Подробности - в документации на TarifSV.

P.S. А мы его и не используем для этих целей;)

И ещё: я нигде не утверждал, что мой софт "единственно правильный". Отнюдь. Но из бесплатного и относительно недорогого - из лучших.

У меня недостаточно большой опыт общения на форумах.
Может, действительно открыть спец. ветку?

pvalera пишет
Кстати, совсем забыл, в процессе дискуссии для топикстартера yunkers (да и для jetc на заметку) появилась единственно полезная информация - для Меридиана Барсум покупать не стоит, тем более, что на Барсум Про нет действующего сертификата. :D

Да, не стоит покупать барсум версии от 2006 года и просить его настраивать тех, кто это делал вышежаловавшемуся товарищу.
Серификат на Барсум истек в июне этого года, так еще не вечер.

pvalera пишет
Кстати, совсем забыл, в процессе дискуссии для топикстартера yunkers (да и для jetc на заметку) появилась единственно полезная информация - для Меридиана Барсум покупать не стоит, тем более, что на Барсум Про нет действующего сертификата. :D

Я бы так не говорил.В принципе 200 некорректных разговоров в месяц из 250000.Можно было бы не обращать внимания, если бы больше половины из них МГ и ВЗ звонки .Был бы у нас 1 сборщик-может мы бы этой проблемы и не увидели.Тем более в обновленном модуле meridian.dll убраны ошибки которые встречались в файлах 35595.*,36121.*,36206.*.Но получается все-равно не доделано до конца.;)

Nicolay1 пишет
Хотя теперь всплыл другой вопрос (присоединяюсь к jetc): в каких именно ситуациях Барсум лажает и неправильно тарифицирует вызовы? Или не достаточно полно отображает всю информацию о звонке.
Вобщем ,что спрашивали то и предоставил.И еще не обрабатывается ожидание(если кому-то надо). Ну и вообще неплохо было Рексофту создать какой-нибудь мусорный архив куда бы обрабатывались звонки с B-записями.Изредка бывает нужно. ;)

svgus пишет
И еще не обрабатывается ожидание(если кому-то надо).
имеется ввиду Time to Answer (OPT TTAA)?

Gluker пишет
Не стоит топить продукт, если у него появились проблемы на одном объекте. Подозреваю, что эти глюки связаны с либо с неправильной настройкой станции либо с уже сделанными "доработками".
Скорее всего связаны с "доработками",как в случае с внутренними звонками.С самих станции M61,M11-х приходят логи удовлетворяющие нас.
В настройках станций в Барсуме-возможно есть косяки.Но рекомендаций от Рексофта не поступало насчет изменений в настройках.Соответственно им отсылались архивы настроек.

Gluker пишет

цитата: svgus пишет
И еще не обрабатывается ожидание(если кому-то надо).


имеется ввиду Time to Answer (OPT TTAA)?
Вобщем да.

здрасьте
не хотелось тему создавать поэтому спрошу тут
ночью Барсум перестал регистрировать вызовы
в его журнале - ошибка sql сервера (он встроенный) - это случалось и раньше, лечилось перезагрузкой
после перезагрузки барсум выдает "невозможно открыть коммуникационный порт" и логи не пишутся
в общем не могу понять что ему не нравится
как (чем) можно посмотреть лезет ли CDR в ком-порт со станции? (tty - enbl)

если "невозможно открыть коммуникационный порт", значит смотри диспетчер задач и удаляй барсум оттуда. А вообще-то вопрос в техподдержку Барсума.

извиняюсь, что захламляю тему, но еще вопрос в догонку
встал на порт гипертерминалом - что-то в него лезет
распечатал параметры порта станции, чтобы сравнить настройки ком-порта с компутером, где живет биллинг
судя по форуму, это можно посмотреть здесь
ld 22 prt adan tty 3
ADAN TTY 3
CTYP QSDI
DNUM 3
DES CDR
FLOW NO
USER CTY
XSM NO
однако ж у меня тут этого нет (я про 19200 8-1)
неужто в станции настройки слетели? :confused:

а остальные TTY как запрограммированы?
prt adan tty

в том то и дело, что в соседних указано это
ADAN TTY 3
CTYP QSDI
DNUM 3
DES CDR
FLOW NO
USER CTY
XSM NO
ADAN TTY 4
CTYP CPSI
DNUM 4
PORT 0
DES
BPS 9600
BITL 8
STOP 1
PARY NONE
FLOW NO
USER MTC TRF SCH BUG
XSM NO
TTYLOG 0
BANR YES

lexaD-k пишет
извиняюсь, что захламляю тему, но еще вопрос в догонку
встал на порт гипертерминалом - что-то в него лезет
распечатал параметры порта станции, чтобы сравнить настройки ком-порта с компутером, где живет биллинг
судя по форуму, это можно посмотреть здесь
ld 22 prt adan tty 3
ADAN TTY 3
CTYP QSDI
DNUM 3
DES CDR
FLOW NO
USER CTY
XSM NO
однако ж у меня тут этого нет (я про 19200 8-1)
неужто в станции настройки слетели? :confused:

Исходя из CTYP QSDI - это т.н. большая машина. Надо проверять настройки на самой карте.

С_Стар пишет
Исходя из CTYP QSDI - это т.н. большая машина. Надо проверять настройки на самой карте.
то есть на плате джамперами выставляется?
там то точно никто не трогал, значит эту версию исключаю
спасибо
бермудский треугольник блин.. :D

Короче, используйте кеширование CDR на флешку и ftp-выгрузку.
Пока в форум пишете, уже столько звонков пропало!!!

И еще. Об этом чаcто упоминалось. CDR порт проверяй компом с настройками 7-N-1, даже если в TTY стоит 8-N-1

спасибо за помощь

Установите на время разборки с проблемами программу TSVlite. Она просто запишет Вам логи на диск. Настраивается просто. На любое сочетание скорости, бит и четность, которые прописаны на АТС.

vsorokin пишет
Установите на время разборки с проблемами программу TSVlite. Она просто запишет Вам логи на диск. Настраивается просто. На любое сочетание скорости, бит и четность, которые прописаны на АТС.
спасибо
только я уже гипертерминалом в файл пишу, а как разберусь протарифицирую из файла..

А как на большой станции сделать накопление CDR на флешку?

Tema пишет
А как на большой станции сделать накопление CDR на флешку? На большой станции для этого используется HDD или флешка (CPPiV).