forum.lissyara.su

Уважаемые коллеги! Прошу помощи!

Проблема с потерей голосовых данных (VOIP).
Используем VOIP для исходящих вызовов.
Входящие по E1.
Кодеки пробовали 729, 711. На последнем еще хуже.

Вводные данные: полоса пропускания интернет канала 40Мбит синхронно
Шлюз FreeBSD 8.2 (АТС Panasonic TDE600 подключена через NAT, в качестве пакетного фильтра - PF)

/etc/pf.conf

# Macros:
int_if_1 = "em0"
ext_if_1 = "em1"
vpn = "tun0"
iodine = "tun1"
ext_nat_1 = "белыйIP"
zero_net = "192.168.0.0/24"
dhcp_net = "192.168.1.0/24"

# Tables
table <private> { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/24 }
table <admin> { }
table <authpf_users> persist
table <sshguard> persist
table <oovoo> { 63.111.29.0/24, 213.218.157.0/24 }

# Options
set skip on lo0
set timeout { udp.first 300, udp.single 150, udp.multiple 900 }
set timeout { other.first 120, other.single 60, other.multiple 120 }
set fingerprints "/dev/null"

# Normalization
scrub in on $ext_if_1 all

# Translation
nat pass on $ext_if_1 from $zero_net to any -> $ext_nat_1
nat pass on $ext_if_1 from $dhcp_net to any port { 110 995 } -> $ext_nat_1
nat pass on $ext_if_1 from any to <oovoo> port { 80 443 5222 } -> $ext_nat_1

# Anchor
rdr-anchor remote_access
load anchor remote_access from "/etc/pf-remote_access.conf"

# Block all
block log all

# Pass local traffic
pass quick on lo0 all no state
pass quick on $int_if_1 all no state

# Out traffic
pass out on $ext_if_1 from ($ext_if_1) to any

pass out on $ext_if_1 proto udp to port 1194 keep state
pass out on $ext_if_1 proto tcp to port 1194 keep state
pass out on $vpn to any keep state
pass out on $iodine to any keep state

# In traffic
pass in on $ext_if_1 proto icmp all
pass in on $ext_if_1 proto tcp to port 22 flags S/SA
pass in on $ext_if_1 proto tcp to port 25 flags S/SA
pass in on $ext_if_1 proto tcp to port 110 flags S/SA
pass in on $ext_if_1 proto tcp to port 993 flags S/SA
pass in on $ext_if_1 proto tcp to port 995 flags S/SA
pass in on $ext_if_1 proto { tcp, udp } to port 53
pass in on $ext_if_1 proto { tcp, udp } from any port 53
pass in on $ext_if_1 proto tcp from any port { 80 8080 443 } to ($ext_if_1)
pass in on $ext_if_1 proto tcp to port 80 flags S/SA keep state

pass in on $ext_if_1 proto udp to port 1194 keep state
pass in on $ext_if_1 proto tcp to port 1194 keep state

pass in on $vpn to any keep state
pass in on $iodine to any keep state


Как видно, приоритезацию трафика не используем, т.к. канал используется не на 100%. В сети 100 юзеров, 70% которых сидят за SQUID'ом, и только остальные за NAT'ом.

Ping-pong до оператора SIPNet:

Обмен пакетами с 212.53.40.40 по 32 байт:

Ответ от 212.53.40.40: число байт=32 время=4мс TTL=248
Ответ от 212.53.40.40: число байт=32 время=3мс TTL=248
Ответ от 212.53.40.40: число байт=32 время=3мс TTL=248
Ответ от 212.53.40.40: число байт=32 время=3мс TTL=248
Ответ от 212.53.40.40: число байт=32 время=3мс TTL=248
Ответ от 212.53.40.40: число байт=32 время=3мс TTL=248
Ответ от 212.53.40.40: число байт=32 время=4мс TTL=248

Статистика Ping для 212.53.40.40:
Пакетов: отправлено = 7, получено = 7, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 3мсек, Максимальное = 4 мсек, Среднее = 3 мсек

Также проводил тестирование всевозможными утилитами - судя по анализу - скорость отличная.

Хотелось бы понять, в чем косяк.
Сначала была мысль, что SIPNet крякает, но подключив тестовый аккаунт другого SIP оператора поняли, что дело не в них.
Через программный IPтелефон качество такое же, так что АТС настроена правильно (настраивали квалифицированные ребята из SOLYAR.RU)

И что самое интересное: МЫ собеседника слышит на протяжении всего разговора отлично, а вот нас - с перебоями.

Если однозначным советом будет включение ALTQ, то не проблема, перекомпилю ядро, внесу изменения в PF, но хочется понять почему канала 40Мбит не хватает даже для одного вызова?!!

Предлагаю вместо шлюза подключить машину с софтовым телефоном и проверить точно, что дело в шлюзе. Если напрямую все в норме, тогда отключить фаер и протестить без него. Попробовать ipfw+kernel nat, благо сейчас перекомпиливать не надо, достаточно модуль подгрузить.

поставь mru 1400

manefesto писал(а):поставь mru 1400

Простите, это где прописать?

tynix писал(а):Предлагаю вместо шлюза подключить машину с софтовым телефоном и проверить точно, что дело в шлюзе. Если напрямую все в норме, тогда отключить фаер и протестить без него. Попробовать ipfw+kernel nat, благо сейчас перекомпиливать не надо, достаточно модуль подгрузить.

Вместо шлюза не получится, сервер работает 24х7х365, да и белый IP один

mizantrop писал(а):

manefesto писал(а):поставь mru 1400

Простите, это где прописать?

а не...немного напутал

MTU/MSS ISSUES
Problems can arise on machines with private IPs connecting to the Inter-
net via a machine running both Network Address Translation (NAT) and
pppoe. Standard Ethernet uses a Maximum Transmission Unit (MTU) of 1500
bytes, whereas PPPoE mechanisms need a further 8 bytes of overhead. This
leaves a maximum MTU of 1492. pppoe sets the MTU on its interface to
1492 as a matter of course. However, machines connecting on a private
LAN will still have their MTUs set to 1500, causing conflict.

Userland pppoe(8) users do not have to worry about this issue, since
ppp(8) itself has an option, ``mssfixup'', which is enabled by default
and takes care of this. Kernel pppoe users have to rely on other meth-
ods:

o Using a packet filter, the Maximum Segment Size (MSS) can be set
(clamped) to the required value. The following rule in pf.conf(5)
would set the MSS to 1440:

scrub out on pppoe0 max-mss 1440

Although in theory the maximum MSS over a PPPoE interface is 1452
bytes, 1440 appears to be a safer bet. Note that setting the MSS
this way can have undesirable effects, such as reducing TCP/IP
throughput, and interfering with the OS detection features of pf(4).

o Setting the MTU on all interfaces being NAT'ed to 1492, instead of
the Ethernet default, 1500. This can be done using ifconfig(8). The
following would set the MTU to 1492 on interface bge0:

# ifconfig bge0 mtu 1492

Unfortunately not all interfaces support setting the MTU at this
time.

See pf.conf(5) for more information on MTU, MSS, and NAT.

manefesto писал(а):

mizantrop писал(а):

manefesto писал(а):а не...немного напутал

Может на самом деле что-то с настройками сет.платы?
Где еще капнуть то?!

ты попробовал что я описал ?

manefesto писал(а):ты попробовал что я описал ?

Установил для em1 (интерфейс, смотрящий на прова) MTU 1492.
Пока без изменений.
Что самое интересное: загрузка канала сейчас максимум 5Мбит, бывают скачки до 10Мбит, но редко. Т.е. канал нагружен по минимуму.

да йобжеж

int_if_1 = "em0"
ext_if_1 = "em1"
vpn = "tun0"
iodine = "tun1"

scrub out on $int_if_1 max-mss 1440
scrub out on $ext_if_1 max-mss 1440
scrub out on $vpn max-mss 1440
scrub out on $iodine max-mss 1440

Для начал какой протокол используется?

manefesto писал(а):да йобжеж

Не помогло Есть еще идеи?

Покажите вывод pfctl -si во время затыков

Dark_ASU писал(а):Для начал какой протокол используется?

RTP (SIP)

AzureZ писал(а):Покажите вывод pfctl -si во время затыков

Status: Enabled for 3 days 14:35:50 Debug: Urgent

State Table Total Rate
current entries 1366
searches 111291463 357.0/s
inserts 791743 2.5/s
removals 790377 2.5/s
Counters
match 67554908 216.7/s
bad-offset 0 0.0/s
fragment 971 0.0/s
short 0 0.0/s
normalize 47 0.0/s
memory 0 0.0/s
bad-timestamp 0 0.0/s
congestion 0 0.0/s
ip-option 15 0.0/s
proto-cksum 13 0.0/s
state-mismatch 1514 0.0/s
state-insert 5 0.0/s
state-limit 0 0.0/s
src-limit 0 0.0/s
synproxy 0 0.0/s

Коллеги, помогите советом, в какую сторону копать. Экспериментирую над пакетным фильтром, читаю документацию, но ничего путного не получается.

убери pf и тестируй

manefesto писал(а):убери pf и тестируй

Что думаете над таким вариантом: добавить новый сетевой интерфейс, АТСку кинуть в эту подсеть, и каким-то образом завернуть SIP-трафик на новую плату?
Благо машинка крутиться на VMWare ESX, останется только ребутнуться. Только вот как трафик "завернуть"?

manefesto писал(а):убери pf и тестируй

У меня 30 человек за NAT'ом сидят, VIP'ы... Им это не оч понравится..

оставайся после работы и тестируй

Какого рода затыки? прерывания, метал голос, не четко слышно? Еще, при звонке уже только одного VOIP происходит заторы, либо при нагрузке?
Вообще идею с MTU поддерживаю. И почему только 1440 ? возможно ниже у меня 1383 летает аж бегом, а выше та же засада. Это зависит от провайдеров.

newadmin писал(а):Какого рода затыки? прерывания, метал голос, не четко слышно? Еще, при звонке уже только одного VOIP происходит заторы, либо при нагрузке?
Вообще идею с MTU поддерживаю. И почему только 1440 ? возможно ниже у меня 1383 летает аж бегом, а выше та же засада. Это зависит от провайдеров.

Да, все,как вы описываете - прерывания, метал голос и слышно плохо, причем все это именно по отношению к исходящему голосу, т.е. нас плохо слышно, а мы собеседника слышим отлично на всем протяжении разговора.
И наиболее ощутимы кряки и прерывания при использовании кодека 711A. На 729А качество заметно лучше, но все равно, ДАЖЕ ПРИ ПЕРВОМ ВЫЗОВЕ случаются перебои, не говоря уже о нескольких одновременных.
Поставил MTU 1383, пока полет нормальный, но переводить всех на SIP пока не буду, хочу окончательно сам удостовериться в приемлемом качестве, пока юзеры на E1 сидят.
Спасибо за ответ, надеюсь, это будет последний пост в теме..

Вот в конфиге pf не вижу где трафик на АТС заворачиватеся?

Не много влезу в разговор.

Уточните.
1. Ваша АТС это железка или сервер типа Asterisk (на сколько я понял он у Вас стоит на ESX).
2. На другом конце провода тоже Asterisk или что то другое?

Если Вы связываете Asterisk-Asterisk однозначно откажитесь от sip и используйте iax2.

kharkov_max писал(а):Не много влезу в разговор.

Уточните.
1. Ваша АТС это железка или сервер типа Asterisk (на сколько я понял он у Вас стоит на ESX).
2. На другом конце провода тоже Asterisk или что то другое?

Если Вы связываете Asterisk-Asterisk однозначно откажитесь от sip и используйте iax2.

В качестве ATC выступает Panasonic TDE600, а вот шлюз на ESX'е.