Мне действительно интересно как еще станция может отдавать CDR кроме как через порты (ну или например PCI шину).

Например вот

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

Что это значит? Какой либо протокол обмена со станцией или что? Если можно то поменьше терминов связи а то я в этом совсем не силен к сожалению...

Если в LD 15/CDR/BDI поставить yes
а в ld 117 написать enl buf cdr
то по протоколу FTP можно забирать CDR записи из буфера c:/u/smp_db/dba.cdr

Понял только вот это:

то по протоколу FTP можно забирать CDR записи из буфера c:/u/smp_db/dba.cdr

Непонятна технология.

1) В файл скидываются CDR за определенное время т.е. отследить 1 новую запись никак не получится? Нужно грузить весь файл другими словами...

2) В данном случае FTP сервер = АТС станция? Куда станция в реальности то пишет на компьютер или все в себе? :-)

1) Пограмма Data Baffering & Access позволяет собирать копировать данные с M1 на комп (с интервалом 15 минут).
Данная программа входит с состав ОТМа

2) На M1 работает Tornado-vxWorks (5.2) FTP server (для CS 4.5)

Пограмма Data Baffering & Access позволяет собирать копировать данные с M1 на комп (с интервалом 15 минут).

Понимаете в чем фишка. Можно даже без этого обойтись а просто самому с нужным интервалом забирать данные. Другой вопрос как я понимаю в том что из этого файла нужно выцепить только новые CDR. И даже это не проблема (по крайней мере у меня) а вот то что этот файл будет например в конце дня проверять все CDR за день а в итоге загрузит только например 5 последних... Помоему это будет сильно тормозить.


Ладно в общем алгоритм понятен. Спасибо.

Как уже отмечалось ранее
http://bbs.radiolink.ru/forum/showthread.php?s=&threadid=21372&highlight=dba.cdr
диск с: имеет небольшой размер, и можно использовать Flash карту установленную с слот B.
А что мешает забрав файл с c:/u/smp_db/dba.cdr или b:/dba.cdr его удалять

"Фишек" там гораздо больше. И файлов иногда бывает гораздо больше чем один. Кроме того, что копировать их нужно еще и удалять, и удалять не FTP-шными командами...
Вобщем, лучше imho не домысливать алгоритм, а напроситься к кому-нибудь в гости и посмотреть как это всё работает в "штатном" режиме.
Удачи

А что мешает забрав файл с c:/u/smp_db/dba.cdr или b:/dba.cdr его удалять

Элементарно Ватсон - то что АТС в этот момент в него новый звонок пишет... Вот как раз PhoneMan об этом и пишет. Скорее всего надо АТС предупредить о том что ты файл трешь чтобы она притормозила запись...

Вобщем, лучше imho не домысливать алгоритм, а напроситься к кому-нибудь в гости и посмотреть как это всё работает в "штатном" режиме.

Ну так никто ж не приглашает :D

Продолжаем разговор.

Непонятно:

1) Как сообщить АТС чтобы она остановила запись в лог файл. Т.е. должен быть некий способ общаться с АТС...

2) При остановке логирования в файл записи будут оставаться в буфере чтобы потом попасть в лог файл после разблокировки?

3) Да ну и напрашивается вопрос. Зачем все это нужно городить если можно сделать через COM порт. :D

Нет необходимости останавливать запись в файл, так как вывод и так буферизируется. Файл удаляется стандартной командой ftp - DELE. После удаления файл создается заново и в него пишется содержимое буфера.
А что касается "городить огород" - не всегда воспользоваться сбором через TTY возможно и не всегда удобно.

Хм. Запутали...

Как вот это

и удалять не FTP-шными командами...

соотносится с

Файл удаляется стандартной командой ftp - DELE.

:confused:

кто не верит - может попробовать.

Я бы попробовал да негде. Человеку которому я делал программу меридиан больше не интересен теперь будет М200. Да и заморочки с FTP неособо нужны потому что CDR через COM порт идет.

тю...а я то думал меридианер....

Новая информация.
Оказывается команда DELE работает только на релизах начиная с 3.0
25.40 и старше эту команду не понимают, реакция однозначная:
DELE FILENAME.TXT
500 Command "(null)" not understood

так что фраза PhoneMan "и удалять не FTP-шными командами..." что называется не в бровь, а в глаз - мои извинения и моё почтение!

Опаньки!

PhoneMan! А чем - же удалять на более младших релизах? через оболочку?
Кстати, если понаблюдать, как работает DBA, то видно, что он переименовывает DBA.CDR в дата_время, скачивает его и отваливается. Потом этот файл висит какое-то время на флешке, а затем, как мне показалось, мерин его сам удаляет.

Кто-нибудь может подтвердить или опровергнуть это наблюдение?

TheRam пишет
Новая информация.
Оказывается команда DELE работает только на релизах начиная с 3.0
25.40 и старше эту команду не понимают

А откуда эта информация? Можно ссылочку на доку? Интересно же почитать - то...

Вот доки то как раз и нету. Попробовал сам "руками" на подведомственных станциях...
Увы.

А чем - же удалять на более младших релизах? через оболочку?

похоже так...буду сниферить трафик ОТМ-а - попробую отследить что-же он делает в это время.

TheRam пишет
буду сниферить трафик ОТМ-а - попробую отследить что-же он делает в это время.
Посмотри пожалуйста в самом процессе забирания данных ОТМ-ом не только то, что он посылает в сторону Мерина, но и что происходит на самом FTP. То, что при старте сессии файл переименовывается - это факт. Кстати, по моему, штатной команды переименования у этого FTP сервера нет. Значит OTM делает это как-то по хитрому...
Если сразу после одного сеанса запустить другой, то видно, что появляется еще один переименованный файл, похоже что мерин их потом сам прибивает. Но через большой промежуток времени...
Блин! Где бы почитать то про это?

похоже так...буду сниферить трафик ОТМ-а - попробую отследить что-же он делает в это время.
Там самое интересное - это пара UDP пакетов, с помощью которых происходит авторизация.
После авторизации, похоже, m1 сам переименовывает DBA.CDR в MMDDhhmm.CDR. При этом новые звонки пишутся в новый DBA.CDR.
По ftp ни какой магии нет - сливает файл и затирает его пустым.

Gluker пишет
По ftp ни какой магии нет - сливает файл и затирает его пустым.
нда, это решение конечно...спасибо!
тока опять все как то....изподвыподверта....
:-(
э-эх

Ну вот, коллеги - благодаря Уважаемому Gluker есть почти стандартное решение для сбора cdr по ftp.

Забирать cdr данные по ftp с Меридина оказалось проще стандартным ftp - виндузовым клиентом из командного файла, исполняемым стандартным же виндузевым скедулером.

Вот пример.

bat

cmd /c ftp -s:m1.txt
renfile.js
move *.log c:\Work\log
del dba.cdr

содержание m1.txt

open ip_адрес
имя_пользователя (не важно )
пароль PDT-шный
cd b:\
get dba.cdr
put c:\Work\log\cldb\dba.cdr
quit

ну а вызываемый скрипт renfile.js

var Shell = new ActiveXObject("WScript.Shell");
var fso, f;
fso = new ActiveXObject("Scripting.FileSystemObject");

d = new Date();
s = "";
s += d.getFullYear();
if (d.getMonth() < 9)
s += 0;
s += (d.getMonth()+1);
if (d.getDate() < 10)
s += 0;
s += d.getDate();
s += ".log";

Shell.Run("cmd.exe /c copy dba.cdr "+s+" /y",0,true)


не претендую на оригинальность и полноту решения, но может кому-то пригодится.

TheRam пишет
[i]Ну вот, коллеги - благодаря Уважаемому Gluker есть почти стандартное решение для сбора cdr по ftp.
Я описал как работает ОТМ+M1, а не то как это сделать руками.
Там фишка в том, что файл переименовывается станцией и она же его потом удаляет (скорее всего удаляются все файлы с нулевой длинной). При этом она задерживает запись новых звонков.
Если переименовывать и удалять руками, то остается вероятность потери звонков при конфликте запись/rename.
Имхо правильней расковырять механизм авторизации. Наверняка он традиционно тупой.

М-да!

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

Может быть я конечно чего-то не понял, из Вашего описания, но то, что я наблюдал в процессе работы ОТМ, дает мне основание полагать, что:
1. Переименование должно происходить именно на Мерине. (Этот прием используется очень часто при файловом обмене непрерывно работающих программных модулей. Как только Мерин отпустит файл, вы сможете его переименовать. Именно такой подход позволяет избежать ситуации, когда мерин попытается писать файл, который вы читаете);
2. Копировать с Мерина нужно именно переименованный файл;
3. Ув. Gluker скорее всего прав, по поводу того, что именно станция удаляет переименованный файл, но нужно проверить гипотезу по поводу нулевой длины файла. Мысль красивая. Как только скопировал данные успешно, захреначил обратно файл 0 длины и мерин понял, что данные забрали успешно :-)

TheRam, у меня только просьба к Вам, не обижайтесь. Это не наезд, а попытка найти истину. Я над этим вопросом давно размышляю, но, к сожалению, нет возможности "потерзать" в лабораторных условиях Мерина. А очень хотелось - бы.

To Gluker:
Может в гости пригласите? Я слышал у вас с демо - стендами все в порядке, может совместно поэкспериментируем? Благо, что в одном городе живем. Полагаю, что для нас с вами, для сообщества в целом, да и для Белтела будет несомненная польза от этих экспериментов :-)

3. Ув. Gluker скорее всего прав, по поводу того, что именно станция удаляет переименованный файл, но нужно проверить гипотезу по поводу нулевой длины файла. Мысль красивая.
На сколько я понял, файлы удаляются не сразу, а с некоторой периодичностью. Скорее всего они обнуляются для освобождения места для новых записей т.к. без pcmcia карты на с: выделяется всего 50к.

To Gluker:
Может в гости пригласите? Я слышал у вас с демо - стендами все в порядке, может совместно поэкспериментируем? Благо, что в одном городе живем. Полагаю, что для нас с вами, для сообщества в целом, да и для Белтела будет несомненная польза от этих экспериментов :-)
Я бы пригласил, но я в офисе бываю крайне редко... ;)

А что в моей методике такого военного? Я тоже ищу истину :-)

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

Что касается возможной потери CDR-записи во время загрузки/перезаписи файла - я поставил в скедулере эту процедуру на 01:00 АМ - в это время в обычном офисе никто не звонит.

Имхо это единственный недостаток - а не прав?
Готов к обсуждению!

Имхо это единственный недостаток - а не прав?
Готов к обсуждению!
Прав. Для частного случая это приемлимо, но хочется найти универсальное решение.
Есть еще один момент - подозвреваю, что m1 по udp говорит ОТМу с какого диска забирать файло.

Gluker пишет
На сколько я понял, файлы удаляются не сразу, а с некоторой периодичностью. Скорее всего они обнуляются для освобождения места для новых записей т.к. без pcmcia карты на с: выделяется всего 50к.
Похоже на правду, но не совсем. Если мониторить папку на диске b:, то видно, что после переименования dba.cdr в то, о чем говорили выше, мерин сразу после первого-же вызова создает dba.cdr , пишет в него данные, при этом переименованные файлы висят неубитыми какое-то время. Я даже специально за ними наблюдал. После окончания OTM сессии, в течение 20 минут они были живы. Потом мне пришлось отойти и вот пока меня не было они пропали... Причем без каких либо видимых действий со стороны OTM. Но это только первые наблюдения. Нужно потерзать железо попристальнее...

Gluker пишет
Я бы пригласил, но я в офисе бываю крайне редко... ;) Может совместим крайне редкий приход в офис и встречу? :-) Извини за навязчивость :-) Или может перевести обсуждение в личку? А то народ уже наверное подустал от этой темы :-)

Похоже на правду, но не совсем. Если мониторить папку на диске b:, то видно, что после переименования dba.cdr в то, о чем говорили выше, мерин сразу после первого-же вызова создает dba.cdr , пишет в него данные, при этом переименованные файлы висят неубитыми какое-то время. Я даже специально за ними наблюдал. После окончания OTM сессии, в течение 20 минут они были живы.
Т.е. файлы на b: не обнуляются?

Насколько я помню - нет. Но я в этом не уверен. К сожалению лога не вел, а сейчас мне до станций пока не дотянуться...
Блин!
Коллеги! У кого есть доступ, ОТМом и FTP проверьте гипотезу...

вот прям сейчас и ковыряюсь...
блин - еще новости от Любимого Вендора...имя пользователя и пароль стали case sensitive, и если имел наглость создать именно в нижнем индексе - при авторизаци вторая букива имени ОТМ-ом чекрыжится в 00 - в результате файлед логин...

Да, получается что именно в момент коннекции udp по порту 1929 файл dba.cdr переименовывается в 03151747.CDR (ну или там другие цифири - это понятно)
Всего 4 пакета, два туда, два обратно. Более по udp трафика нет.
Следом OTM коннектится ftp штатно и это файл сливает.
Аккурат после "слива" он обнуляется.
А следующие вызовы пишутся в DBA.CDR

да, файл обнуляется именно ОТМ-ом, из лога это видно

2TheRam: поделись udp пакетами pls.
Правда там пароли будут... но мне они без надобности?:)

Леша, сюда постить я думаю нет смысла - и так топик перегружен. Я тебе по почте вышлю.
Валера - надо?

А удаление этого переименованного файла когда происходит? И кто это делает? У меня на версии 3.0 не работает Оказывается команда DELE работает только на релизах начиная с 3.0

Да! За пакетики я буду очень признателен. А то когда еще до живого железа доберусь... Заранее спасибо.

Пока не понял - жду вот...но похоже не ОТМ, поскольку во-первых не может :-) во-вторых уже несколько раз коннектился - пока все присутствуют...
3.0 кхм...даже так...сорри!

Имхо М1 сам периодически выполняет dbaCleanupFiles.

Может у меня какого патча не хватало... Как всегда...
Но странно... Неужели даже внутри 3.0 эта команда может быть, а может и не быть... (DELE).

To TheRam:
Правильно ли я понимаю эту фразу: да, файл обнуляется именно ОТМ-ом, из лога это видно
ОТМ затирает старый файл новым но 0 длины. При этом OTM использует стандартную FTP команду типа PUT. Или я что-то упустил?

Аккурат после сообщения TIM000 18:30 15/3/2006 CPU 0 все временные файлы изчезли. DBA не коннектился, на станции никаких действий в момент "исчезновения"
До этого запускал руками LD 1 - ничего.

А сколько времени прошло до исчезания?

Первый файл был создан в 17:48, последний в 18:05 - удалились все разом в 18:30.
Коллеги - переносим дискуссию почту или аську, фатит тут уже...

Результат незабудьте огласить только... :)

jellfish пишет
Результат незабудьте огласить только... :)
Выложил первую версию DBALog v1.01 (http://www.tura.sp.ru/downloads.htm)

А ведь работает!!! :-D

p.s. и логично работает!

А как работает то? :-) Неужели идентичные UDP пакеты шлет? :-)

Это было бы самое простое...в том то и дело что отличаются...

jellfish пишет
А как работает то? :-) Неужели идентичные UDP пакеты шлет? :-)
Шлет по образу и подобию. Только id сессии всегда одинаковый.

To Gluker
Поздравляю с новорожденой программой. :-)