На
> VERSION 1411
>RELEASE 21
> ISSUE 19
> IN-SERVICE PATCHES : 0
после очередной коррекции времени
> STAD 30 07 2003 07 56 45
в CDR стали откладываться звонки начавшиеся со странного времени
> N 006 00 A025029 DN221 08/01 10:50:60 00:00:00.0
> N 059 00 T048002 DN268 08/01 11:06:00 00:02:28.0
Примерно каждая шестидесятая запись идет с неправильным временем... Количество секунд от 00 до 60 это 61. Анализаторы логов глюкуют, аднака. После очередного
> STAD 08 08 2003 08 07 30
ситуация исправилась.
Что это было? Есть подозрение, что могло повлиять нечетное количество секунд при установке времени. Не хочется повторения.

Никто таки не сталкивался? Ладно, пока взял за правило в STAD указывать 00 секунд - в CDR до сих пор полет нормальный.
Почти. Вот еще один глюк...

Как в CDR по номеру RTMB определить задействованную городскую линию в случае потока? Никак, можно только по номеру задействованного DN. CLID и все такое - этого в CDR нет. Пытаемся определить вот в таком случае:

>S 088 00 742 A001028 08/13 10:16:29 00:00:00.0 A71019ххх
&
& 000 01
D 089 00 742 A001028 08/13 10:16:29 00:00:00.0 9ххх

Исходящий был от 742, по этому DN и вычисляем городской номер, на который, например, прийдет счет.

>S 090 00 A001010 742 08/13 10:16:17 00:00:12.0
&хххххххххXXXXXXX
& 000 01 2 02
D 091 00 A001010 742 08/13 10:16:29 00:00:12.0

Входящий был на 742, по этому DN вычисляем городской номер.

>E 097 00 T001010 T001028 08/13 10:17:36 00:01:08.0
&хххххххххXXXXXXX
& 000 01 2 02

Смотрим предыдущие записи, сопоставляем RTMB. В последней записи явно был входящий и исходящий 742, по нему вычисляем на какой номер прийдет счет. И можем понять на какую линию в статистику дописать нагрузку. И так далее, и все такое.
Внимание здесь следует обратить вот на что: третья запись, "Е" которая, ее время - это не время начала соединения, а время его окончания. Но
16:17 + 0:12 = 16:29
17:36 - 1:08 = 16:28
То есть третье соединение началось раньше окончания второго! Поэтому если я отсортирую записи по дате-времени, то отследить номер, с использованием которого делался исходящий звонок по транку 001028, будет невозможно - третье соединение начинается или раньше или позже окончания второго, плюс-минус три секунды.
Не вычитать из записей типа "E" и "D" продолжительность, чтобы определить время начала соединения? Нельзя - бывает так, что следующее соединение по этому же транку началось раньше, чем закончилось предыдущее. Хоть на секунду, но раньше, бывает - гуляет время в CDR до трех секунд в любую сторону.
Нельзя сортировать? Кто писал обработку логов, тот поймет - прийдется как-то наворачивать подачу файлов обработчику, чтобы не сортировать звонки впоследствии.
И таких примеров хватает:
S 030 00 DN260 T045005 08/13 10:37:08 00:01:22.0 7145xxxxxxx
E 032 00 DN308 T045005 08/13 10:38:39 00:00:08.0
N 033 00 DN308 T045005 08/13 10:38:31 00:00:08.0 308