SUrov_IBM

Похоже, у Вас «тяжёлый» случай взаимодействия с оператором. Менеджеры и монтажные войска, выполняющие заявку менеджеров, обычно работают по скрипту и мало что (к большому сожалению) понимают в собственной инфраструктуре. Скорей всего, в местечковом операторе есть пара-тройка специалистов и только они собственно занимаются сетью. К сожалению, без прямого выхода на таких людей сделать что-то нормально обычно не получается. В случае с Вашим оператором, наверное лучше руководствоваться принципом «Работает - не трожь!», а если прямой IP нужен для управления и мониторинга VPN клиента, то лучше самому разнюхать сниффером, что генерирует Zyxel и прозрачно заменить его Вашим VPN клиентом, не прибегая к взаимодействию с оператором. Есть шанс поломать и существующую схему, а потом героически её возвращать как было - за NAT. ;) P.S. Немного не по теме топика: Одно, конечно продолжает удивлять – «серость» операторов связи местечкового разлива, вроде Вы корпоративный клиент, оператор может даже отдельное волокно под IP TV выделить (значит на уровне проводов, что-то понимает), оператор освоил PON и не по лапше из VDSL предоставляет услуги, а прямой IP так и не научился подавать. Мол, наш главный дядя Петя, который в 200x году собрал ядро, придумал так, так и делаем для всех как он завещал. Пионер-нет в красивой обёртке ей-Богу. Для любителей компьютерных игр такой вариант приземления IP подходит, значит и корпоративщику с его какими-то VPN’ми должно подойти.

Grohotov, здравствуйте. Может попробовать на операторском Zyxel настроить DMZ, для конкретного IP, который получает Ваш pfSense? Если запариться, можно в разрез ONU и Zyxel поставить управляемый коммутатор, отзеркалить порт и попробовать посмотреть, с какими параметрами Zyxel взаимодействует с вышестоящим оборудованием, чтобы потом убрать его из схемы подключив pfSense вместо него? Правда я так понял, что Zyxel используется для IP TV и это важный для Вас сервис? Если совсем будет «засада», что оператора не поменять и существующую схему не перестроить, можно попробовать посмотреть в сторону другого типа VPN, например L2TP/IPSec (архитектура сервер-клиент), способный работать за NAT на клиентской части.

Уважаемые гуру, приветствую. Как всегда не обойтись без Вашего совета. Задача, на самом деле очень простая и скорей всего, я жёстко затупляю и не могу понять чего-то элементарного. На CISCO IOS, в сигнализации SIP поступает входящий вызов, содержащий в поле "To: <sip:буквенное_значение@" вместо цифрового. Естественно, я не могу указать такое значение в dial-peer voice voip, поскольку такое значение не корректно – "Incorrect format for E.164 Number". Собственно вопрос – каким образом, можно попробовать «приземлить» подобный вызов? Наверное, сработает incoming called-number T, я честно говоря не пробовал, но хотелось бы «приземлить» конкретное значение "To: <sip:буквенное_значение@". P.S. Заранее благодарю за любые мысли! Нужно будет собраться с силами и просветиться в направлении Matching Inbound Dial Peers by URI https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-inbnd-dp-match-uri.html Скорей всего там наведутся исчерпывающие ответы на мои вопрос. ;) Отвечу сам себе для заметки – чтобы принять входящий вызов по сигнализации SIP, отличающийся от "E.164 Number" (исключительно числовой формат) в рамках IOS, его нужно рассматривать как схему адресации SIP URI. Из описания: - Cisco IOS Versions 15.3 and earlier only support SIP profiles in the outbound direction. - After Cisco IOS Version 15.4, the SIP profile feature is introduced to modify inbound SIP messages as well. В общем, чтобы нормально обрабатывать SIP URI (например, изменять значения поля "To"), нужно, чтобы IOS поддерживал SIP profiles для входящих вызовов, а это возможно начиная с версии 15.4. В моём случае, для моего барахла CISCO 28xx, данная версия IOS слишком новая. Поэтому, задачу удалось разрешить только просьбой присылать входящие вызовы в формате "E.164 Number".

2. Проверить, что происходит с вызовами, на уровне SIP сигнализации: Для этого Вам потребуется найти управляемый коммутатор, чтобы поставить его в разрез IP линии между шлюзом и оператором. Далее, потребуется отзеркалировать порт коммутатора, к которому подключен шлюз (процедура зеркалирования описана многократно и выходит за рамки данного обсуждения), чтобы направить траффик на компьютер, подключённый к коммутатору. На компьютере, нужно будет запустить траффик-анализатор Wireshark, чтобы снять трассировку вызовов по протоколу SIP. Далее, выложить её на форум, чтобы форумчане могли проанализировав её и сделать выводы, чтобы дать подсказку что некорректно работает в момент вызова.   Но добрый Вам совет – Лучше, заставьте оператора разобраться со своим оборудованием, чтобы он решил проблему или вызовите специалиста, способного за отдельную плату сделать то, что я написал выше (надеюсь такие имеются в вашей местности), но специалист только сможет условно понять, в чём проблема, а не решить её без участия оператора.

OK, если у Вас такой говнистый оператор, что не хочет помочь в решении проблемы связанной с его же оборудованием, давайте подумаем вместе: Вот собственно Ваш шлюз - https://npotelecom.ru/catalog/voip-shlyuz-36fxs/ Подскажите, если с ТА (условно №1) подключенного к шлюзу, позвонить на ТА (условно №2) так же подключенному к этому шлюзу, вызов проходит? ТА №2 звонит? Вы снимаете трубку с ТА №2 и вызов обрывается? 1. Нужно исключить проблемы физики линий: Данный шлюз имеет FXS порты, предназначенные для вывода на плинт (пары). Нужно убедиться, что ТА №1 и №2 физически правильно с коммутированы на пары, согласно документации шлюза и что между этими парами нет замыкания (возможно на пары соседних линий, если используется многопарный кабель от плинтов до ТА). Лучше всего перенести и подключить ТА №1 и №2 напрямую к парам шлюза, исключив многопарный кабель из схемы, отключив две конкретные пары на плюнете от многопарного кабеля полностью и подключить к ним ТА, чтобы исключить меж-парное замыкание.

Хм…, глупый вопрос, а собственно входящий вызов от оператора поступает именно в таком формате +7343XXXXXXX (не путайте с АОН вызывающего абонента)? Если так, то попросите оператора отрезать «+7» и заново перенастройте АТС со своей стороны, возможна она о «+» спотыкается.

Просто очень сложно помочь разобраться в проблеме, не имея понимания, каким образом пытаются осуществляться проблемные вызовы и что за оборудование используется, кроме телепатических догадок, что используется "Элтекс TAU-36.IP" в качестве шлюза. И что за оператор такой, который предоставляет 28 абонентских линий, способный поставить не самый дешёвый VoIP шлюз и при этом совершенно отказывающийся разобраться в проблеме? Используется какая-то «серая» схема, что оператору нельзя предъявить ультиматум по данному вопросу или это закрытое учреждение, в котором отродясь не было специалистов, пришли какие-то люди, всё настроили и не проверив ушли?

Wainer, здравствуйте. Я не специалист по АТС Asterisk (возможно это и не Звёздочка, но похожа), судя по сообщению – поступивший вызов не может быть «приземлён» из-за того, что нет сопоставления с оконечным extension (абонентский телефон) или IVR. Грубо говоря, АТС не знает какое действие сделать с данным вызовом, перевести его на абонентский телефон или безусловную переадресацию или голосовое меню и т.п.

62Aleksandr, здравствуйте. Вы очень сумбурно объяснили схему включения. Были медные пары, к которым подключались 28 ТА (телефонных аппарата), потом эти пары обрезали и переключили в некий много-портовый VoIP шлюз. Грубо говоря, от FXS портов данного шлюза, подключены ТА. Это более-менее понятно, а вот с вызовами пожалуйста поподробнее. Между какими ТА обрываются вызовы? Между ТА подключёнными к портам шлюза и/или при вызове абонентов в городской тел. сети? Кто в этой схеме вызывающий (А) и вызываемый (Б) абоненты?   Так же очень желательно, чтобы Вы обозначили точную модель VoIP шлюза и что за ТА, у которых обрывается вызов используются (советские барашковые с диском или более менее новые).

Sol, пять лет назад, я бы «с руками» у Вас забрал бы такое оборудование и ещё бы гостинцев отправил из Петербурга в ответ, но мне физически стрелять «двойками» просто некуда, нет поблизости энтузиастов-телефонистов. Я свой Infinet Wi-Fi мост другу в Крым отдал, поскольку ему было нужнее, чем мне (перестроил IP канал через публичный Интернет, так проще). Как думаете, может Вы сможете сделать такой подарок автору темы, он насколько я понимаю радио-любитель и устройства не будут без дела лежать, поставит он их у себя, мультиплексирует 4 x G.703 с помощью Cisco и модулей VWIC2-2MFT-T1/E1 или G.703 например и получится у него ~ 6 Мб/Сек., что для радио вещания должно за глаза хватить. И на этих же Cisco организует динамическую маршрутизацию для резервирования с существующим Wi-Fi мостом! Главное, после этого принести жертву бону грозы и не забыть про громоотводы, подключенные не на батарею! ;) P.S. А в качестве спасибо от автора, подробный фотоотчёт-статья «Как я провёл лето» – т.е. как закалялась РЛЛ сталь, сопряжённая с Камасутра!

Sol, здравствуйте. Вы так смачно и в двух словах описали этот процесс, что мне аж самому релейку захотелось, не знаю правда зачем, наверное потому, что люблю технический секс, особенно со старыми железками. ;) А если по существу, я не понимаю, почему автор хочет именно РЛЛ? У него уже есть один Wi-Fi радио мост, который у него работает, но он бояться (и правильно делает), что он может выйти из строя, но при этом не могу понять, почему нельзя использовать VPN через Интернет для резервирования? Неужели это режимный объект типа "колонии", куда нельзя завести оператора, хотя бы домового класса?

Кстати, как вариант. Беглый поиск выдаёт PASOLINK IDU блоки по цене доступной практически любому любителю: https://chesnook.ru/index.php?route=product/product&product_id=5784 https://www.avito.ru/sankt-peterburg_pushkin/tovary_dlya_kompyutera/radioreleynoe_oborudovanie_nec_pasolink_mdp-150mb7_1909489811?slocation=621540 Правда ещё нужно поискать блоки ODU, источники питания 48 В и фидерные кабели. Что тоже потребует материальных вложений.

Dgf, здравствуйте. Возможно, данная функция, была изначально заложена в ПО много-портовых шлюзов (насколько я понимаю, функция чисто программная – создать определённые тоны), поскольку они могли использоваться в качестве аппаратуры формирования АЛ в жилых домах или на предприятии, при модернизации существующей инфраструктуры телефонной сети. Где вполне могли оставаться старые абонентские окончания с единственной функцией «Русский АОН» (бабушка удавиться, но не поменяет ТА, а будет писать жалобы во все инстанции) или уже современные (комбинированные «Русский АОН»/Caller ID), но по умолчанию настроенные на «Русский АОН» (офис с факсимильными машинами или DECT трубками, где сотрудники не в состоянии поменять режим, хоть убей, пока сам не придёшь и не сделаешь) для совместимости. А уже потом, данная программная функция, могла быть реализована и в более младшем семействе шлюзов, по просьбам трудящихся, хотя изначально этого и не планировалось, но не составило серьёзных телодвижений или затрат. ;)

Уважаемые господа, благодарю за помощь в ращении моей задачи! Собственно имеется шлюз Eltex TAU-1M.IP, обновлён до последнего на данный момент ПО: 2.3.1.11. Значение "Caller ID Generation" установлено в "Rus AON" – при вызове, абонентским окончанием (факсимильная машина Panasonic KX-FT982, переведена в режим «АОН») успешно обработан «безынтервальный пакет» с номером вызывающего абонента и его последующее отображение на дисплее. Ожидаю ТА «РУСЬ 17» с функцией АОН, ради которого собственно и затеивалась данная схема. Буду надеется, что «безынтервальный пакет» посылаемый TAU-1M.IP, ТА «РУСЬ 17» воспримет без дополнительных корректировок таймеров времени в микропрограмме. Собственно, успешно получилось обработать «безынтервальный пакет» на стареньком ТА «РУСЬ-13с». P.S. Ещё раз, благодарю всех профессионалов за участие и помощь в моём вопросе!

Без должных грозозащитных мероприятий, качественного (не на батарею, водопровод (что самый плохой вариант) и не крышу, лифт, мусоропровод и т.п.) заземления, защиты по AC питанию из строя выйдет любой радио-мост и не важно, будет он Wi-Fi и стоить как бытовая техника или это РЛЛ, стоимостью как автомобиль, разница лишь в том, что Wi-Fi радио мост, при выходе из строя Вы легко почините, купив ответную часть в любом компьютерном универмаге, а РЛЛ оставшийся с одной стороны в таком случае, просто снесёте на металлолом. Также, если например снегом, до состояния сугроб завалит РЛЛ с одной из сторон, эффект будет таким же как и у Ubiquiti. Исходя из этого, не вижу смысла, в Вашей задаче применять именно РЛЛ.   P.S. У операторов, при соблюдении всех нормативов, РЛЛ также выходят из строя при сильных грозах, там пытаются выходить из положения по принципу резервирования линий связи (радио, наземная, лазерная), по крайней мере для обеспечения связи на основных узлах.