Элтекс

Здравствуйте, товарищи Элтексы!
Публикую отчет о тестировании шлюза TAU.72 с прошивкой 2236 (последняя доступная). Поехали.

1. Режим Authentication раздела SIP configuration. Не работает режим global. В документации написано:

global - выполнять аутентификацию на SIP сервере с общим именем и паролем для всех абонентов

Однако, при регистрации шлюз все равно использует в поле from номер телефона. Пример SIP запроса на регистрацию:

<--- SIP read from UDP:10.0.10.11:5060 --->
REGISTER sip:192.168.10.43 SIP/2.0
Via: SIP/2.0/UDP 10.0.10.11;rport;branch=z9hG4bKHp1Kr10vtUZ2N
Max-Forwards: 70
From: <sip:63001@192.168.10.43>;tag=Hcm2KH46er6eD
To: <sip:63001@192.168.10.43>
Call-ID: 6e79581d-095d-122f-88a5-a8f94b01aa0b
CSeq: 13263579 REGISTER
Contact: <sip:63001@10.0.10.11>
Expires: 15
User-Agent: TAU-72 build 2236 sofia-sip/1.12.10
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, INFO
Supported: timer, 100rel, replaces, path
Content-Length: 0

Странно, потому что в логах ТАУ вижу такую запись:

un 4 14:12:59 10.0.10.11 tau72: [app:info]create reg handle for endpoint 0, auth: tau72-mayak/dkir75ifedsi03n, wat(0), timer on 1000
Jun 4 14:12:59 10.0.10.11 tau72: [sip]nua(0x3d8500): sent signal r_destroy
Jun 4 14:12:59 10.0.10.11 tau72: [app:info]create reg handle for endpoint 17, auth: tau72-mayak/dkir75ifedsi03n, wat(0), timer on 2700

tau72-mayak / dkir75ifedsi03n - это username и password, указанные в секции Authentication под полем global, и сконфигурировано два порта - 0 и 17. В настройках портов указан только Phone, флаг Custom выключен.


2. При сбое в регистрации на обоих прокси серверах что в режиме Homing, что в Parking не происходит перерегистрации. Лечится ребутом шлюза. В логах:

Jun 4 14:13:00 10.0.10.11 tau72: [sip]nta: received 404 Not found for REGISTER (13262326)
Jun 4 14:13:00 10.0.10.11 tau72: [sip]nta: 404 Not found is going to a transaction
Jun 4 14:13:00 10.0.10.11 tau72: [sip]nta_outgoing: RTT is 64.388 ms
Jun 4 14:13:00 10.0.10.11 tau72: [sip]tport_release(0x3c8600): 0x412600 by 0x415a00 with 0x463600
Jun 4 14:13:00 10.0.10.11 tau72: [sip]nua(0x3c9600): removing register usage
Jun 4 14:13:00 10.0.10.11 tau72: [app:info]SIP: got nua_r_register : 404(Not found)
Jun 4 14:13:00 10.0.10.11 tau72: [app:info]sip: endpoint 0: REGISTER: 404 Not found

Смущает строка removing register usage - типа, досвидос, больше не буду пытаться регаться. И по-хорошему, должен задаваться параметр - Re-registration timeout, указывающий, через какой период попробовать перерегистрацию. Для homing - чтобы вернуться на основной SIP сервер, для Parking - просто чтобы зарегаться на предыдущем, но остаться на втором.

3. Нет ограничения на входящий звонок . Шлюз принимает звонки с любого SIP клиента. Представим себе кулхацера, который издевается безнаказанными звонками на абонентов ТАУ. Мне кажется, должно быть так:
- при использовании прокси сервера, принимать звонки только от прокси сервера;
- при выключенном прокси, принимать звонки с учетом списков ACL Incoming call restrictions.

4. Где iptables? Где tcpdump? . Издевательство просто. В шлюзе линукс, а утилит типа iptables и tcpdump - нет. Как без них жить в этом небезопасном и сложном мире??

Спасибо, жду Вашим комментариев.

Тихий субботний вечер, продолжаю ковырять шлюз....

Очень большая часть пользователей ТАУ.72 используют Asterisk. В SIP протоколе Asterisk есть свои особенности, а именно по части авторизации SIP пиров.
- http://www.voip-info.org/wiki/view/Aste ... P+channels
- http://www.voip-info.org/wiki/view/Aste ... er+vs+peer
Проблема при регистрации ТАУ72 на Asterisk возникает всегда, когда в поле from - номер порта, в в поле Digest username - то, что прописано в global authentication. И астериск ругается примерно так:

[Jun 4 16:23:43] WARNING[8672]: chan_sip.c:12999 check_auth: username mismatch, have <63001>, digest has <tau72-mayak>
Registration from '<sip:63001@192.168.10.43>' failed for '10.0.10.11' - Username/auth name mismatch

Как я ни крутил Asterisk, менял версии с 1.6 до 1.8, ничего не помогло. Не может в Asterisk отличаться username от auth username. Можно долго спорить о стандартах SIP протокола, но у меня вопрос: зачем при включенном global auth регистрировать каждый отдельный порт, как происходит сейчас? Регистрация должна быть один раз, с username/password как в секции global. Далее все INVITE идут с этим username/password, и меняется только callerid number, равный порту. Логично?

Здравствуйте!
1. По-моему Вы немного перепутали регистрацию и аутентификацию.
в режиме global и user def. регистрация происходит аналогично, отличаются процедура аутентификации
"global – выполнять аутентификацию на SIP-сервере с общим именем и паролем для всех абонентов; user defined – выполнять аутентификацию на SIP-сервере с раздельным именем и паролем для каждого абонента, имя и пароль назначаются портам в настройках меню Ports conf"

2. Что значит сбой регистрации?
переход на резервный sip proxy происходит при отказе/недоступности основного, а по всей видимости у Вас сервер доступен..
или я не так понял?

3. В следующий релиз постараемся внести функцию inbound, чтобы принимал вызовы только с sip proxy
ну и как правило защиту шлюза организовывают на свичах/коммутаторах на которых построена сеть.

4. tcpdump есть на шлюзе, так же можно switch на ТАУ заставить работать в режиме disable learning (hub mode), и подключить к свободному порту ТАУ ПК, с запущенным снифером и смотреть лог.
iptables так же постараемся внести в следующий релиз.
конфигурирование iptables через консоль достаточно будет?

5.

зачем при включенном global auth регистрировать каждый отдельный порт, как происходит сейчас? Регистрация должна быть один раз, с username/password как в секции global. Далее все INVITE идут с этим username/password, и меняется только callerid number, равный порту. Логично?

если регистрация должна быть один раз, какие номера должны быть в полях from и to в сообщении register?
как модет быть регистрация с username/password? может быть речь идет об аутентификации?
пока как то не логично..

Здравствуйте, Женя.
Отвечаю по пунктам.

1. По поводу global. Фича работает, как задумано Вашими разработчиками, но для Asterisk'a не подходит. Я еще буду обсуждать эту тему на asterisk-support.ru.

2. Сбой регистрации значит невозможность зарегистрироваться ни на одном из серверов. У меня в такой ситуации шлюз перестает делать попытки регистрации вообще. При этом невозможность регистрации означает не timeout подключения, а получение от SIP прокси запрета на регистрацию. Представим себе ситуацию, есть два SIP сервера, управляемые централизованно, и работающие с одним биллингом. Случайно в биллинге эккаунт заблокировали, шлюз от обоих серверов получил Not found или Forbidden, и все, больше не полезет. Если хотите, я это еще раз тщательно протестирую.

3. > ну и как правило защиту шлюза организовывают на свичах/коммутаторах на которых построена сеть.
Женя, а если шлюз в чужой сети? У меня как раз такая ситуация - торговый центр, сеть не моя, я только связь даю. MUST HAVE ограничения на примем только от SIP прокси (если он используется).

4. tcpdump - точно, есть, сорри. iptables добавьте плз. Кроме консоли ничего не нужно.

5.

если регистрация должна быть один раз, какие номера должны быть в полях from и to в сообщении register?
как модет быть регистрация с username/password? может быть речь идет об аутентификации?

Насколько я понял, при включенном режиме global шлюз регистрирует каждый порт, подставляя в поле From номер порта, а в digest md5 аутентификацию - глобальный юзер и пароль. Как я уже сказал, с Asterisk'ом такая схема не работает, он не умеет (не умел?) разделять username от auth username, посмотрю в новых версиях Asterisk'a. Сейчас подниму FreeSWITCH, попробую на нем сделать существующую логику шлюза. С точки зрения концепции SIP, наверное, логично регистрировать каждый порт с его номером. Это по SIP'овски Но нам, телефонистам, часто это совсем не нужно. Достаточно просто послать вызов на шлюз с указанием номера, мы знаем, что этот номер живет на этом шлюзе. Такие режимы реализованы в шлюзах quintum например, и во всех других. Они просто регистрируются 1 раз, с указанным user/pass, и далее просто используют эту учетную запись, меняя callerid number в зависимости от номера порта, и направляя в порт в зависимости от номера назначения.
У меня есть предложение - добавить в шлюз режим global (Asterisk compat) - совместимо с Asterisk, где будет работать как только что описал. Плюс маркетинговая тема - специально для Asterisk'a, совместимо.

Пошел ставить FreeSWITCH и осбуждать тему auth username на a-s.
Отпишу.

2 - Not found или Forbidden (403 или 404) не причина перерегистрировать на другом прокси.
перерегистрация происходит, например, в таких случаях:
503, 408. если сервер недоступен, либо по приему ICMP dest unreach..

3. iptables и inband устроит Вас?

5. так же в следующий релиз включим Registration Retry Interval, сейчас он по умолчанию 1 минута

Not found или Forbidden (403 или 404) не причина перерегистрировать на другом прокси.
перерегистрация происходит, например, в таких случаях:
503, 408. если сервер недоступен, либо по приему ICMP dest unreach..

Я так и понял, что нет перерегистрации. Но это неправильно. Я уже описал ситуацию - накосячил с конфигурированием учетной записи, выдал 404, и все - больше регистрации не будет до перезагрузки всего шлюза. Это разве нормально??

iptables устроит. Inbound call restriction by IP - в случае, если нет (не сконфигурирован) SIP прокси. Если есть SIP прокси - только от него.

litnimax писал(а):Я так и понял, что нет перерегистрации. Но это неправильно. Я уже описал ситуацию - накосячил с конфигурированием учетной записи, выдал 404, и все - больше регистрации не будет до перезагрузки всего шлюза. Это разве нормально??

конечно нет, сейчас Registration Retry Interval равен одной минуте, в следующим релизе сделаем его конфигурируемым.
на вашей версии, скорей всего, не перерегистрируется шлюз по получению 404, это недавно было поправлено

litnimax писал(а):iptables устроит. Inbound call restriction by IP - в случае, если нет (не сконфигурирован) SIP прокси. Если есть SIP прокси - только от него.

Inbound call restriction by IP зачем. если будет iptables?
будет просто Inbound, т.е. если есть сервер и стоит флаг, то вызовы только от сервера принимаются.