asterisk.ru

Vlad1983 писал(а):включайте дебаг access-list-ов

В access-list ничего не дропается. Открыли все по максимуму, то есть по IP.
На syslog сервере четко видно установление сессии RTP и RTCP и кол-во переданной информации.

это диагноз: NAT или SIP ALG.

В случае ALG: отключаем его на кошаках

относительно же NAT: есть замечательная утилита iperf. У ней есть режим UDP. попеременно проверяем порты UDP 5060, 10000:10001 (думаю достаточно). Меняем местами клиент и сервер, даем полосу 4M, пакетами 160bytes. Смотрим и убеждаемся..

Я в начале поста писал что нигде NAT не используется.

SIP ALG - используется в случае снова ж таки когда есть NAT, смысла отключать не вижу.

iperf - проверяет пропускную способность, задержки и т.д., не вижу смысла ею проверять, так как у нас есть система мониторинга, которая показывает нагрузку на входящем интерфейсе на ASA, общая загрузка за день максимальная была 8 Мбит/с из 100 Мбис/с. возможных. Да и если бы были задержки, то в худшем случае слышимость бы то пропадал то появлялась бы, то были бы искажения звука и т.д. но никак не односторонняя слышимость.
Вообщем пока без вариантов.

Сделано около 20-ти вызовов с абонента "А" на "Б", выловить ничего не удалось, все работает нормально, слышно, дебаг есть, там видны выбираемые кодеки, IP адреса телефонов и открытия UDP портов для RTP. Назовём это Картинка №1 (хорошая).
Нужно поймать плохой вызов, иметь его дебаг, и смотреть выбираемые кодеки, IP адреса телефонов и открытия UDP портов для RTP. В этой картинке №2 (плохой) что-то будет отличаться от картинки №1.
Найти и устранить.

Капитан Очевидность (с)

malder_d писал(а):SIP ALG - используется в случае снова ж таки когда есть NAT, смысла отключать не вижу.

не видите, но он есть

НУ а если чуть поразмыслить. Что у нас получается при передачи голоса от абонента до астериска. Поправьте если не правильно напишу.
На первом этапе с астериском согласуются кодеки, порты передачи медиаданных RTP, управляющий порт RTCP (обязательно). После чего астериск с абонентом "А" строит канал. Далее он посылает запрос на абонента "Б" и согласовывает с ним все остальные параметры, после чего и с ним строится канал. Внутри астериска между каналами строится так называемый мост (бывает разных типов) и начинается передача данных.
Далее, в случае если кодеки абонентов не совпадают то астериск внутри себя делает транскодинг, можно посмотреть командой core show channel (канал), происходит у Вас транскодинг или нет. Также там есть такие интересные параметры как NativeFormats - это родной формат кодека со стороны клиента WriteFormat - говорит о том что со стороны астериска будет идти звук в формате кодека такого-то, ReadFormat - говорит что запись голоса в астериск будет идти по такому-то кодеку.
Теперь что получается в моем случае когда абонент "А" делает вызов абоненту "Б". и абонент "А" не слышит абонента "Б". Пакеты от "А" с голосом бегут по каналу пусть будет 1 (это от А до астериска), далее через мост в канал пусть будет 2 (это от астериска до Б), и абонент "Б" слышит, но когда абонента "Б" говорит то по логике пакеты должны попадать в канал 2, а раз звук от астериска приходит по каналу 2 то и уходит без проблем должны, тут уже не согласованность портов по каналу 2 не может быть так само как и по каналу 1, ведь голос со стороны 1-го каналу проходит.
Получается проблема может быть как в телефонном аппарате, он попросту может не отправлять пакеты грубо говоря с микрофона, так и может быть в самом астериске.

SIP ALG - используется в случае снова ж таки когда есть NAT, смысла отключать не вижу.

Используется ВСЕГДА. И Asterisk НЕ СОВМЕСТИМ С НИМ. ВЫКЛЮЧИТЬ.

iperf - проверяет пропускную способность, задержки и т.д., не вижу смысла ею проверять, так как у нас есть система мониторинга, которая показывает нагрузку на входящем интерфейсе на ASA, общая загрузка за день максимальная была 8 Мбит/с из 100 Мбис/с. возможных. Да и если бы были задержки, то в худшем случае слышимость бы то пропадал то появлялась бы, то были бы искажения звука и т.д. но никак не односторонняя слышимость.

Начитались википедии? или лень?
Делайте как Вам говорят.. трубу нужно проверить - залипает ли NAT и вообще есть ли потери, еще засечь wireshark меняются ли порты.

Вообщем пока без вариантов.

Ага, читать умные книжки, верить в УльтраЛорда)))

ded писал(а): Капитан Очевидность (с)

+100500 )

В случае когда абонент "А" делает вызов абоненту "Б". и абонент "А" не слышит абонента "Б". Пакеты от "А" с голосом бегут по каналу?
Вы можете это увидеть или
tcpdump host 1 телефон "А"
tcpdump host 2 телефон "Б"
или
CLI> rtp set debug on

если дело в ALG, тогда RTP порты в SDP у INVITE и в реальности (видно в pcap) будут отличаться.
Также будут исковерканы и некоторые заголовки SIP..

ded писал(а):Сделано около 20-ти вызовов с абонента "А" на "Б", выловить ничего не удалось, все работает нормально, слышно, дебаг есть, там видны выбираемые кодеки, IP адреса телефонов и открытия UDP портов для RTP. Назовём это Картинка №1 (хорошая).
Нужно поймать плохой вызов, иметь его дебаг, и смотреть выбираемые кодеки, IP адреса телефонов и открытия UDP портов для RTP. В этой картинке №2 (плохой) что-то будет отличаться от картинки №1.
Найти и устранить. (с)

Вызов плохой поймал, дебаг с него есть со стороны звонящего. Просмотрел выбираемые кодеки, всегда выбирает G729, IP адреса телефонов и порты RTP совпадают по логам по всем трем железкам (ASA)на пути следования. После был совершен вызов с нормальной слышимостью. Разницы между первой и второй картинкой никакой абсолютно, просмотрел строчка за строчкой. Со стороны телефона RTP порт всегда 5004 RTCP 5005, со стороны асетриска порты четко выбираются из диапазона 10000-10500.

Единственное что еще не поймал дебаг со стороны абонента "Б" и дебаг по RTP.

Zavr2008 писал(а):если дело в ALG, тогда RTP порты в SDP у INVITE и в реальности (видно в pcap) будут отличаться.
Также будут исковерканы и некоторые заголовки SIP..

ну хорошо, вы говорите что порты в реальности бы отличались, но я б на syslog сервере увидел бы измененный порт наверняка, ведь там пишутся все коннекты, или я не прав?