SIP

[at0m]

Всем привет посоветуйте что нить, нужен sip клиент + сервер под свой сервер (vds)
к клиенту особенности :
+ шифро ZRTP (ну или по проще )
+ работа за NAT
+ аудио (можно без видео и без конферент связи)

питался настроить jitsi.org на сервере www.officesip.com как бы все работает но есть одно НО jitsi не работает в NAT

Заранее спасибо

 

[marg0]

Вам еще необходим _http://turnserver.googlecode.com/files/officesip-turn-server-1.1.msi TURN сервер, для работы за НАТ, ну а если у вас будет свой VDS|VPS то все вопросы решаются туннелированием VoIP

Добавлено в [time]1388239333[/time]
Можете попробовать также Asterisk. Есть уже готовые решения все в одном из коробки типа Zentyal, настройка банальна, все можно найти на официальном сайте.

 

[Dark Koder]

насколько мне обьясняли, то проще астериском сделать, а дальше просто проверяется его работа в режиме мониторинга и распределение всей сети.

 

[at0m]

marg0
приведи схему что то не в курю то есть помимо vds где серв. officesip надо еще vds\vps под TURN сервер ?

 

[marg0]

На данный момент существует два варианта протокола: первый
вариант стандарта (Classic STUN) и текущий вариант стандарта (STUN).
Classic STUN предлагает алгоритм определения типа NAT и позволяет
определять внешний ip адрес и порт, которые привязываются локальному
узлу NAT транслятором. Использование STUN подразумевает, что есть
некий сервер, реализующий данный протокол, который имеет два
публично доступных ip адреса.
Следует учитывать, что в таком режиме могут быть пройдены только
различные варианты конического NAT. Симметричный NAT обладает
другими характеристиками фильтрации пакетов и способами привязки
ip адреса и порта, что не позволяет использовать полученные внешний
ip адрес и порт, так как либо при обращении к сервису он будет другой,
либо пакеты от сервиса не будут переданы клиенту. Для решения
описанной проблемы необходимо использовать технологии TURN для
обхода NAT на основе транслирующего сервера, который будет
непосредственного взаимодействовать с клиентом. При этом сам
транслирующий сервер имеет внешний ip адрес и далее дополнительных
трансляций адресов не выполняется. TURN позволяет узлу за NAT
получать входящие данные через TCP или UDP соединения и
предназначен для решения ситуаций, которые возникают в случае
использования NAT, привязывающих ip адреса и порты в зависимости от
ip адреса адресата, или от ip адреса и порта адресата.

 

[marg0]

Взаимодействие в сети TURN осуществляется по определенному
алгоритму. Клиент инициирует создание передающего адреса и в
дальнейшем управляет этой привязкой. Если адресат хочет отправить
некоторые данные клиенту, то он отправляет их на передающий адрес, а
затем TURN сервер передает их в виде TURN пакета клиенту.
Взаимодействие возможно с несколькими адресатами одновременно через
один передающий адрес, индикация адресата задается в TURN пакете. За
счет того, что ip адрес и порт TURN сервера, с которыми осуществляется
взаимодействие, являются фиксированными, способ привязки ip адреса и
порта, а также фильтрация трафика перестают оказывать негативное
влияние на передачу данных.
Таким образом, использование TURN позволяет избежать проблем,
возникающих при использовании NAT, привязывающих ip адреса и порты
в зависимости от ip адреса адресата, либо от ip адреса и порта адресата. На
данный момент TURN считается включенным в STUN, как один из
способов прохода NAT. Рекомендуется использовать TURN только, как
крайнюю меру, в случае, когда использование STUN не позволяет
осуществить передачу данных, использование TURN во всех случаях
передачи данных приводит к тому, что весь трафик взаимодействия между
узлами начинает проходить через TURN сервер. Определить наиболее
подходящий метод для конкретных условий передачи потоковых данных
позволяет ICE протокол , который регламентирует механизм выбора
между STUN или TURN