forum.technoforward.ru

Здравствуйте.
АТС SL2100 v2.20. Не удаётся зарегистрировать SIP транк у провайдера. Инструкция и метод науч. тыка применены не раз. Во вложении два дампа Wireshark'a: успешная регистрация и звонки с софтфона и неуспешная с АТС.
Связаться с тех.службой провайдера пока не удаётся, пытаюсь "подогнать" сообщения NEC'a под успешные софтфона.
Опытным путём выяснено:
- 10-28-05 обязательно в 1 (Domain name), иначе после первого запроса Register получаем "480 Temporarily unavailable";
- при данном параметре 10-28-05>1 АТС генерирует запросы на регистрацию только при SIP Carier Choice - Carrier D (10-29-14). При всех других значениях ни одного запроса не генерируется. Уж не знаю насколько это правильно.

Сравнение обмена софтфона и АТС (на мой не сильно проф. взгляд) показывает:
- исходящий порт всех сообщений АТС – 5060, у софтфона – случайный;
- в полях from-to-contact у софтфона присутствует поле displayname (заполнен в настройках);
- строка "Via:", запросов от АТС, находится в самом конце сообщения и в ответном сообщении данной транзакции со стороны провайдера не добавляются строчки "received=10.8.0.158" и "rport=50594", говорящие о адресе отправителя с точки зрения провайдера. Тогда как в обмене с софтфоном данная строка на первом месте сообщения, как это привычно видеть.
Может ваш опытный взгляд разглядит ещё что-то неправильное-подозрительное?

Удалось связаться с техподдежкой провайдера. ID пользователя с @доменом требуется обязательно, заменить его на user@ip_адрес со своей стороны они не могут. Как уже было сказано ранее, при необходимом в данном случае 10-28-05>1 АТС генерирует запросы на регистрацию только при SIP Carier Choice - Carrier D (10-29-14).

Так же отметили:
- отсутствие в пакете авторизции некоторых полей в строке Authorization, по сравнению с софтфоном: CNonce Value, QOP, Nonce count;
- странное положение строки VIA и отсутствие её модификации со стороны сервера;
- отсутствие поля User-Agent.
Сказать определённо, что из различий фатально для регистрации провайдер не может.
Прошу вашей помощи в данной ситуации.

Рассуждаем-пробуем далее.
Регистрация неуспешна скорее всего из-за параметра 10-29-14 SIP Carrier Choice - Carrier D, который необычен своей схемой формирования SIP сообщения (отличия описаны выше).
Проблема в том, что при других "обычных" значениях этого параметра (Default-A-B..) И 10-28-05>Domain name АТС не формирует ни одного SIP пакета. Совсем.
Стратегию вижу следующую: меняем SIP Carrier Choice на, например "default" и пытаемся добиться от АТС попыток регистрации.

Закралась мысль о DNS. В сети провайдера (это внутр. серая сеть, приходящая к клиенту отдельным линком) DNS серверов нет.
На DNS сервере в LAN сети клиента завели фейковую А-запись, в 10-67 включил и прописал DNS в LAN сети (та же подсеть, что и LAN интерфейс АТС (10-01/02). Ситуация не изменилась.
В Wireshark'e появляются DNS запросы от АТС на разрешение SRV и A записей от имени VoIP интерфейса, DNS сервер же в LAN'e. Конечно же ответы не придут в АТС. Круг замкнулся.

Итого мои выводы: при включении 10-28-05>"Domain name" станция начинает работать полностью по DNS именам не только в формировании SIP URI , но и при обращении к Registar серверу, игнорируя поле с явно указанным ip адресом (10-29-06). Пытается обратиться по FQDN имени (10-29-11), но не разрешив это имя на DNS серверах не формирует SIP запросы. Естественно для разрешения этих имён нужен доступный в VoIP сети DNS сервер.
Но это не наш случай: провайдер требует URI вида user@FQDN, но DNS серверов в этой серой сети не имеет.
Тем не менее, при 10-29-14 SIP Carrier Choice > Carrier D АТС формирует таки SIP запросы без настроенного DNS (10-67), но регистрация не проходит по причинам... вероятно "особенностей" Carrier D.

Вопросы:
- как можно повлиять на такое поведение АТС? Чтоб и нужный SIP URI формировался и обращение к Registar шло по ip адресу? Неужели это так нестандартно? Ведь софтфон справляется на ура при тех же условиях.
- есть ли в АТС аналог файла hosts для локального разрешения FQDN в ip адрес без участия внеш. DNS?

Да, физ. схема подключения такая:
АТС - Mikrotik (функция коммутатора с зеркальным портом) - LAN коммутатор L2
- Mikrotik - линк провайдера
- Mikrotik - линк для зеркалирования на PC

С PC доступна как LAN сеть клиента, так и сеть провайдера (естественно, при смене ip настроек сетевого адаптера).


Продолжаю просить помощи.

Ответ в письме.

С помощью поддержки и дампов удалось разобраться в ситуации.
При параметре 10-28-05>Domain name весь SIP обмен АТС генеририрует с использованием доменных имён. Это касается как формирования SIP URI в SIP запросах (user@FQDN вместо user@ip_address), так и собственно обращениния к SIP серверам и прокси: используются параметры 10-29-11/12/13 и игнорируются 10-29-03/06.
Для меня это было неочевидно.
Соответственно, для разрешения FQDN имён нужен DNS сервер, который настраивается в 10-67 и работает именно для VoIP интерфейса: ДНС запросы будут исходить от АТС с dest. ip VOIP интерфейса. АТС сначала ищет SRV запись, затем A.
В данном случае сложились два фактора: требование провайдером регистрации по схеме user@domain и отсутствие в его внутр. сети (подключение организовано через прямой линк с серой сетью) DNS сервера.
Временно решили задачу, подняв статичную А-запись на Mikrotik'e у клиента в LAN сети.
Тему можно закрывать.
Спасибо.

PS в инструментарий был докуплен Mikrotik hAP lite (RB941). За полторы тысячи руб. компактная коробочка с помощью которой на месте у клиента можно: отзеркалировать трафик, поднять DNS, NAT и пр., что может сильно помочь в творческом поиске.