Причины односторонней слышимости при некоторых sip звонках?
Приветствую.
Работает следующая схема:
Мини-АТС Panasonic TDA-100 -> sip-шлюз D-Link DVG-2102s -> Роутер -> SIP-провайдер Zadarma
В 20% звонков мы не слышим вызываемую сторону. Т.е. первая попытка: идет гудок вызова, после щелчок, и тишина. После эксперементов выяснилось, что щелчок - это соединение и вызываемый абонент сказал "алло", нас он слышит, но мы не слышим его. В логах у оператора звонок отображается как успешное соединение с длительностью разговора 1 минута - все логично. Со второй или третьей попытки соединение проходит успешно.
Теоретически где может быть загвоздка? Из-за чего может быть односторонняя слышимость?
Зеркалировать порт подключения DVG-2102s и снимать полный дамп трафика.
Еще лучше если одновременно на WAN роутера тоже снять дамп.
Без этого только предположения, что роутера ломает SIP в некоторых случаях.
@Rostel а что конкретно роутер может ломать в sip? в какую сторону загуглить?
Что надо проверить в дампе от сип-шлюза? Их целый пул, я на отдельном буду эксперементировать, но надо знать что выловить. Вдруг трабл в конкретной железке. Чем и объясняется отсутствие голоса в части звонков.
лучше с порта чтоб RTP тоже попал как есть
снимать wireshark, tcpdump, ngrep... в pcap-файл
чем можете пользоваться
для справок по командам https://wiki.freeswitch.org/wiki/Packet_Capture
только без фильтров по портам
@rostel
Сегодня по закону подлости "клева не было", все звонки проходили. Единственное что поймал destination unreachable https://yadi.sk/d/VyA8aj1CcLqet - дамп.
Что это может быть?
@rostel: сегодня отловил. было два звонка подряд на один номер, указанный в файле. в обоих проблема с односторонней слышимостью. перезвонили вызываемой стороне с мобильного, она подтвердила, что мы "молчали". в отчете задармы оба звонка числятся, как удачные звонки с длительностью 1 минута. https://yadi.sk/d/yMzGLrKPcMoLM
@rostel: если связанно с тем, что шлюз не знает, что он за НАТ, то не понятно, почему так редко звонки не проходят, они всегда должны так глючить, нет?
Я искал в настройках пункт, обозначающий что устройство за НАТ - не нашел. ctun отключен.
Щас еще поищю поддержку НАТ и отпишусь.
rostel
Пытаюсь отловить звонок, то пользователи не фиксируют время и номер проблемы, то меня нет на месте. Пока дампа нет подходящего.
Но вот что еще выловил.
На всех железках было выставлено:
Listen Port UDP: 5060
RTP Starting Port UDP: 9000
Соответственно при регистрации первая забирала 5060 порт, а все остальные регистрировались на портах 1024 и далее. Может это их как то сбивало?
Я щас прописал на второй, третье и т.д. железке сип-порты 5062, 5064 и т.д. ; rtp порты 9100, 9200 и т.д.
Сразу возник вопрос - через один порт надо указывать, т.е. каждому устройству надо два порта или один? В инете где-то встретил упоминание, что надо два порта. Хотя по логике нужен один порт.
А вот в описании rtp написано, что надо два порта на линию.
И что на счет SIP-ALG, на сколько это глючная вещь, не подскажите? Ее лучше отключить?
SIP-ALG часто мешается, на разных железяках работает абсолютно по разному.
Поставли б у себя Asterisk или FreeSwitch и не морочились с прямым подключением шлюзов к оператору.
rostel:
Без SIP-ALG несколько voip-шлюзов за NAT не будут работать же?
Asterisk есть, но в данной цепочке он не участвует. Считал его лишним звеном отказа.
Думаете лучше чтобы сип шлюзы и Астериск находились в одной подсети и взаимодействовали между собой, а Астериск уже регился у сип-провайдера + прокинуть на него rtp порты из внешки?
@CatHD и реально задарму уговорить на запись трафика? я с ними бадаюсь уже месяц по этому поводу, они говорят на нашей стороне проблем нет и все.
Что конкретно у них попросить? Так и написать "записать трафик"? Дамп снимать с того, что они предоставят или дамп с порта коммутатора на котором сип-шлюз?
Сообщаете им свой внешний IP и просите включить запись трафика, затем совершаете тестовые вызовы до получения одностороней слышимости, затем сообщаете что бы выслали дамп, всё. В дампе будет явно видно, был ли от вас RTP или нет. Если RTP нет, следует искать причину у себя. Если был, надо проверить сигнализацию и порты с которых был RTP. Но всё это делается с дампом трафика со стороны задармы.
Dynaton
nat есть.
Если потерю пакетов из внешки можно как нибудь объяснить, то во внешку то пакеты как могу не уходить? При условии что фаерволл не при чем, а фаерволл не при чем так как 90% звонков проблем не имеют. Что значит проверить RTP порты, на фаерволле и на шлюзах?
kodi: увидел фразу "нас он слышит, но мы не слышим его"
тобишь до Вас RTP не всегда долетают, это в НАТ беда.
спросить какие RTP порты выделены у провайдера, и пробросить их через НАТ на dlink
Dynaton
сорри, все верно, скорее всего до шлюза от провайдера не доходят rtp-пакеты.
но почему они не доходят в таком маленьком проценте звонков(соединений)? сама проблема в чем может крыться - в таймауте, в занятых портах или еще в чем?
Пробросить порты через NAT на одну железку нельзя, так как железок много.
На всех железках было выставлено:
Listen Port UDP: 5060
RTP Starting Port UDP: 9000
Соответственно при регистрации первая забирала 5060 порт, а все остальные регистрировались на портах 1024 и далее. Может это их как то сбивало?
Я щас прописал на второй, третье и т.д. железке сип-порты 5062, 5064 и т.д. ; rtp порты 9100, 9200 и т.д.
Сразу возник вопрос - через один порт надо указывать, т.е. каждому устройству надо два порта или один? В инете где-то встретил упоминание, что надо два порта. Хотя по логике нужен один порт.
А вот в описании rtp написано, что надо два порта на линию.
Сначала снимаете дамп на АТС с которой звоните. Если все норм то начинайте анализ трафика на NAT устройствах, смотрите что входит и что выходит )) Работы и правда не много, просто нужны знания по SIP. Успехов.