Астериск неправильно выбирает сетевой интерфейс
|
Сообщений: 28
|
Re: Астериск неправильно выбирает сетевой интерфейс
tmaСудя по моим экспериментам, asterisk указанный в bind адрес подставляет как src ip-адрес, соответсвенно если этот адрес 0.0.0.0, то он его и указывает. Конечно звук никуда не придет. Следовательно, я думаю, что нужно указывать именно тот адрес, с которого нужно гнать rpt. ;)
Да ну ?
И ты серьезно думашь, что пакеты с обратным адресом 0.0.0.0 пройдут через IP-стек.
Вообще, принято всякие догадки проверять через tcpdump. Проверь...
0.0.0.0 это не "любой" ip. А _ВСЕ_ локальные ip. Т.е. будет использован ближайший по роутингу.
|
|
Сообщений: 1530
|
Re: Астериск неправильно выбирает сетевой интерфейс
alekseybb
И ты серьезно думашь, что пакеты с обратным адресом 0.0.0.0 пройдут через IP-стек.
Я серьезно думаю, что в chan_h323 есть ошибка. См. ниже.
alekseybb
Вообще, принято всякие догадки проверять через tcpdump. Проверь...
А я догадки не строю -- я пускал h.323 debug и вижу результат, что в качестве dst IP chan_h323 пишет IP, куда он лезет, а в качестве src IP он пишет 0.0.0.0. Далее все просто не работает. На машине _один_реальный_IP_. Т.е. выбирать можно только между 127.0.0.1 (если он его выбрал, то эффект будет тот же самый, т.е. rtp поток уйдет в никуда) и реальным IP.
Решение -- прописать в bindaddr реальный IP.
Если бы я не решил бы проблему этим способом, то я бы стал пускать всякие там tcpdump и пр. А иначе это просто ненужно...
alekseybb
0.0.0.0 это не "любой" ip. А _ВСЕ_ локальные ip. Т.е. будет использован ближайший по роутингу.
Я знаю что такое 0.0.0.0. ;)
Думаю ты в этом не сомневаешься. ;)
Но где именно ошибка в asterisk'овском chan_h323 я не смотрел.
Хотя надо будет... Не представляю даже что они умудрились сделать. |
|
Сообщений: 31
|
Re: Астериск неправильно выбирает сетевой интерфейс
горячие финские парни! ;-)
у меня сервер с интерфейсами 192.168.0.40 и 82.208.хх.уу
на нем * и gnugk, через интерфейс с адресом 82.208.хх.уу шлет голос на провайдера ип-телефонии, звонок хоть с gnugk хоть с * проходит, но никто никого не слышит
то есть вы говорите о том что мне в h323.conf в [general]
указать bindaddr = 82.208.хх.уу (вместо 0,0,0,0 )
то все должно заработать ??
|
|
Сообщений: 1530
|
Re: Астериск неправильно выбирает сетевой интерфейс
alex_u2
на нем * и gnugk, через интерфейс с адресом 82.208.хх.уу шлет голос на провайдера ип-телефонии, звонок хоть с gnugk хоть с * проходит, но никто никого не слышит
С gnugk не рботал.
Можно предположить, что кодеки не совпадают, rtp трафик режется...
Фиг знает...
alex_u2
то есть вы говорите о том что мне в h323.conf в (general)
указать bindaddr = 82.208.хх.уу (вместо 0,0,0,0 )
то все должно заработать ??
В случае с двумя интерфейсами я даже не знаю.
Но сам бы прописать публичный.
|
|
Сообщений: 28
|
Re: Астериск неправильно выбирает сетевой интерфейс
tma
А я догадки не строю -- я пускал h.323 debug и вижу результат, что в качестве dst IP chan_h323 пишет IP, куда он лезет, а в качестве src IP он пишет 0.0.0.0. Далее все просто
[ ..... ]
Но где именно ошибка в asterisk'овском chan_h323 я не смотрел.
Хотя надо будет... Не представляю даже что они умудрились сделать.
Я все-таки рекомендую tcpdump. Т.е. это не src IP.
Далее, если речь идет об RTP, то в нем значение src IP вообще роли не играет, так как это поток, вложенный в UDP, т.е. он _всегда_ идет в одну сторону.
Вообще, чтобы понять проблему надо начать говорить нормальным языком. Все проблемы роутинга VoIP в том, что ряд кривых протоколов в начале инициализации сессии сообщают удаленной стороне неверный обратный адрес. Т.е. такой который не может быть отроучен. ЭТО НЕ ИМЕЕТ НИКАКОГО ОТНОШЕНИЯ К IP.
Короче. Я собственно о непонимании, которое приводит к высказываниям вроде
tma:Это ядро должно выбирать сетевой интерфейс. man ip
Ядро делает все, что надо. Это протокол такой, в котором сообщается адрес отправителя кроме того, что есть в несущем протоколе udp/ip и проч.
|
|
Сообщений: 1530
|
Re: Астериск неправильно выбирает сетевой интерфейс
alekseybb
Я все-таки рекомендую tcpdump. Т.е. это не src IP.
На рабочей машине сносить h.323 ради запуска tcpdump у меня нет желания, а больше нигде h.323 проверить мне не получится.
alekseybb
Далее, если речь идет об RTP, то в нем значение src IP вообще роли не играет, так как это поток, вложенный в UDP, т.е. он _всегда_ идет в одну сторону.
Да, согласен, что я неверно выразился.
Скорее всего * действительно сообщает другой стороне неверный адрес, вот туда все и шлется... Без результатно, конечно.
alekseybb
tma:Это ядро должно выбирать сетевой интерфейс. man ip
В случае с несколькими публичными IP для tcp/ip действительно нужно читать man ip. К примеру для балансировки. Иначе нет никакого смысла вешать на разные IP. Конечно если все публичные IP висят алиасами на одном канале, то можно man и не читать. ;)
|
|
Сообщений: 31
|
Re: Астериск неправильно выбирает сетевой интерфейс
Вообще, чтобы понять проблему надо начать говорить нормальным языком. Все проблемы роутинга VoIP в том, что ряд кривых протоколов в начале инициализации сессии сообщают удаленной стороне неверный обратный адрес. Т.е. такой который не может быть отроучен. ЭТО НЕ ИМЕЕТ НИКАКОГО ОТНОШЕНИЯ К IP.
полностью поддерживаю! в свое время когда я тоглько начал сталкиваться с voip и h323 собаку съел. пытался заставить нормально работать H323 через НАТ. устройство, сидящее за натом, сообщало публичному гейткиперу свой серый адрес и естественно он не мог никуда быть отроучен!.
На рабочей машине сносить h.323 ради запуска tcpdump у меня нет желания, а больше нигде h.323 проверить мне не получится.
а зачем сносить h323? |
|
Сообщений: 1530
|
Re: Астериск неправильно выбирает сетевой интерфейс
alex_u2
На рабочей машине сносить h.323 ради запуска tcpdump у меня нет желания, а больше нигде h.323 проверить мне не получится.
а зачем сносить h323?
Объясняю еще раз -- НА РАБОЧЕЙ МАШИНЕ! Чтобы провести эксперимент, нужно проставить 0.0.0.0 и запустить tcpdump.
Конечно я увижу, что там пишется в самих заголовках, но все сессии умрут. Меня не поймутс...
Если мне подскажут иной способ (без поднятия h.323 на другой машине) проверки? ;)
Нет у меня сейчас времени решать чужие проблемы, когда решением проблемы (даже временным) было прописать public IP.
|
|
