Привет любимому форуму!
Имеем проблему расхождений учета межоператорского трафика (по длительности соединений) с учетом присоединяющего оператора.
Анализ показал, что ВРЕМЯ ОКОНЧАНИЯ соединения в том и другом биллинге может различаться. Причем CDR Meridian`а фиксирует окончание соединения по отбою ЛОКАЛЬНОГО абонента. Время дисконнекта в канале EDSS1 (по которому, видимо, считает другой биллинг) не всегда совпадает с отбоем моего абонента.
Характер статистики ошибок можно варьировать изменением значения таймера T306. Когда T306 был 120 (то ли умолчание, то ли установщик поставил) было +2...4% ошибки завышения длительностей у нас. Попробовали обнулить. Получили примерно ту же величину ошибки, но со знаком минус. Подбирать T306 для усреднения ошибки к нулевому среднему нет никакого желания.
Есть ли честное решение проблемы?

Время окончания соединения в CDR Meridian`а определяется суммой времени старта и длительности соединения. По умолчанию, длительность определяется с точностью в 2 сек.
А параметр DUR5 (LD17) у Вас YES?
В этом случае получите точность определения длительности соединения в 0,5 сек.
Кстати, можно поинтересоваться и у оператора связи, с какой точностью у него фиксируется длительность соединения.

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

Время окончания соединения в CDR Meridian`а определяется суммой времени старта и длительности соединения.
Не согласен. ДЛИТЕЛЬНОСТЬ СОЕДИНЕНИЯ не может быть получена непосредственно из событий протокола сигнализации. Она вычисляется как разность между началом голосового соединения ("Ответ Б", как правило) и его завершением (в идеале первый пришедший из "Отбой А", "Отбой Б" ).
По умолчанию, длительность определяется с точностью в 2 сек.
А параметр DUR5 (LD17) у Вас YES?
В этом случае получите точность определения длительности соединения в 0,5 сек.
Да, поставил сразу же, когда запускали систему.
Кстати, можно поинтересоваться и у оператора связи, с какой точностью у него фиксируется длительность соединения.
1 сек. по договору присоединения.
Необходимо также отметить, что на стороне инициатора вызова всегда длительность соединения несколько (обычно - до 1 сек) меньше, чем на стороне, терминирующей вызов. Так, у входящего от оператора связи вызов с вашей стороны будет иметь бОльшую длительность, чем та, которую измерит оператор. И наоборот. (На время осуществления разъединения) ...
Пояснение интересное. Оно объясняет часть составляющей ошибок.
Но я задавал вопрос о действии существенно более грубого фактора. - К КАКОМУ МОМЕНТУ CDR ПРИВЯЗЫВАЕТ МОМЕНТ ЗАВЕРШЕНИЯ СОЕДИНЕНИЯ? В идеале при межоператорском учете это должен быть канальный дисконнект. Тогда методически ошибки минимальны.
Но, блин, эксперименты показали, что CDR привязывается к отбою локального абонента. В доказательство привожу пример самой грубой ошибки. Внешний входящии вызов на FAX/Answer mashine. Услышав болтовню факса входящий абонент А сразу бросает трубу. Факс еще минуту держит линию. И эта минута идет в ошибку! Правда, такое бл...во было при установленном по умолчанию INC_T306=120. Порывшись в доках, я правда, нашел два умолчания (INC/OUT) 120/120 (видимо, для SL1) и 2/30 (для EDSS1). Сейчас, от безысходности, поставил 2/30. Будем ждать, что получится. Можно, конечно, оперативно запросить тестовые биллинги той стороны, но там структура СвязьИнвеста, а это куча бюрократических формальностей.

Вы сами пишете, что "факс еще минуту держит линию". Т.о., с вашей стороны отбоя нет. Однако, как Вы утверждаете, с противоположной стороны абонент уже положил трубку.
Среди других, возможны варианты:
1. У вас Meridian (или EDSS1?) настроен на ожидание двустороннего отбоя. (Не помню, где это устанавливается...). И ждет, пока не отобьется вторая сторона.
2. У вашего оператора связи (или у транзитного) аналогичные проблемы. Они часто возникают вследствие многократной смены протоколов сигнализации в процессе установления соединения.

Из личного опыта. Многократно наблюдал "зависание" вызова при транзите вызова с аналоговой СЛ в EDSS1 при плохо положенной трубке на одном из концов... (С MFC такое не происходит).
Однажды здорово "напоролись" с транзитом вызовов на Кубу. (Это был не Meridian). Добрая половина из них давала код отбоя, отличный от "нормального завершения" (16 и 31 по Q.931). Но, поскольку присоединены к оператору связи были по ОКС7 (которому "наплевать" на коды отбоя), доказать ничего не удалось и пришлось платить за фактически не состоявшиеся вызовы...

1. У вас Meridian (или EDSS1?) настроен на ожидание двустороннего отбоя. (Не помню, где это устанавливается...). И ждет, пока не отобьется вторая сторона.
Да здесь прозрачнее. Я же не зря пишу про T306. Этот таймер задерживает дисконнект, чтобы мой абонент мог прослушать акустику в канале. Дисконнект в этом случае происходит по первому наступившему событию:
1.отбою абонента Meridian
2.истечению задержки в T306.
Экстрим с минутной ошибкой мы прибили сразу, обнулив T306. Но то, что CDR берет окончание соединения с локального отбоя, а не с канала, никуда не делось. С T306=0 местный биллинг стал давать отсчеты меньше соседского, т.к. локальный отбой стал чаще приходить раньше. С T306=2 сек. ошибка может и усреднится к 0, но это же не устраняет методическую ошибку измерения.

2. У вашего оператора связи (или у транзитного) аналогичные проблемы. Они часто возникают вследствие многократной смены протоколов сигнализации в процессе установления соединения.
Это точно. Это же ТфОП миллионного города, каких зверинцев там только нет. Прикольно другое, что есть направления тарификации, где погрешности почти нет (междугородка например, или новые узлы присоединения).


А что еще подкрутить в CDR или PRI так и не нашли...

1. У вас Meridian (или EDSS1?) настроен на ожидание двустороннего отбоя. (Не помню, где это устанавливается...). И ждет, пока не отобьется вторая сторона.


В маршруте NEDC ETH, FEDC ETH - оно?

В маршруте NEDC ETH, FEDC ETH - оно?


DID EDSS1 - нету здесь NEDC и FEDC:confused:

TYPE: rdb
CUST 0
ROUT
ACOD

TYPE RDB
CUST 00
ROUT 1
DES USI_MAIN
TKTP DID
NPID_TBL_NUM 0
SAT NO
RCLS EXT
VTRK NO
NODE
DTRK YES
BRIP NO
DGTP PRI2
ISDN YES
MODE PRA
IFC EURO
CNTY ETSI
SBN NO
PNI 00000
NCNA NO
NCRD NO
ISAR NO
CPFXS YES
SDID YES
CTON NATL
DAPC NO
INTC NO
DSEL VOD
PTYP DCO
AUTO NO
DNIS NO
DCDR NO
ICOG IAO
RANX NO
SRCH RRB
TRMB YES
STEP
ACOD 4901
TCPP NO
TARG 01 09
CLEN 1
BILN NO
OABS
INST
IDC YES
DCNO 0
NDNO 0 *
DEXT NO
DNAM NO
MFC NO
ICIS YES
OGIS YES
TIMR ICF 512
OGF 512
EOD 13952
NRD 10112
DDL 70
ODT 4096
RGV 640
FLH 510
GTO 896
GTI 896
SFB 3


PAGE 002

NBS 2048
NBL 4096
RTD 12
DTD NO
SCDT NO
2 DT NO
DDO NO
DRNG NO
CDR YES
INC YES
LAST NO
QREC NO
OAL YES
AIA YES
OAN YES
OPD YES
NDP EXC 0
CDRX NO
NATL NO
TDG 8
SSL
CFWR NO
IDOP NO
MUS YES
MRT 12
MR NO
PANS YES
EQAR NO
FRL 0 0
FRL 1 0
FRL 2 0
FRL 3 0
FRL 4 0
FRL 5 0
FRL 6 0
FRL 7 0
TTBL 0
ATAN NO
OPR NO
PRDL YES
EOS NO
DNSZ 0
RCAL NO
MCTS NO
ALRM NO
BTT 30
ACKW NO
ART 0
PECL NO
DCTI 0
TIDY 14901 1
SGRP 0
ARDN NO
ANIE 0
CAC_CIS 1
AACR NO

При изменении нужно сначала CNTL YES.

При изменении нужно сначала CNTL YES.

>ld 16
RDB000
MEM AVAIL: (U/P): 51030586 USED U P: 434706 148400 TOT: 51613692
DISK SPACE NEEDED: 193 KBYTES
RAN RTE AVAIL: 512 USED: 0 TOT: 512
REQ chg
TYPE rdb
CUST 0
ROUT 2
DES
TKTP
SAT
RCLS
DTRK YES
DGTP PRI2
ISDN YES
MODE
IFC
CNTY
SBN
PNI
CPFXS
SDID
DAPC
INTC
DSEL
PTYP
DNIS
DCDR
IANI
ICOG
RANX
SRCH
TRMB
STEP
ACOD
CLEN
TCPP
TARG
BILN
SGRP
OABS
INST
IDC
DCNO
NDNO
DEXT
ICIS
OGIS
CNTL yes
TIMR
DRNG
CDR
NATL
TDG
SSL
CFWR
IDOP
MUS
PANS
EQAR
FRL
TTBL
ATAN
OPR
PRDL
DNSZ
RCAL
MCTS
ALRM
BTT
ACKW
PECL
DCTI
TIDY
ARDN
ANIE
CAC_CIS

MEM AVAIL: (U/P): 51030586 USED U P: 434706 148400 TOT: 51613692
DISK SPACE NEEDED: 193 KBYTES
RAN RTE AVAIL: 512 USED: 0 TOT: 512
REQ

Увы...

По 311-й доке:
NEDC Near End Disconnect Control basic-1
This entry determines the type of control exercised by
the Meridian SL - 1 on trunk disconnections.

Т.е. якобы для SL-1?...