на сколько помню Redirecting работает при переадресации без каких-либо телодвижений абонента т.е. поставил переадресацию и смотришь на телефон

на сколько помню вот так
system -> oth.system -> External Signaling Parameters = Redirecting number used

Trunk Groups->Trunk Group->IE External Forward = Redirecting Number

IE External Forward ставить на тут TG которая смотрит в сторону Cisco, если поставить в сторону то не будет переаресация

есть такая штука redirect

действительно мой случай, отключил HLC и все стало в шоколаде
Спасибо

есть почти точно такая ситуация и похоже это тоже мой случай

Lync (sip) -> OXE (pri) -> pstn

при звонках с Lync на сотовые (к примеру 89175336699) не идет подключение голосового канала хотя по трассе с обоих сторон видно connect. если с Lync позвонить на тот же самый сотовый но только на федеральный номер (5336699) то проблем нет

причем это вылезло после апгрейда с 7.1 до 9.1, на 7.1 было все в шоколаде

WD еле-еле до 4-х лет дотягивают

запустите smartctl -X /dev/hda  (длинный тест), минут через 30-45 а лучше через 1 час глянуть результаты, если ничего не изменилось то прежние результаты актуальны

из практики - абсолютный рекордсмен 10 лет на cpu3s3 (до сих пор в работе), до этого было 8 лет на cpu3

вопрос из ряда философского где заканчивается грань правды, но лучше не ждать "подарка" и подумать об замене как сказал etc

из этого

а так результаты smartctrl нормальные

а так похоже что hdd крандец

все правильно, нужно smartctl -е /dev/hda чтобы включить , если не поддерживает то скажет "мол...извини братан..."

а затем уж smartctl -a /dev/hda чтоб посмотреть

из всей практики на 50% hdd smart не включен по дефолту

причин может много
1. крандец hdd, нужно глянуть через root статус smartctl -a /dev/hda
2. можно попробовать ребут атс, но сперва пункт 1

если пароль root сменили и забыли то можно вернуть по дефолту обратно

to Prost, на 4018 в режиме sip входящий номер показывает? или как с телефоном авайя в режиме sip когда надо допиливать астериск чтоб показывал входящий номер

чем дальше в лес, тем больше дров
прикольно получается - sip-телефон домой поставить "не левое", к атс прикрутить то "левое"

на ноде 1 все TG 1xx, на ноде 2 все TG 2XX, на ноде 3 все TG 3XX, это на тот случай если друг с ноды 1 кто-то захочет выходить в город через ноду 3. вот и все проблемы (TG удаленной ноды должна совпадать)

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

смотри внимательно network routing

причем тут количество абонентов??? все сводится к тому сколько активных сессий на каждый sip-id предоставляет пров (сессий может быть 1 а может 3 5 10 15 да хоть 30)

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

сомнительно и не факт что это прокатит для sip-транка. есть такая фича таким способом объединять две и более ОХЕ или не так?


вывод - те же яйца только в профиль с элементом геммороя - надо будет плодить TG (по количеству sip-номеров, а если у меня 100 таких номеров?) с топим SIP-ISDN (даже если mini-sip) и в этоге потом полезем cfgUpdate чтобы выровнять количество количество каналов на TG и естественно размер выделяемой памяти поднять. спрашивается - оно это надо? когда есть гуманный способ