Что-то как-то ... не разобрался так сходу. Не подскажите, как быстро сделать нужный дамп? Какие кнопки понажимать в программулине, и какие действия совершить?
Я так понял, что нужно совершить повторный звонок, при параллельной фиксации трафика этой программой? Какой? С 6 секундной задержкой или с 1-секундной? Или все равно?
Выбрал в программе соединение (свою сетевуху) она стала выводить на экран большое количество строчек с разными протоколами и пр..
Что с этим делать?
Никогда не пользовался подобной программой ((

Проверьте, не стоит ли VoIP Call Out Notification в Telephony Settings.
Если стоит попробуйте убрать.

Интересно чем закончится это снятие логов. И самое интересное — причем тут они.

Вообще, Е1 может сигнализировать о начале разговора. А внутренняя АТС вполне может делать при этом переполюсовку.
Что у вас в Advanced settings->line settings->Enable Polarity Reversal и PSTN Answer Detection.
Попробуйте с ним поэксперементировать. При экспериментах смотрите логи slmon, там будет виден момент переполюсовки.

А еще интересен вопрос, почему у вас набор занимает 6 секунд? ведь тоном должно быть быстрее, а пульс не вяжется с Е1.

Я всегда думал, что это уведомление абонента (возможно писк в трубке) при перенаправлении звонка по войпу. Я не прав?

Мне почему-то тоже так думалось:
VoIP Calling Notification: The gateway will play a tone to notify that the call is via VoIP.

В общем, ни изменение настройки VoIP Calling Notification: была включена, выключил - результат тот же.
Ни включение Enable Polarity Reversal - было выключено, включил.
НЕ помогло! (((

Логи еще могут помочь?)

Я ж говорю, попробуй пофапать PSTN Answer Detection.

Да нее, это я паузу ставил в 6 секунд, после получения ответа о соединении. Ну просто от балды, с запасом. Реально, при паузе 6 секунд, происходит примерно следующее: при наборе номера (возможно даже перед набором номера) Октелл получает сигнал о соединении и отсчитывает 6 секунд. За это время, секунды за 2-3, происходит набор номера, я слышу гудок, ответ абонента, первые пару слов голосового меню и только после этого происходит набор добавочного. То есть хватило бы и 4-х секунд, может и 3-х.
Но поставил с запасом, к тому же междугородние номера дольше набираются.

Про PSTN Answer Detection пропустил - извините. Ща попробую.

П.С. Хотя слово "пофапать" ни о чем не говорит))

Ставлю Enable Polarity Reversal - Enable

Ставлю PSTN Answer Detection, как Ring Tone - без разницы! Набирает добавочный через секунду (так сейчас настроил) после начала набобра номера (или конца набора номера, но еще ДО соединения. Только после этого гудок начинается. (Это видно по логам SLmon)

Ставлю PSTN Answer Detection, как Polarity Reversal - вообще не набирает добавочный! По-ходу так и не дожидается он этой переполюсовки на Е1...

Походу. Но в этом случае, то что вы хотите можно реализовать только задержкой, а то как у вас работало считать божьим даром. Как известно — бог дал, бог взял.

))) Что-то не похоже это на инженерное объяснение...

Задержкой-то конечно можно, но в том то и дело, что фик знает какую задержку ставить. Номера городские даже набираются с разной скоростью, например прямой быстрее, чем с кодом 499. На межгород у каждого отдела еще ставиться свой префикс из 5 цифр (для контроля междугородних разговоров по отделам) 5 цифр + 8-ка + 10 цифр номера = 16 цифр - еще дольше набирается. И это если через Е1, а если выход через МГТС, то вообще непредсказуемо.
Опять же, где-то трубка снимается сразу, без гудка, где-то после первого гудка, где-то после второго...
Отсюда либо ставить с запасом, тогда на прямых номерах можно прослушать все приветствие и часть меню и только потом переключение, либо усложнить сценарий и пытаться угадать примерное время до соединения.
А как было бы просто, если бы момент соединения определялся!

Ну, и кстати, момент соединения в SLmon не отображается каким-либо событием.

То есть, разбирая следующий лог:

14:17:05 [028460] 5: FXO=OFFERING
14:17:05 [028460] 5: Get CallerId=703
14:17:05 [028460] 5: Check Trunk FixLine
14:17:05 [028460] 5: Hunting Trunk Line
14:17:05 [028460] 3: Peer=192.168.100.246:5038, PT=8, RecvOnly=0
14:17:05 [028460] 3: TrunkPrefix=, Dest=95141990, Dialno=95141990
14:17:05 [028460] 3: FxoHookOff
14:17:05 [028460] 3: SetInputGain(-8)
14:17:05 [028460] 3: ==18:TrunkDialOut
14:17:06 [028471] 3: DialOut(95141990)=0
14:17:08 [028483] 3: Fxo DialOut OK
14:17:08 [028484] 5: FXO=ACCEPT
14:17:08 [028484] 3: ==13:VoipAnswering
14:17:08 [028485] 5: FXO=CONNECTED
14:17:08 [028485] 3: RtpApiTalk[1,1], Peer=192.168.100.246:5038, PT=8, FC=2, NewOOB=0
14:17:08 [028485] 3: ==14:Talking
14:17:09 [028498] 3: Play(2)
14:17:09 [028500] 3: Play(5)
14:17:10 [028503] 3: Play(4)
14:17:15 [028562] 5: FXO=DISCONNECT

Могу отметить, что:

в 14:17:08 после строк
14:17:08 [028484] 5: FXO=ACCEPT
14:17:08 [028484] 3: ==13:VoipAnswering

в трубке слышится какой-то хруст. Возможно это и есть переполюсовка? После него появляются строки:
14:17:08 [028485] 5: FXO=CONNECTED
14:17:08 [028485] 3: RtpApiTalk[1,1]
14:17:08 [028485] 3: ==14:Talking

судя по всему именно этот момент считается соединением, после чего, выждав паузу (задержку, которую я поставил), Октелл начинает набор добавочного 254:
14:17:09 [028498] 3: Play(2)
14:17:09 [028500] 3: Play(5)
14:17:10 [028503] 3: Play(4)

Реально же где-то в 11 секунд пошел гудок, в 12-13 секунд заговорило голосовое меню.
(В 15 секунд я положил трубку: 14:17:15 [028562] 5: FXO=DISCONNECT)

Описанные вами проблемы, несомненно, ужасны. Но такова особенность наших линий. Вы не можете однозначно определить момент ответа абонента. Это могут только линии для таксофонов — там у ГТС есть переполюсовка.
Если вы говорите, что работало, то нужно искать что сломалось. Но я не могу себе представить, как это работало. Нельзя определить момент ответа абонента без переполюсовки. Единственный вариант, что все-таки УАТС делала вам переполюсовку после посыла в линию номера. Тогда пауза в 1 секунду как раз приводила к тому, что на звонок успевали ответить, а время набора номера учитывалось УАТС.
Но судя по всему было не так.

Момент реверса полярности в слмон отображается однозначной записью (что-то вроде «Plarity revers»). Очевидно, у вас реверса не происходит.

Ладно, если больше нечего добавить, то СПАСИБО вам BDenis и Alexey Motkov за участие в данном вопросе и за ваши советы. Мы хотя бы попытались.