AF
Asterisk Forum
обсуждения телефонии, VoIP и IP-PBX
12разделов
5 423тем
34 385сообщений
← К списку тем

SIP over OpenVPN

Asterisk IP PBX 17 сообщений -
#1

Прочитал тут-
http://openvpn.net/archive/openvpn-users ... 00389.html
и тут
http://www.networkworld.com/reviews/2006 ... -test.html

Поставил OpevVPN, тестирую, пингую сервер с клиента через OpevVPN, т.к. клиент получил от сервера IP через OpevVPN- ping reply time 35-70 ms.

Проблема- А когда звоню через OpevVPN и пингую сервер с клиента через OpevVPN, ping "прыгает" до 900-3700 ms и при этом звук прерывистый...

OpevVPN компрессия (comp-lzo) включена или нет не меняет ситуацию...

Может дело в энкапсуляции SIP пакетов в OpevVPN? Кодек G711, а G729 у меня не стоит...

Вопрос- Может ли использование G729 улучшить ситуацию?

Может кто зто уже делал...

Спасибо...

_________________
О сколько нам открытий чудных готовят просвещенья дух...


Последний раз редактировалось: chief.centrel (Ср Апр 16, 2008 04:23)
#2

я слышал что в openvpn очень маленький срок жизни пакета udp и он просто их отбрасывает
если же поднять на tcp то всеравно потмо воип идет внутри по udp и также отбрасывается много. это всеголишь слух, я не проверял пока еще.

_________________
«Choose a job you love, and you will never have to work a day in your life» — Confucius
#3

У нас работает голос по OpenVPN. Замечаний нет.
Как верно замечено оппонентом в первом линке, имеет место проблема фрагментации, что устраняется изменением МТУ.
#4

Спасибо, да у меня proto tcp-client/server вот нашел тут пояснение, http://openvpn.net/archive/openvpn-users ... 00141.html
http://openvpn.net/archive/openvpn-users ... 00150.html

я так понимаю вы anest имели ввиду data overrun situation- packet dropped due to output saturation?

Цитата:
Now if you run OpenVPN over TCP, then run a UDP based IP phone service over OpenVPN then you basically have a UDP -> OpenVPN -> TCP connection. Now since TCP is automatically rate limited but UDP is not, then if OpenVPN is getting data at X bytes per second via the UDP VoIP protocol but the underlying TCP connection to the other OpenVPN peer can handle less than X bytes per second, then you have a data overrun situation and OpenVPN has no choice but to drop the packets. This is what the "MULTI: packet dropped due to output saturation message" means.

_________________
О сколько нам открытий чудных готовят просвещенья дух...
#5

Exactly! именно этот кусок текста гдето и видел..
_________________
«Choose a job you love, and you will never have to work a day in your life» — Confucius
#6

Да сделайте проше tunnel или ipsec tunnel, если нужно кой-какое шифрование.
Подправить MTU на iface и все пучком.

_________________
ys
http://voip.rus.net/
#7

Поставил две строчки-
mssfix 1500
tun-mtu 1500

и это не помогло...

а с опцией fragment 1200 пишет- --fragment can only be used with --proto udp

Я поясню почему у меня только OpenVPN катит. Дело в том что я провел домашний телефон к себе на работу, а поскольку там 5060 и 5061 порты закрыты то приходиться через OpenVPN, да и еще у меня клиент там XP, так что я вставил USB WiFi адаптер в комп и он у меня как AP, причем моя WiFi Zyxel P-2000W_V2 труба в такой связке сразу получает мой домашний внутренний IP.

Такая схема не заработает с ipsec tunnel или L2TP- DHCP адрес не даст и пакеты не будут форвардиться...

Вот таки дела...

_________________
О сколько нам открытий чудных готовят просвещенья дух...
#8

chief.centrel писал(а):

а с опцией fragment 1200 пишет- --fragment can only be used with --proto udp

Почему тогда в серверном конфиге не поставишь proto udp?
#9

Цитата:

Почему тогда в серверном конфиге не поставишь proto udp?


A у меня TCP сервер-

Код:

# Are we connecting to a TCP or
# UDP server? Use the same setting as
# on the server.
proto tcp
;proto udp

_________________
О сколько нам открытий чудных готовят просвещенья дух...
#10

Я же написал - почему в серверном конфиге не используешь udp?
#11

у openvpn overhead на rtp получается весьма заметный, может быть просто канал тонкий?
#12

Друзья столкнулся с точно такой же проблемой, подскажите как решать?
#13

Пользуем udp
mtu подрезаем, обычно до 1400
#14

Спасибо, попробую отпишусь по результатам.
#15

Проблема заключалась в TCP over TCP.
Proto UDP на обоих концах решили вопрос с заиканиями.
#16

Dr.Sqaer писал(а):
TCP over TCP

Вы уверены в том что пишете?

_________________
«Choose a job you love, and you will never have to work a day in your life» — Confucius
#17

Dr.Sqaer писал(а):
Друзья столкнулся с точно такой же проблемой, подскажите как решать?


просто я убрал comp-lzo (дополнительное сжатие трафика), идущего через виртуальный туннель.

# comp-lzo

_________________
О сколько нам открытий чудных готовят просвещенья дух...