что ни есть обычным ухом
я же говорю что акустически не проходит

ОХЕ R9.1 (i1.605.37.a) кристалл

к SIP-транку подключен SAP BCM (Call-Center)
соединение с провом через PRI

проблема заключается в следующем - при звонках в PSTN с терминала SAP_BCM не передается dtmf тобишь если позвонил на дису но жми не жми клавишу цифр dtmf через pri не идет акустически

на терминале SAP_BCM в плане dtmf очень скудно, т.е. имеется только rfc2833 (что и включено)

в ОХЕ на ext-gateway который идет на SAP_BCM включена опция "INFO metod remote ext"

ниже лог где с терминала нажали цифру "1"

----------------------utf8-----------------------
INFO sip:172.16.1.3 SIP/2.0
Via: SIP/2.0/UDP 10.100.7.13:5060;branch=z9hG4bK-115O111001777
To: <sip:95257425@172.16.1.3>;tag=6af7aaf4e33b2358a55858dc48bc99c0
From: <sip:150@10.100.7.13:5060>;tag=O111001777
Call-ID: O111001777@10.100.7.13
User-Agent: SAP BCM SIP Bridge
CSeq: 115 INFO
Max-Forwards: 69
Supported: timer, replaces
Content-Type: application/dtmf-relay
Content-Length: 24

Signal=1
Duration=200
-------------------------------------------------

1349767665 -> 21 [CRequest::CRequest] Creation of a request (RECEIVED FROM NETWORK)
1349767665 -> [CIOCom::receiveRequest] Received CRequest 21 ref=1
1349767665 -> [CIOCom::checkHostInBlackList] host=10.100.7.13
1349767665 -> [CIOCom::checkHostInBlackList] host=10.100.7.13
1349767665 -> [CIOCom::receiveRequest] rport1 not empty
1349767665 -> [CDispatcher::onIncomingRequest()]
1349767665 -> [CDispatcher::processRequestFromManagerIndex()] start at index 0
1349767665 ->  102 [CCallManager::onIncomingRequest()]
1349767665 -> 1102 [CCall::receiveRequest] INFO
1349767665 -> 1102 [CCall::getDialog] Confirmed Dialog found
1349767665 -> 1505 [CDialog::receiveRequest]
1349767665 -> 1505 [CDialog::receiveBasicRequest]
1349767665 -> 2120 [CTransaction::changeState] STATE CHANGED TO INITIAL
1349767665 -> 2120 [CTransaction::changeState] notifying the parent dialog
1349767665 -> 1505 [CDialog::onTransactionState(pTrans = 2120, previousState = Terminated, currentState = Initial, reason = None]
1349767665 -> 2120 [CTransInitialState::receiveRequest] Transaction changes to Trying state
1349767665 -> 2120 [CTransaction::changeState] STATE CHANGED TO TRYING
1349767665 -> 2120 [CTransaction::changeState] notifying the parent dialog
1349767665 -> 1505 [CDialog::onTransactionState(pTrans = 2120, previousState = Initial, currentState = Trying, reason = Request reception]
1349767665 -> 1505 [CDialog::addTransaction] added transaction 2120 with branch z9hG4bK-115O111001777, with CSeq 115
1349767665 -> 1102 [CCall::checkAuthentication] INFO
1349767665 -> 1102[CMotorCall::controlAuthentication] ---*--- AUTH ---*--- Control authentication
1349767665 -> 1102[CMotorCall::controlAuthentication] ---*--- END ---*--- Control authentication
1349767665 ->    0[CMotorCall::onReceiveRequest] route already analyzed.
1349767665 -> 1102[CMotorCall::onReceiveRequest] request for gateway.
1349767665 -> 1102[CMotorCall::onReceiveRequest] state = COMPLETED_STATE.
1349767665 -> [CCompletedState::receiveInfoMessage] [138835600] [138835600]
1349767665 -> [CCompletedState::receiveInfoMessage] receive Methode INFO : application/dtmf-relay
1349767665 -> [CCompletedState::receiveInfoMessage]-->call->extGw=1
1349767665 -> [isValidGwExt] ext gw 1 is valid
1349767665 -> 1102[CMotorCall ISDN ExtGW
1349767665 -> [isValidGwExt] ext gw 1 is valid
1349767665 -> 1102[CMotorCall ISDN ExtGW
1349767665 -> 1102[CMotorCall::emitSuccessfulMessage]-->accept SIP INFO
1349767665 -> [isValidGwExt] ext gw 1 is valid
1349767665 -> 1102[CMotorCall::inviteBuildContact] Contact: sip:172.16.1.3
1349767665 -> 1102[CMotorCall::makeResponse] Reply directed to the last received request.
1349767665 -> 1102 [CCall::makeGenericResponse] 200
1349767665 -> 1102 [CCall::getDialog] Confirmed Dialog found
1349767665 -> 1505 [CDialog::createResponse] 200
1349767665 -> 2120 [CTransTryingState::createResponse] CResponse 24 ref=1
1349767665 -> 24 [CMessage::send] sip_sendMessage (10.100.7.13:5060)
1349767665 -> SEND MESSAGE TO NETWORK (10.100.7.13:5060 [UDP]) (BUFF LEN = 448)
----------------------utf8-----------------------
SIP/2.0 200 OK
Allow: INVITE, ACK, CANCEL, BYE, PRACK, NOTIFY, SUBSCRIBE, OPTIONS, UPDATE, INFO
Contact: sip:172.16.1.3
Supported: timer,100rel
User-Agent: OmniPCX Enterprise R9.1 i1.605.37.a
To: <sip:95257425@172.16.1.3>;tag=6af7aaf4e33b2358a55858dc48bc99c0
From: <sip:150@10.100.7.13:5060>;tag=O111001777
Call-ID: O111001777@10.100.7.13
CSeq: 115 INFO
Via: SIP/2.0/UDP 10.100.7.13:5060;branch=z9hG4bK-115O111001777
Content-Length: 0

-------------------------------------------------
1349767665 -> 2120 [CTransTryingState::createResponse] Final : Transaction changes to Completed state
1349767665 -> 2120 [CTransaction::changeState] STATE CHANGED TO COMPLETED
1349767665 -> 2120 [CTransaction::changeState] notifying the parent dialog
1349767665 -> 1505 [CDialog::onTransactionState(pTrans = 2120, previousState = Trying, currentState = Completed, reason = Final resp creation]
1349767665 -> 2120 [CTransaction::startTimer] Timer J is started (delay = 32000 ms)
1349767665 -> 1505 [CDialog::updateRouteSet] there are 0 record-route headers
1349767665 -> 1102[emitEventToMonitel] content size (lginfo): 656
1349767665 -> 1102[emitEventToMonitel] CAC = 0 eqtCAC = -1
1349767665 -> 1102[emitEventToMonitel] CAC = 0
1349767665 -> [sendLgEvtSip] Event sent on eqt : 1713 Id :-1
1349767665 -> [display_ipc_out] ------------ Begin ---------------
1349767665 -> Id : -1
1349767665 -> INFO
1349767665 ->   digit_nb=1, Duration : 200
1349767665 ->   Signal[0] : 1
1349767665 -> [display_ipc_out] ------------- End ----------------
1349767665 -> RECEIVE MESSAGE FROM NETWORK (10.100.7.13:5060 [UDP])
-------------------------------------------------

все правильно

процесс обмена команд должен быть таков

--> invite
<-- sip 100
<-- sip 180/183
<-- ack
--> sip 100

у вас
--> invite
<-- sip 100
<-- sip 180/183
<-- ack
и все

да и sip-телефон который звонит не хочет общаться по sdp180, а хочет по rel 100

из под root команда killall sipmotor
если не помогло то рестарт атс

знаю что есть и минуты отсчета
по параметру 193 вообще 1% остался


лично мое мнение что патч накатить то можно, но вот на долго ли отсрочим проблему на пару месяцев или пару дней

to nokiani, в сетях dns-shop время от времени появляются hdd 2,5" ide 160gb бренда WD. бери сразу 2 штуки
такие WD-шки 3 года отработают, но не больше

ru.wikipedia.org/wiki/S.M.A.R.T.
"точку" в конце не забываем дописать если не открылась ссылка

показатель ненормальный

столько hdd не живут

странно что показатель 0

hdd это не солнце, столько градусов не бывает


думаю что стоит запустить тест на long

дык пишет -e включить
smartctl -e /dev/hda

затем гляньте "smartctl -h" опцию запустить тест short/long, либо ждите полдня и снова "smartctl -a /dev/hda"

обычно всякого рода проблемы по сценарию "не было и в друг стало, и при рестарте на некоторое время пропадает" возникает при перед пенсионном возрасте hdd

покажите результаты команды из под root  -> smartctl -a /dev/hda

вот и безхозная плата EMTL нашла свое применение

есть такое в 9.1, накатывали патч i160533c для исправления времени, а так вроде текущий патч i160537a

есть ОХЕ версии 9.1 (i1.605.37a) MI

на борту есть платы INTIP2A и INTIP3A, назначение - общий котел (sip-транк да ip-абоненты)

долго не могли понять понять sip-транк время от времени падает т.е. заканчиваются с очень большой скоростью лицензии sip-транка и через не которое время лицензии sip-транк освобождаются можно сказать пачками от (5-10) на раз. "killall sipmotor"  помогал от 2х часов до нескольких дней. полный ребут атс довал точно такой же результат как и "killall sipmotor"

в процессе поднятия ip-биллинга на цисках засекли паразитный траффик (граффик от 6 тыс. до 10 тыс. пакетов в секунду ) между INTIP3A и атс samsung os7200.
в процессе разбирательства выяснилось что voip-плата от атс samsung os7200 вошла вступор и просто напросто спамила несколько портов rtp платы INTIP3A

os7200 ребутнули все проблема "как бабка наговорила"

вывод если есть проблемы sip-транком или intip3 падает, ищите паразитный траффик

из-за отдаленности атс пока все заглохло, "лунаход" отдыхает
как что-то проясниться отпишусь

есть большой камень в сторону французов по душу  sip-транк

есть ОХО с релизами 710/085.001 и 820/026.006, sip-транк выступает в роли объединения единого нумерационного плана и транзитных звонков для конкретного направления, а болезнь у обоих одна и таже (sip,транзит,disa)

subcriber (как internal плане) прописываем в приват плане. метим sip-транк приват, звонок на ОХО отбивается с  "sip cause 404 - not found", subcriber (как internal плане) прописываем в паблик плане (sip-транк по прежнему приват), о-о-о-о чудо звонок дошел до абонента ОХО через sip-транк.
далее метим sip-транк паблик, звонок до абонента доходит по "паблик плану". далее удаляем из "паблик плана" строку "subcriber" и входящий звонок падает на G.B.
тут естественно все транзитные звонки расписаны через паблик план, "это не есть гуд" если в нашем винегрете есть disa, делать что...менять бренд?!

to Артём, я частично разжевал твою проблему

другой вопрос - кто изъявит желание написать в support французам??? поведение sip-транка с метками паблик/приват не адекватное

после демонтажа voip8-2 в Hardware and Limits/ Main Cabinet  написано CPU4

CPU и CoCPU - в одной сетке и коммутаторе