asterisk.ru

Платный суппорт

Я подумал о решении и реализации NAT. Тут, указано несколько схем http://asterisk.ru/knowledgebase/Asteri ... +Solutions. Мне должна подойти последняя

Asterisk как SIP сервер на публичном адресе, клиент из-за NAT подключается к Asterisk

и решение для неё указано следующее:

решается в большинстве случаев с помощью nat=yes и qualify=xxx в sip.conf для клиента. Некоторые клиенты (X-lite) упрощают подключение с помощью встроенных функций STUN и посылки UDP пакетов keep-alive. Опция qualify же напротив, посылает пакеты keep-alive со стороны Asterisk клиенту за NAT.

Мне немного не понятна формулировка "для клиента". Т.е. параметр nat=yes должен установить у себя в настройках провайдер, для моей учётки? И тогда его Asterisk будет понимать что я за НАТом и будет слать мне пакеты, по уже установленному в процессе регистрации соединению. Ежели он этого не сделает (сделал) то он будет пытаться соединиться со мной, как будто я с ним в одной сети и НАТа между нами нет - отрпавляя мне голос в любом другом соединении, о котором мой НАТ не знает.

Проблема была на стороне провайдера. Говорят что-то в prerouting поправили.

tonny_bennet писал(а):Ночью провайдер что-то у себя обновил и пропал поток в одну сторону. Я у себя ничего не менял. Скорее всего проблема у провайдера,

Оно с самого начала было ясно. Как можно помочь им ковыряя и перестраивая у себя?

Мне тоже было почти-понятно, что проблема у них, но очень хотелось понять где именно и аргументированно показать где косяк, мол я не вижу, что от вас не приходит порт, или я шлю поток туда -то. Пока не столкнулся не знал, что делать и на что обращать внимание. С той стороны, как оказалось, тоже не сильно опытные сотрудники.

ded, возвращаясь к заметке о настройке NAT, мои предположения и рассуждения верны?

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

в таких случаях я беру ноут с софтфоном и врубаюсь прямо до NAT. Запускаю шарк и отправляю гневное письмо прову со скринами о кривости их рук и прочих детородных инструментов.

Это сложно реализуемо т.к. серверы от меня далеко и доступ к ним только через консоль/RDP/web-интерфейс. Попробую в RDP сессии запустить, но не факт получится проверить голосовой стык нормально.

Подобные отмазы говорят о дилетанстве и пожелании решать проблемы способом "авось пройдет".
Пров явно будет гнать на "глючный микротик". Итд и тп.. лопухами лечить беременность модно?)
А бедный клиент рвать волосы на всех местах..

Можно попросить временно открыть доступ до IP где Вы находитесь, на тест. И проверить всё.

Zavr2008 писал(а):в таких случаях я беру ноут с софтфоном и врубаюсь прямо до NAT. Запускаю шарк и отправляю гневное письмо прову со скринами о кривости их рук и прочих детородных инструментов.

Ваш уровень владения мат. частью, как мне кажется, многим выше чем у сотрудников провайдера и вы можете упрекать их кривости рук и прочих инструментов. Я могу их упрекать только в вопросах маршрутизации, адресации, шейпинга и прочих IP дел, в которых как мне кажется я неплохо разбираюсь. Ругать их за телефонию, мне пока страшно (страшно показаться невежей), ибо мой уровень знания мат. части не высок. Я и задал здесь вопрос, на что именно обратить внимание.

К слову сказать, сотрудник провайдера не отрицал присутствия проблемы с их стороны. Просто он параллельно чинил ещё десяток абонентов, у которых были те же проблемы. Причём какие-то решались, а какие-то нет. Его это ещё сильнее запутывало.

Настроив аппаратный IP телефон я получил ту же проблему, что у меня была с сервером, и провайдер всё также подтвердил и ушёл ковыряться в своих железяках. Он не гнал на мой глючный МТ.

Про возможность попросить открыть доступ с IP на котором я сидел конечно предполагал, но не каждый провайдер на это согласится. Пока не столкнёшься с нормальным админом/инженером, а не "девочкой ТП из ТП" результата не будет.