Доброго времени суток уважаемые специалисты...
Есть вопросс следующего характера: имеем ЛДК-300 с 2 потоками, время от времени один из потоков "затыкается " на нашей атс ( кпв есть-звонка нет)...Лечится только ресетом...Причём затыкается только один поток, второй работает исправно...Меня очень сильно смущает подмена каналов в команде "аллерт", на трассе это хорошо видно. Кабеля синхры проверяли, платы местами меняли ( проблема остаётся с потоком, а не уходит с платой), прошивку тоже меняли вместе с процом ( на всякий случай ), сейчас версия 3.6 . Если есть какието соображения, прошу поделится.
Привожу один пример трейса с ЛДК,прилагаю файлик поболее, так как поток звонков большой прошу прощенья за невозможность отследить один какой-то звонок.....
Заранее спасибо.......

(CO 23) SETUP
IE_BEARER_CAPABILITY
IE_CHANNEL_INFO
IE_CALLING_NO
1111111111
IE_CALLED_NO
1111111
IE_SEND_COMPLETE

145358 C>06 11, D1 06 02 18 03 A9 83 8B
--------------------============================================>>>>>>>>>>
(CO 23) CALL PROCEEDING
IE_CHANNEL_INFO

145358 COL 023:06 11 St:co idle (00) Ev-I:ring start P1: 0 P2: 0 EVT: 11 <- 23,61
145358 D>06 11, C0 00 4E
145358 COL 023:06 11 St:di-dialing(00) Ev-I:disa dgt P1: 1 P2: 0 EVT: 80 <- 23,61
145358 COL 023:06 11 St:di-dialing(00) Ev-I:disa dgt P1: 1 P2: 0 EVT: 80 <- 23,61
145358 COL 023:06 11 St:di-dialing(00) Ev-I:disa dgt P1: 1 P2: 0 EVT: 80 <- 23,61
145358 COL 023:06 11 St:di-dialing(00) Ev-I:disa dgt P1: 1 P2: 0 EVT: 80 <- 23,61
145358 COL 023:06 11 St:di-dialing(00) Ev-I:disa dgt P1: 1 P2: 0 EVT: 80 <- 23,61
145358 COL 023:06 11 St:di-dialing(00) Ev-I:disa dgt P1: 1 P2: 0 EVT: 80 <- 23,61
145358 COL 023:06 11 St:di-dialing(00) Ev-I:disa dgt P1: 1 P2: C EVT: 80 <- 23,61
145358 D>06 11, C5 00 00
145358 D>06 11, C5 00 00
145359 D>06 11, C0 00 4E
145359 D>06 11, C5 05 01
145359 COL 023:06 11 St:hnt-queued(00) Ev-I:dummy acd P1:26F3 P2: 0 EVT: 0 <- 23,61
145359 COL 023:06 11 St:hnt-queued(00) Ev-I:dummy acd P1:26AF P2: 2 EVT: 0 <- 23,61
145359 COL 023:06 11 St:hnt-queued(00) Ev-I:dd rng ack P1: 0 P2: 0 EVT: 82 <- 2,01
145359 C>06 11, D0 06 01 18 03 A9 83 8B
--------------------============================================>>>>>>>>>>
(CO 23) ALERTING
IE_CHANNEL_INFO

145359 COL 024:06 12 St:co idle (00) EVT 5 24 05 04 03 80 90 A3 18 03 A1 83 8C 6C 0C 21 80 30 36 33 33 37 35 33 34 37 38 70 08 C1 34 35 35 39
39 35 35 A1 (U0)
145361 COL 025:06 13 St:co idle (00) EVT 5 24 05145363 COL 022:06 10 St:co idle (00) 145363 D>06 10, C5 00 00
145374 COL 030:06 18 St:ds-talk (00) EVT E 05 45 08 02 81 90 (U10)
<<<<<<<<<<============================================--------------------
(CO 30) DISCONNECT
IE_CAUSE
CCITT standardized coding
private network serving local user
normal call clearing

145374 C>06 18, DF 05 4D 08 02 81 90
--------------------============================================>>>>>>>>>>
(CO 30) RELEASE
IE_CAUSE
CCITT standardized coding

145375 COL 030:06 18 St:ds-talk (00) EVT :E0 05 5A 08 02 81 90 (U19)
IE_CAUSE

145378 COL 030:06 18 St:ds-talk (00) Ev-T:isd rls gd P1: 0 P2: 0 TMR: 9 <- 30,61
145378 D>06 18, C5 00 00
EVT F 05 4D 08145383 COL 027:06 15 St:di-dialing(00) 145384 D>06 15, C5 00 00
145399 COL 024:06 12 St:hnt-queued(00) EVT E 05 45 08 02 81 90 (U7)
<<<<<<<<<<============================================--------------------
(CO 24) DISCONNECT
IE_CAUSE
CCITT standardized coding
private network serving local user
normal call clearing

145399 C>06 12, DF 05 4D 08 02 81 90
--------------------============================================>>>>>>>>>>
(CO 24) RELEASE
IE_CAUSE
145403 COL 029:06 17 St:co idle (00) EVT 5 24 05 04 03 80 90 5A145409 COL 025:06 13 St:co idle (00) Ev-T:isd rls gd P1: 0 P2: 0 TMR: 9 <- 25,61
145410 COL 013:06 01 St:co idle (00) 145416 COL 014:06 02 St:hnt-queued(00) EVT E 05 45 08 02 81 90 (U7)

С чего Вы это взяли??? Где Вы это на трассе "хорошо увидели"???
Здесь нет никакой подмены каналов!!! Входящий вызов был в 11 канале, вот для 11-го канала и выдается Call_Proc и Allert.

добрый день....почему 11 ???? 23


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

CO 23) ----- ? ALERTING
IE_CHANNEL_INFO

145359 COL 024 ------ ? :06 12 St:co idle (00) EVT 5 24 05 04 03 80 90 A3 18 03 A1 83 8C 6C 0C 21 80 30 36 33 33 37 35 33 34 37 38 70 08 C1 34 35 35 39
39 35 35 A1 (U0)
145361 COL 025 -------- ?:06 13 St:co idle (00) EVT 5 24 05145363 COL 022:06 10 St:co idle (00) 145363 D>06 10, C5 00 00
145374 COL 030 --------- ?:06 18 St:ds-talk (00) EVT E 05 45 08 02 81 90 (U10)

Совершенно не туда!!!

Вот Alerting:
145359 C>06 11, D0 06 01 18 03 A9 83 8B

6-ой слот, 11 канал - это и есть ваша СО023

даа...это я понимаю что для потока 11 а для меня 23 ))))))
а это что обозначает????

145359 COL 024 ------ ? :06 12
45361 COL 025 -------- ?:06 13
145374 COL 030 --------- ?:06 18

А говорите, что понимаете...
Это относится к вызовам, осуществляемым по другим каналам потока (12, 13, 18). Т.е. это уже другие вызовы.

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

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

1. Вызовы ТОЛЬКО входящие, направляются на группу операторов ( 12 системных телефонов )
2. Пропадают ВСЕ вызовы с данного потока, с аналоговых линий и другого потока - порядок, лечится только ресетом, пропадают в среднем 3 раза в день
3. трассировку завтра сниму, только один вызов сложно поймать , там проходит в среднем 600-900 звонков в час
4. Нет, поток который нормально работает от провайдера, который глючит - с астериска..Синхру берём от провайдера и транслируем на астериск( пробовали сервевер и мастером и слейвом - результат тот-же). На астериске смотрели трассу тоже, сказали что алерт отрабатывается корректно( но звонков нет )
5. Нет , поток физически нормальный, выход с него проверить нет возможности ( так как исходящей связи там вообще нет)

От нагрузки это не зависит, так как если отключить ( програмно) поток с астериска и направить трафик на поток провайдера - всё ок...

- вызовы в этом потоке принимаете как DID или как Normal (ПГМ140)??
- что прописано в ПГМ167/2 (Error)??
- что прописано для каналов этого потока в ПГМ144??
- какой тип Hunt-группы (ПГМ190)??? Что прописано в атрибутах группы (ПГМ191)??

1. потоки настроены как DID
2. в пгм 167 везде Attd
3. всё на группу 620
4. группа ринговая, с настройками по умолчанию

и с первого и со второго потока звонки валятся по одной мсн ячейке ( т.е. для атс существует только один городской номер для всего).....

Проверьте: входящие вызовы в проблемном потоке поступают в одних и тех каналах???
- при нормальной работе потока
- когда поток "заткнулся"
Или вызовы идут "кругу" и начиная с каких-то каналов уходят в "никуда"...
Т.е. посмотрите, связана ли проблема с номерами каналов, в которых приходит вызов??

[quote name='R@M' date='22.12.2009, 13:36' post='27094']
Доброго времени суток уважаемые специалисты...
Есть вопросс следующего характера: имеем ЛДК-300 с 2 потоками, время от времени один из потоков "затыкается " на нашей атс ( кпв есть-звонка нет)...Лечится только ресетом...Причём затыкается только один поток, второй работает исправно.

Добрый день! У меня такая же ерунда была со вторым потоком. Оба потока и на АТС и на ГАТС объеденены логически в один пул. Плата первогов первом KSU, а вторая во втором. Кабели синхронизации и пр. все есть. Неисправность выглядела так: аварии на плате не было, входящие как бы подвисали, т.е. нет отбоя и нет соединения. Если при нажатии 9-ки попадался канал из второго потока, то АТС сама играла отбой. Лечилось тока ресетом. Но, когда это стало надоедать, то я позвонил на ГАТС и попросил их перегрузить их плату Е1 в их АТС. И все прошло. Меня иногда удивляет, что в моментах, где возможно виновата или ГАТС или УПАТС, подозрение падает только на LDK-300. И никто не лечит провайдера...

добрый день...
to harris: нет, входящие рулятся по кругу, распределяются по всему потоку, зависимости от каналов точно нет( так как при таком трафике все каналы перебираются за 1-2 мин)

to ЛыЖник: дело в том что как раз от провайдера с потоком всё ок(даже если мы весь трафик переключим на один поток-есть такая возможность) атс работает месяцами как вкопанная,,,,,,,а вот только подключаем астериск - всё ресет ( причём странно там уже могут спрогнозировать ресет по времени с разницой в 1-2 часа???????????)....Причём ресет необязательно атс, можна и астериск-поможет.......Я интуитивно подозреваю что дело в сервере, но я хочу предметно даказать это........


to harris:Вы просили трейс без "n", вот кусок, во время всего трейса ни один телефон не звонил.......

спасибо

На этой трассировке видно, что:
1) на некоторые вызовы был ответ!!! Если Вы говорите, что телефоны в это время не звонили, то скорее всего у Вас в атрибутах группы указана выдача Гарантированного приветствия (VMIB Announce 1, Timer 1 =0 )!!!
Ответ был дан через разное время, возможно вызов ожидал пока освободится канал на VMIB.
К сожалению, в эту часть лога не попали дальнейшие сообщения об этих вызовах... Может у Вас используется достачно длинное привествие?? Ну, вообщем для этих вызовов осталось неясно, что с ними было дальше.
2) На некоторые вызовы после того, как LDK дает сообщение Alerting в сторону Астериска и ставит вызов в очередь в Hunt-группу, от Астериска приходит Disconnect!!!!! (через 2 -4 сек от начала вызова). Т.е. Астериск разъединяет вызов, для которого еще не было даже воспроизведено Приветствие группы (не было Connect'а), поэтому телефоны операторов и не звонят!!

По второму пункту понял....
По первому - у нас нет в атс голоса ????????

Вы написали, что в течении этого времени, телефоны операторов не звонили.
Но на эти вызовы был ответ (Connect)!!! Значит операторы все-таки продолжали принимать вызовы с этого потока???
Что у Вас указано в атрибутах этой Hunt-группы операторв???

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

В трассировке видны именно вызовы по этому же потоку (слот 6), и на эти вызовы был дан Connect (ответ)!!!

в этом то и проблема ??????
Но....месяца 3 назад в 5 слоту стоял голос, я вместо него поставил поток, который нормальный ( городской )

1) Почему код страны = Корея ???
2) Что-нибудь прописано в ПГМ231/5 (Reroute dest.) для этого вашего DID-номера (индекса)???
3) Что значит "раньше стоял голос"??? В слоту 5 раньше была установлена плата VMIB/AAIB ???
А где она сейчас???

Вообще-то, на мой взгляд, делать из 12-ти операторов группу типа RING при большой интесивности входящих вызовов - это как-то бредово... Одновременно приходит несколько вызовов с разных потоков... Зачем Вам понадобтлось, чтобы звонили все операторы одновременно???? В этих случаях обычно используется UCD-группа. Вызов распределяется на свободного оператора.

1. Оставили по умолчанию
2. Not Asigment
3. Да, раньше была установлена плата AAIB, сейчас нету за ненадобностью....

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

1. Вообще-то, код страны должен быть = CIS (страны СНГ). В некоторых процедурах все-таки есть различия, специально сделанные с учетом наших требований.

ОК. Итого:
- часть вызовов сразу же (2 -4 сек) отбивается со стороны Астериска. Нужно разбираться с Астериском и смотреть его трассировки, почему он отбивает вызов.
- на часть вызовов есть ответ. Нужно искать, кто ответил..
Можно это отследить либо по записям SMDR, либо по логу CLI Print (Call Info).

Код страны сменим, это не повлияет ни на что?? ( я спрашиваю потому-что на старых ЖДК-100 это была довольно болезненная процедура )

Логи будем ловить ( и те и те )......Так как нужно ждать глюка часов 8-9 , завтра результат будет доложен......


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


спасибо.....

Смена кода страны не устранит проблему, но тем не менее, ИМХО, все-таки лучше поставить CIS.
В станциях LDK (в отличие от GDK) код страны меняется безболезненно.
- DIP8 на MPB поставить в ON (вправо)
- В ПГМ100/1 указать 7 (CIS)
- Внимание: вернуть DIP8 на MPB в положение OFF (влево)!!!!
- перезапустить станцию.

Вот, все подобные строки - это сообщения Connect:
022386 C>06 21, D2 0C 07 4C 09 20 81 34 35 35 39 39 35 35

@ОК. Итого:
- часть вызовов сразу же (2 -4 сек) отбивается со стороны Астериска. Нужно разбираться с Астериском и смотреть его трассировки, почему он отбивает вызов. @


доброго времени суток...

подскажите пожалуйста, а где конкретно по трассе видно что отбой приходит через 2-3 сек....
спасибо

Ну, например, здесь:

1)
Входящий Setup:
022382 COL 035:06 23 St:co idle (00) EVT 5 24 05 04 03 80 90 A3 18 03 A1 83 98 6C 0C 21 80 30 39 37 39 35 31 38 38 38 39 70 08 C1 34 35 35 39 39 35 35 A1 (U0)
………… (Сообщения Сall_Proc, Alert я пропускаю)
А через 4 сек приходит Disconnect от Астериска:
022425 COL 035:06 23 St:hnt-queued(00) EVT E 05 45 08 02 81 90 (U7)

2)
Входящий Setup:
022471 COL 037:06 25 St:co idle (00) EVT 5 24 05 04 03 80 90 A3 18 03 A1 83 9A 6C 0C 21 80 30 39 36 38 32 37 37 32 34 38 70 08 C1 34 35 35 39 39 35 35 A1 (U0)
………….
А через 4 сек приходит Disconnect от Астериска:
022513 COL 037:06 25 St:wait gring(00) EVT E 05 45 08 02 81 90 (U7)

3)
Входящий Setup:
022886 COL 018:06 06 St:co idle (00) EVT 5 27 05 04 03 80 90 A3 18 03 A1 83 86 6C 0F 21 80 2B 33 38 30 39 36 32 30 31 33 30 32 31 70 08 C1 34 35 35 39 39 35 35 A1 (U0)
………….
А через 2 сек приходит Disconnect от Астериска:
022901 COL 018:06 06 St:hnt-queued(00) EVT E 05 45 08 02 81 90 (U7)

Доброго времени суток...

Всех с прошедшими праздниками ( и с наступающими , у кого ещё остались )...
По поводу предыдущих траблов, выяснилась интересная штука.....Трейс с астериска показывает
так-же, что алерт проходит ( только конект он почему-то не показывает ), но вызова нет...В СМДР атс НЕ фиксирует эти звонки ( хотя включён print lost call, и аон в 200 пгм ).....Если я для сравнения выложу 2 трейса с атс и сервера, это как-то поможет прояснить ситуацию?????

Спасибо.......

Вообще-то "АОН в ПГМ200" ("CLI Print") не имеет отношения к SMDR.
CLI Print - это отдельная задача, при этом выдаются другие записи, в своем формате (не в формате SMDR).

Ну, а Disconnect, который выдает Asterisk, Вы видите при его трассировке??

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


по поводу CLI Print я понимаю......я вкл её потому-что аон попадает в гипер терминал ещё до поступления звонка, соответственно хотел просто проверить видит ли атс эти потерянные звонки....

Доброго времени суток....
Удивительное рядом, но мы обнаружили странную фичу.......СМДР атс всё таки сыпет....
3342 *620 027 00:00:00 12/01/10 17:34 G0506557481
3343 *620 028 00:00:00 12/01/10 17:34 G0675017011
3344 *620 029 00:00:00 12/01/10 17:34 G0672333466

или вот
3337 *620 023 00:00:00 12/01/10 17:34 G0637209491
025 : 0637209491
3338 *620 024 00:00:00 12/01/10 17:34 G0955983418
026 : 0955983418
3323 702 040 00:00:25 12/01/10 17:34 I0503596843
025 : 06372094027 : 0506557481
028 : 0675017011
029 : 0672333466
3342 *620 027 00:00:00 12/01/10 17:34 G0506557481

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

А что удивительного???
Если у Вас включен Lost Call Print, то потерянные вызовы будут также попадать в отчет SMDR.
G - это как раз и означает, что вызов был разъединен в момент ожидания обслуживания в группе, т.е. вызывающий абонент отбил линию не дожидаясь ответа (пришел Disconnect от Asterisk'a). То ли сам пользователь отбил линию, то ли ваш "сервер" - для станции это одно и то же.

Мне непонятно, что Вы так упираете на наличие Alert??? Ну отдала станция Alert, поскольку направила вызов в группу. Ну и что??
Если у Вас шквал звонков направлен в RING-группу, то здесь вообще невозможно будет разобраться, что происходит!!
Я уже Вам про это писал....

ну должен быть хотя-бы какой-то выход.....

Ну, какого выхода Вы ожидаете, если и сейчас неясно, кто именно виноват: LDK или Asterisk.
По трассировкам я видел, что вызовы отбиваются на стороне Asterisk'а.
Поменять тип группы с Ring на UCD (хотя временно, для проверки) - ваш заказчик не желает...