Здрасьте Вам !

Помогите, пожалуйста, разобраться в следующей ситуации:

Есть цепочка станций

Узел2 - Узел1 - МД110 - ГТС

Узел2 - периферийный узел сети ОХЕ
Узел1 - центральный узел сети ОХЕ (здесь собираются тикеты)
МД110 - соединение по ISDN (ABC-F)
ГТС - соединение по ISDN

Итак вызов:
Узел2 - МД110 есть тикет (CallType = LocalTransit)
Узел2 - ГТС есть тикет (CallType = PrivateNetworkOutgoingCalltoPrivateNetwork)
Узел1 - МД110 есть тикет (CallType = LocalNetworkCall)
Узел1 - ГТС тикета НЕТ ВООБЩЕ (что странно, учитывая, что вызов по более длинной цепочке Узел2 - ГТС откладывается ) :(

В связи с чем два вопроса:
1) Где начать рыть, что-бы эти тикеты у меня все таки были?
2) Я предполагал, что CallType - это типы вызовов, которые можно фильтровать в "Applications/Accounting/File ParametersFor Ext Accounting/Filter", но как я здесь вижу ни "LocalTransit", ни тем более "PrivateNetworkOutgoingCalltoPrivateNetwork" в указанных выше фильтрах нет. Где про них можно хоть что-то прочесть? От куда они беруться?
Заранее спасибо.

Еще одно наблюдение! :)

При смене сигнализации между Узлом 1 и МД110 с ABC-F на Q-SIG - все тикеты в наличие. А тот, потеряный, называются "CallType = PrivateNetworkCall"!

:)

Насчет потери тикетов, проверьте ваш ли это случай. Есть две станции 1 и 2. Стык - ABC-F, QSIG или ISDN с галкой private=true. Network mode стоит на узле 1.
Подключение к городу на узле 1.
Что будет на узле 1.
1) Абонент узла 1 - город, тикет есть.
2) Абонент узла 2 - город, тикет есть.
3) Город - абонент узла 1, тикет есть.
4) Город - абонент узла 2, на узле 1 тикета нет, на втором есть.
Из-за этого приходилось иногда подключение станций делать через два потока (две группы (одна входящая, другая исходящая). И режим Network разный в разных потоках.
Если транковая группа ISDN (без галки private) - все тикеты будут, но в случае 2 их будет два (входящий и транзитный).

Думаю, что это не тот случай.
Попытаюсь еще раз описать, но немного короче:
Есть цепочка:

ОХЕ - МД - ГТС
(где ОХЕ - наша - на ней тикеты, в сторону МД сигнализация ABC-F)

ОХЕ -> МД (тикет ЕСТЬ)

ОХЕ -> МД -> ГТС (тикета НЕТ)

Т.е. с точки зрения ОХЕ, вызовы на МД и ГТС - абсолютно одинаковы. ОХЕ не знает какие вызовы окончатся на МД, а какие уйдут далее транзитом. Т.е. мне представляется, что в момент соединения МД "говорит", что вызов для нее является транзитным. И это каким-то образом влияет на отсутствие/наличие тикета на ОХЕ.
Смотрел трассу в обоих случаях: естественно есть различия в сообщениях ALERT и CONNECT, а еще в странзитном случае есть сообщение PROGRESS, - оно, вроде как, и передает на вызывающую сторону особенности маршрута. Копать здесь глубже смысла особого не вижу.


ЗЫ. Еще раз скажу, что при смене сигнализации на Q-SIG - все тикеты в наличие. Конечно, можно было решить проблему "в лоб" и поставить Q-SIG, но уж очень бы хотелось сохранить хождение имен между ОХЕ и МД.

Есть у меня еще решение - сделать два потока, и пустить отдельно вызовы на МД (по ABC-F) и через МД в ГТС (по Q-SIG) - тогда, вроде как, проблема решается.

Но хотелось бы разобраться: почему ОХЕ при сигнализации ABC-F не хочет сохранять этот тип тикетов?

А в настройках тарификации все фильтры включили? Ну и есть ли какие-то инциденты на станции на тему тарификации.

Да, фильтры включил абсолютно все.
Инцидентов по тарификации нет...

Обманул, однако :))
Есть инцидент:
20/08/07 13:10:14 000001M|--/--/-/---|=2:0283=ACCOUNTING. Appli CALLHANDLING : feature incident 2 9270

Вот что о нем написано:

Incident number (q to quit):0283

INCIDENT NUMBER: 283
Network indicator: Alcatel 4400
OBJECT CLASS: Dhs3x_node
EVENT TYPE: ProcessingErrorAlarm (10)
PROBABLE CAUSE: Unknown (0)
SEVERITY: Major

"ACCOUNTING. Appli P1 : feature incident P2 P3"
"charging"
"P1 : 14 = APL_CALLHANDLING"
"P2 : -1 = non significant"
" P3= The first four digits of the emitted number."
"P2 :0 = BAD_PERIOD"
" bad period number for the week day."
" P3= the last digit returns the week day value."
"P2 :1 = BAD_TARIF"
" bad tarif number."
" P3= bad tarif number."
"P2 :2 = BAD_BAREME"
" bad or unknown charge scale number for the emitted number."
" P3= The first four digits of the emitted number."
"P2 :3 = BAD_CALENDAR"
" the accounting ticket date is not in the calendar."
" P3= 0."
"P2 :4 = BAD_DATE"
" the accounting ticket date is false."
" P3= 0."
"P3 :Status"
"Duration charging"
"The duration charging is used for all the O/G calls on a charged trunk group"
"with a switch over to conversation and 0 tax received from the network."
"In duration charging management, each number must be assigned to a zone, and"
"subsequently to a scale of charges (one scale of charges per zone)."
"The accounting ticket is sent back to internal accounting with a number of"
"charging units = 0."
"Note the incident with all its information on an observation slip"
"(anomaly report), specifying if possible the error context."
"Check the whole duration charging management.";

Пока разбираюсь...

Станция не знает к какой шкале относится номер, который начинается с 9270. Соответственно не сохраняет его.
Charges scales и area. ЕСли не требуется тарификация силами станции, а только регистрация - достаточно одной шкалы, а в area создаете минимальный номер 0, макс 9, шкала 1 (та которая есть).

Да.
Сделал Area - она стала давать другой инцидент и просить дни недели. Заполнил.
Инцидент пропал. Но тикета нет по-прежнему... :(