Примери за конфигуриране на рутери и защитни стени за правилна NAT функционалност в Asterisk
Всичко най-интересно в рубриката "Флудилка"
Кой е на сайта
Дискусия Joomla, Virtuemart 2, Cisco IOS, Asterisk, PHP
- Размер на шрифта: По-голям
- Преглеждания: 7368
- Коментари: 1
- Абонирайте се за актуализации
- Печат
- Споделя това
- Оплачете се за това съобщение
Проблемът с обръщането на NAT чрез медиен трафик е само едната страна на медала. Първо ще разгледаме какви препятствия създава NAT за сигнализиране на съобщения и какви SIP разширения са създадени, за да ги преодолеят.
Обхождане на SIP NAT
Вторият проблем е необходимостта от правилно маршрутизиране на входящите SIP заявки. SIP не предоставя механизъм, който би позволил да се изпращат нови заявки през същата връзка на транспортния слой, която е формирана по време на регистрацията на потребителя. Записите в таблицата за превод на NAT имат ограничен живот (за да не препълва и таблицата) и за да могат входящите SIP заявки да достигнат до UA зад NAT, записите в таблицата за превод на NAT трябва да се актуализират периодично. Това се отнася както за безсвързани, така и за ориентирани към свързване протоколи.
Фигура 1. Маршрутизиране на входящи заявки
Но записът в таблицата за превод на NAT се изтрива след определен период от време (най-често няколко минути). Проблемът е уместен не само в периода след регистрацията на потребителя: по време на SIP диалоговите прозорци новите съобщения може също да не се получават за дълъг период от време, което е достатъчно, за да може изтриването на записа от таблицата за преводи. Съществуващите SIP стекове решават този проблем, като периодично изпращат SIP заявки, ПРИКАНВАТ, ОПЦИИ, INFO, NOTIFY или (ако се използва UDP) дейтаграми, които не съдържат полезен товар.
По-пълна и усъвършенствана техника е описана в проекта Управление на инициирани от клиента връзки в SIP проекта на Internet Engineering Task Force (IETF) [2]. Нека се спрем на него по-подробно.
Когато регистрира потребител, регистраторът запазва данни за транспортната връзка, чрез която е получена заявката. Два специални параметъра instance-id и reg-id на заглавката Contact ви позволяват да намерите данни за връзката в базата данни на регистратора и да насочвате входящата заявка към UA през връзката на транспортния слой, през която е получена заявката за регистрация. Освен това проектът описва механизми за постоянно актуализиране на записите в таблицата за превод на NAT.
Нека обобщим това с малък пример за регистриране на потребител зад NAT и използване на UDP (вижте фигура 2).
Фигура 2. NAT Traversal чрез SIP сигнализиране
Искането REGISTER съдържа параметъра Via rport header, информиращ UAS за поддръжката на RFC 3581, както и параметрите reg-id и + sip.instance в заглавката Contact:
Отговорът на проксито изглежда така:
