Комментарии 28
Вот бы мне такую статью в 2007м.
Целая книжка была https://www.oreilly.com/library/view/asterisk-the-future/059600
А зачем все это настраивать , если есть FreePBX?
Про NAT написана полная чушь. Большинство встроенных в роутеры NAT это Symmetric NAT который открывает канал в ОБЕ стороны и поэтому если послать на исходный адрес и порт, то пакет дойдет до адресата с внутренним адресом и все будет работать. Именно поэтому в 99% случаев SIP работает нормально через NAT без каких либо настроек. Единственный нюанс - что некоторые раутеры пропускают пакеты обратно только с того адреса и порта на который отправили, а некоторые со всех.
Большинство встроенных в роутеры NAT это Symmetric NAT который открывает канал в ОБЕ стороны и поэтому если послать на исходный адрес и порт, то пакет дойдет до адресата с внутренним адресом и все будет работать.
Что вы несёте?..
Большинство NAT - это Port Restricted Cone NAT.
А доступность SIP-устройств для входящих вызовов обеспечивается одним из следующих механизмов:
а) Банальный Keep-Alive - частая(10-30 сек) отправка "пустых(\r\n)" или SIP-пакетов типа OPTIONS или NOTIFY SIP-клиентом на SIP-сервер.
(Почти) схожий эффект может достигаться очень частой(каждые 60 секунд) перерегистрацией SIP-клиента, но на очень агрессивных CG-NAT(Carrier-grade NAT) это вряд ли прокатит. Это не может являться заменой KA и в целом порочная/не эффективная практика(тем более для "стационарных" SIP-клиентов).
Обязательно для транспорта UDP. Менее критично(при условии нахождения НЕ за CG-NAT) для TCP(и соответственно TLS/WSS). Для TCP может использовать(как со стороны клиента, так и сервера) нативный TCP Keep-Alive механизм, но тут многое зависит от связки сервер <> NAT <> клиент.
б) Алгоритмы SIP-ALG(названия могут варьировать или быть просто в виде отдельной группы спец-правил), которые при детектировании SIP-взаимодействия через маршрутизатор, динамически создают правило для поддержания открытого состояния выделенного на уровне NAT порта, даже если со стороны клиента нет KA и используется UDP в качестве транспорта для SIP.
Так как никакого стандарта(насколько я знаю) не существует на реализацию SIP-ALG, все характеристики его работы произвольны и весьма часто такие решения нестабильны/функционируют некорректно, что нередко создаёт проблемы в работе тех АТС/серверных решений, которые могут без перезаписи значений(IP:Port) в SIP-заголовках клиентом(используя STUN) или маршрутизатором(SIP-ALG) корректно определять контакт(IP:Port) для сигнального(SIP) и медиа(RTP) трафика.
Очень часто SIP-ALG - это чёрный ящик, поэтому если есть иные средства для организации корректного взаимодействия между сервером и клиентом - следует отказаться от SIP-ALG.
Это вывод из многолетней личной практики(не операторского, конечно, уровня, но коммерческой эксплуатации).
в) Использование Stateful протокола транспортного уровня(т.е. TCP). Но как уже упомянуло в пункте а), домашние провайдеры со своим CG-NAT плевать хотели на это, и могут также агрессивно выпилить вашу TCP-сессию через 30 секунд простоя.
Поэтому если вы полностью не контролирует весь маршрут внутри сети до выходной точки в Интернет, то полагаться на это невозможно.
Поэтому лишь Keep-Alive может обеспечить достаточную надёжность "обратного канала" для обычных потребителей.
Вы статью читали или вы писатель, а не читатель? Причем тут регистрации SIP если В СТАТЬЕ разговор про NAT идет ТОЛЬКО в контексте передачи звука и односторонней слышимости, поэтому все ваши много букв совсем не в тему. Так вот откройте статью, прочитайте "Проблемы с NAT" и спросите себя зачем вы писали этот пост и как он относится к статье.
При том, что это равноценный элемент проблемы с NAT в работе SIP, как и проблема с (не)прохождением RTP, а также как иллюстрация к тому, почему устройства работают находясь за Port Restricted Cone NAT.
А вы так и не ответили, где это вы Symmetric NAT нашли на "большинстве встроенных в роутеры NAT" ; )
Вы лучше копируйте wiki дальше без своих комментариев, а то " лишь Keep-Alive может обеспечить достаточную надёжность" уже звучит как глупость, потому что максимум что может сделать Keep-Alive - это поддерживать канал открытым и НИКАК не влияет на его надежность. И вы так и не ответили каким образом "Использование Stateful протокола транспортного уровня(т.е. TCP) " относится к прохождению звука или для тролля главное это начать придиратся к комментариям не читаю статью и выдергивая его из контекста? Для особо тугих объясняю - суть поста была в том что описанный в статье сценарий совершенно неверный и не работает на борльшинстве раутеров независимо от того как его назвать. Если же вы согласны с автором и готовы поспорить что его сценарий это реальная проблема на большенстве раутеров, то жду ваших аргументов по делу.
для тролля главное это начать придиратся к комментариям
Т.е. как раз то, чем вы сейчас занимаетесь - пытаетесь найти в моём тексте какие-то "ошибки/нестыковки", отводя внимание от исходной претензии к вашему высказыванию по поводу Symmetric NAT.
Классика демагога : )
Вы лучше копируйте wiki
Вы лучше читайте о чём речь, а то я вижу наличие ссылок на wiki триггерит у вас "он всё из wiki натаскал", что весьма потешно выглядит.
Ссылки на wiki даны для тех, кто не знаком с обозначенными механизмами и кому будет интересно об этом почитать.
И под "достаточной надёжностью" подразумевается стабильность работы канала связи между SIP-сервером и SIP-клиентом через агрессивный провайдерский NAT.
Но вы в этом усмотрели лишь возможность для контратаки в мою сторону )
И вы так и не ответили
Так вы этот вопрос выше и не задавали.
Для RTP не применимо. Пример был приведён для сигнального(SIP) трафика в контексте режима работы NAT, который я оспорил в первом сообщении, и комментировать который вы так упорно избегаете.
на борльшинстве раутеров независимо от того как его назвать.
Т.е. вы уже и не настаиваете, что "на большинстве" именно Symmetric NAT ? ; )
описанный в статье сценарий совершенно неверный и не работает
Приведёте пример почему он не верный и почему не будет работать?
А то пока складывается впечатление, что "я видел что оно и так работает, а вы тут все дураки", что довольно слабый аргумент.
Т.е. по делу о статье в комментариях к статье сказать нечего, досвидания. Спорить о том какой тип NAT считается самым массовым в отсутствии статистики считаю бессмысленным,т.к. в контексте статьи ВСЕ указанные ведут себя именно так как я описал независимо от названия.
P.S.
Приведёте пример почему он не верный и почему не будет работать?
А то пока складывается впечатление, что "я видел что оно и так работает, а вы тут все дураки", что довольно слабый аргумент.
Потому что у меня 25 летний опыт разработки VoIP(H323/SIP) софт свитчей, VoIP оборудования, системы СОРМ для операторов VoIP, участие в open source VoIP проектах и за все это время я не видел ни одного случая когда такой сценарий работал, но видел тысячи случаев наоборот. Кроме того, в указанной вами статье на wiki описано 4 типа NAT и описание ВСЕХ подтверждает мою точку зрения, а не автора статьи. При этом я допускаю что есть какие то ооочень редкие не стандартные типы NAT в которых вариант из статьи возможен.
Спорить о том какой тип NAT считается самым массовым в отсутствии статистики считаю бессмысленным
Но только зачем-то сами это изначально и утверждали, но да ладно.
за все это время я не видел ни одного случая когда такой сценарий работал
Что не работает?
1:1 маппинг для для клиентского устройства?
Закрепление диапазона портов за каждый из клиентских устройств(при условии, что NAT сохраняет номер src порта при трансляции и противоположенная сторона использует IP не из SDP, а src IP из SIP-пакета инициатор вызова)?
Даже SIP-ALG может работать нормально в отдельно взятом случае(если не используется TLS/WSS).
Методы упомянутые в статье вполне рабочие, но важные детали, при которых это будет работать, опущены.
Проблемы работы через NAT довольно поверхностно описаны в статье, это факт.
Из-за этого последнее утверждение, описывающее проблему пропуска RTP от Алисы, в одних условиях будет верным(если NAT по умолчанию рандомизирует порты при трансляции, либо если данный порт уже используется другим устройством), а в других не верным(NAT сохраняет исходный номер src порта и смог это сделать - порт ещё не используется другим устройством).
Это вопрос конкретных условий, в которых работает АТС и её абоненты, а не Silver Bullet решения.
Помимо NAT'ов сильно разнятся возможности как клиентских устройств, так и самой АТС относительно решения проблем работы через NAT.
Если RTP проксируется АТС(что необходимо для записи разговоров), и АТС имеет механизм определения источника RTP-потока на объявленный с её стороны IP:Port - проблема решается малой кровью, без необходимости задействовать STUN или SIP-ALG на клиентской стороне(или иных настроек на маршрутизаторе).
Что не работает?
Вниматнельнее надо читать статью и комментарии, тогда и не будет таких глупых вопросов. Вот что не работает:
наш маршрутизатор всё равно будет блокировать весь её аудиотрафик! Когда он получает UDP-пакет из аудиопотока Алисы, NAT-соединение с хранением состояния, соответствующее внутреннему клиенту, отсутствует, поэтому пакет отклоняется. Увы!
И вот суть моего ответа:
NAT ..открывает канал в ОБЕ стороны и поэтому если послать на исходный адрес и порт, то пакет дойдет до адресата с внутренним адресом и все будет работать...единственный нюанс - что некоторые раутеры пропускают пакеты обратно только с того адреса и порта на который отправили, а некоторые со всех
Как называется NAT вообще не играет ни какой роли в контексте утверждения/ответа потому что ВСЕ основные типы NAT так делают. Обсуждение решений НЕ СУЩЕСТВУЮЩЕЙ (в рамках описанного) проблемы в статье бесполезно, а про проблемы сигнального траффика через NAT в статье вообще нет ни одного слова.
Вниматнельнее надо читать статью и комментарии, тогда и не будет таких глупых вопросов.
Пока вижу лишь унылые нападки в ответ, а не рассказ "как надо" с детальным описанием механик работы той или иной схемы )
Вот что не работает
NAT-соединение с хранением состояния, соответствующее внутреннему клиенту, отсутствует
Вполне себе возможная ситуация по нескольким причинам:
NAT рандомизирует номер src порта или этот же номер уже используется другим устройством(т.е. гарантировать что это будет работать в сети со множеством устройств, прямо скажем сложно). Уже упоминал это выше.
Если в качестве Алисы выступает не конечный абонент, а АТС и вызов в состоянии Session Progress (проигрывается приветствие без интерактивного IVR) - RTP-поток будет только в одну сторону, и в таком случае он гарантировано не пройдёт NAT до момента коммутации, когда активируется ответный RTP-поток.
Как называется NAT вообще не играет ни какой роли в контексте утверждения/ответа потому что ВСЕ основные типы NAT так делают.
Опять же, только при условии что:
NAT НЕ рандомизирует номер src порта или этот же номер уже НЕ используется другим устройством.
Гарантировать что у произвольного абонента и то, и другое не встретиться - нереально.
Второй абонент сам не находиться за NAT.
В этом случае проблема значительно усугубляется для обоих сторон.
Без активных механизмов определения источника RTP-потока абонентов на стороне АТС, или ухищрений в виде SIP-ALG или доп.настроек на уровне маршрутизатора каждого из абонентов - магии не случится.
Потому, что это актуально было лет 15 назад.
Расскажу вам свой опыт.
FreePBX он же Асреиск только с вебоболочкой. Бесплатен.
В DHCP делаем параметр: 135 Yealink с номером103. Это VLAN 103. Yealink когда его видит соазу прыгает в этот VLAN 103. А там наша любимая опция. Параметр 66. Это путь FTP по которому лежит конфиг.
Почему так. Да потому что 66 параметр можно прописать трлько один. И если он занят Yealink , то Циску уже не вбить. И WDS тоже это PXE BOOT.
А так телефон улетает в свой ВЛАН где и получает параметр.
Файл телефона это его выгруженный конфиг где имя MAK адрес.
Телефон идет по FTP грузит конфиг применяет и все. Он в сети. Автоматика.
Я просто беру шаблон.
Вбиваю логин пасс, название phone-2333, файл называю МАК Телефона. Кладу в FTP папочку, перегружаю аппарат.
Удобно когда телефон ловит редкий глюк. Пользователю говорю ОК зажать на 20 сек. Телефон слетает до заводских. Автоматом у него 135 параметр включен. Он сам ловит конфиг и глюк исчезает. Было пару раз.
Атс работает как часы уже 4 года.
Для того чтобы в CDC отчетах имена были на русском. Просто снесите коиент mysql и поставьте ANSI Client mysql . В сети есть инструкция.
Воткну свои пару копеек:
BLF лучше указать так, что бы любой контакт одного номера получал состояние всего номера:
exten => _XXXX,hint,PJSIP/${EXTEN}&Custom:${EXTEN}
а в очереди использовать, например, так:
member => Local/6001@from-home/n,1,,PJSIP/6001,
и что бы всё это работало:
exten => _60xx,1,NoOp()
same => n,Dial(${PJSIP_DIAL_CONTACTS(${EXTEN})},60,T)
same => n,Hangup()
Это позволит корретно использовать множественные регистрации одного номера на разных устройствах без конфликтов.
В наше время более актуальна будет настройка Астерикса с сип клиентами на смартфонах, без выхода в общую сеть. Есть у кого-нибудь такая инструкция?
Похоже, пора снова вытаскивать комп с настроенным 10 лет назад FreePBX и вспоминать, как я там все настраивал. В офисе работало сносно, с парком шлюзов, пока не встал затык с записью разговоров и интеграцией с crm..
Для кого эта статья?
Для новичков описание консольной настройки неприемлемо, есть GUI.
Для профессионалов статья пустая (ни о чем).
Я вот после всяких проблем с интернет-связью тоже решил поднять дома АТС, выбрал MikoPBX, поднял, работает, даже видеосвязь есть, но видимо невозможно организовать нормальную работу софтфона, чтобы на него дозвониться можно было, как например на платный 3сх. Внимание вопрос: какие есть варианты АТС со своей приложухой и нормальными пушами? Можно платное, но не сильно 😀
Для мобильного устройства определённо стоит использовать транспорт TCP. Радиопередатчики смартфонов крайне эффективно справляются с поддержанием открытого TCP-соединения, а TCP будет стабильно доставлять пакеты SIP даже при плохом сигнале сотовой сети.
Это потому что TCP по сути терминируется на БС (ну если точнее, то в коре) и дальше идет уже GTP, который модемом опять превращается в TCP. Поэтому плохая связь не приводит к ретрансмитам TCP пакетов, они повторяются на уровне радио, пока не будут доставлены, а для пользовательского уровня выглядит как просто задержка пакетов.
del
Создаём личную систему VoIP