Тема: Односторонняя слышимость при подключении по SIP (Q38689)
АТС подключена по SIP к провайдеру Глобус Телеком (http://www.globus-telecom.com/ ) в режиме peer-to-peer . Подключение проводилось не мной, я вызван для решения проблемы с односторонней слышимостью разговора. Симптомы следующие. Вызов устанавливается (например, на моб. , но это значения не имеет), абонента АТС слышно, а городского нет. Снял трассировку. На ней видно, что голосовой траффик поступает в обе стороны, причем именно на тот порт, который запрашивается Панасоником . Проигрываю разговор средствами Вайршарк (трассировка снималась на АТС) - голос в обе стороны ходит , а у абонента АТС в это время тишина. Т.е. DSP почему-то считает, что эти пакеты адресованы не ей ... Пытался обнулить АТС и поднять её с минимумом настроек подключения к провайдеру - тоже самое. К АТС подключены несколько NT аппаратов - между ними и аналоговыми телефонами голос идет нормально. Подскажите, в чем заключается проблема?
Успешное соединение NTххх - PBX по какому порту происходило, ниже 12010 ?
Может DSP-16 попробовать поменять ?
АТС подключена по SIP к провайдеру Глобус Телеком (http://www.globus-telecom.com/ ) в режиме peer-to-peer . Подключение проводилось не мной, я вызван для решения проблемы с односторонней слышимостью разговора. Симптомы следующие. Вызов устанавливается (например, на моб. , но это значения не имеет), абонента АТС слышно, а городского нет. Снял трассировку. На ней видно, что голосовой траффик поступает в обе стороны, причем именно на тот порт, который запрашивается Панасоником . Проигрываю разговор средствами Вайршарк (трассировка снималась на АТС) - голос в обе стороны ходит , а у абонента АТС в это время тишина. Т.е. DSP почему-то считает, что эти пакеты адресованы не ей ... Пытался обнулить АТС и поднять её с минимумом настроек подключения к провайдеру - тоже самое. К АТС подключены несколько NT аппаратов - между ними и аналоговыми телефонами голос идет нормально. Подскажите, в чем заключается проблема?
Я бы проверил исправность АТС, взяв с собой к клиенту стендовую NCP500. Если на одной АТС работает, а на другой - нет, значит виновато железо, и его надо менять. В противном случае - проблема у провайдера.
NT телефоны работают нормально с аналоговыми, значит DSP работает корректно. История завершилась совершенно неожиданно. Внезапно слышимость стала двухсторонней. Сеть админ не ковырял, я для проверки залил старый “проблемный” бэкап - все равно работало как часы. В общем, скоро начну в чудеса верить.
NT телефоны работают нормально с аналоговыми, значит DSP работает корректно. История завершилась совершенно неожиданно. Внезапно слышимость стала двухсторонней. Сеть админ не ковырял, я для проверки залил старый “проблемный” бэкап - все равно работало как часы. В общем, скоро начну в чудеса верить.
Провайдер чудесный, укуси его пчела.
... В общем, скоро начну в чудеса верить.
Чудес не бывает. Бывают чудотворцы...
Если никто ничего не делал, то остается только одна причина: конфликт IP адресов DSP процессора и другого устройства.
Станция молча отдает правление компу без всякого сопротивления, комп при этом про конфликт адресов даже не пишет...
... В общем, скоро начну в чудеса верить.
Чудес не бывает. Бывают чудотворцы...
Если никто ничего не делал, то остается только одна причина: конфликт IP адресов DSP процессора и другого устройства.
Станция молча отдает правление компу без всякого сопротивления, комп при этом про конфликт адресов даже не пишет...
Ну Akela же вроде писал, что пакеты-то идут. А при конфликте IP он и к станции бы подключался через раз (в случае конфликта с адресом IPCMPR), IP-телефоны бы не работали тоже (в случае конфликта с адресом DSP)...
Так что я цинично полагаю, что виноват был сиплый пров.
... В общем, скоро начну в чудеса верить.
Чудес не бывает. Бывают чудотворцы...
Если никто ничего не делал, то остается только одна причина: конфликт IP адресов DSP процессора и другого устройства.
Станция молча отдает правление компу без всякого сопротивления, комп при этом про конфликт адресов даже не пишет...Ну Akela же вроде писал, что пакеты-то идут. А при конфликте IP он и к станции бы подключался через раз (в случае конфликта с адресом IPCMPR), IP-телефоны бы не работали тоже (в случае конфликта с адресом DSP)...
Так что я цинично полагаю, что виноват был сиплый пров.
Судя по трассировке, человек, который писал этот вопрос в Базу знаний на объекте не был.
Если и был, то типа мимо проходил и написал о всём об этом мягко говоря не правду.
ммм, не понял, что значит “на объекте не был” , “мимо проходил” и “написал ... не правду” ? Это адресовано мне!?
ммм, не понял, что значит “на объекте не был” , “мимо проходил” и “написал ... не правду” ? Это адресовано мне!?
Это адресовано тому человеку, который писал вопрос в Базу знаний.
этот же вопрос с такой же формулировкой был задан мной в БЗ.
этот же вопрос с такой же формулировкой был задан мной в БЗ.
Вчера ответил в Базе.
Проблемнную часть трассировки приложил.
предположение о том, что DSP вешают NT аппараты попытками регистрации интересное, но объясняет ли оно именно ОДНОСТОРОННЮЮ слышимость (т.е. в одну сторону DSP работает) , а также то, что АТС перезагружалась в том числе и с инициализацией настроек , но симпотмы этим победить не удалось? Конфликт адресов - тоже интересная гипотеза, которую я не проверял на месте, но там в качестве роутера стоит циска и админит её достаточно грамотный админ, сложно предположить, что в сети появится устройство с конфликтом адресов. Кстати, не так давно у меня был случай с аналочиными симптомами (Q38556) , там проблема была решена тем, что АТС убрали за NAT и паразитный траффик на DSP (провайдер её пинговал постоянно) тоже фигурировал. Кирилл Летов предположил , что имел место быть конфликт IP-адресов .
...Конфликт адресов - тоже интересная гипотеза, которую я не проверял на месте, но там в качестве роутера стоит циска и админит её достаточно грамотный админ...
В моем случае тоже был Админ грамотный, а также в его распоряжении был сервер, который не использовался и стоял все время выключенный. Иногда его включали для доступа к старым архивам.
Собственно за ненадобностью про IP сервера никто не помнил, а именно он и вызывал конфликт.
Более того - комп про конфлик даже не пишет, он тупо тянет одеяло на себя, станция не сопротивляется.
Ну а в плане мудрого администрирования: достаточно получать адреса по DHCP, и вновь подключенный комп с уже когда то зарезервированным айпишником - с ним же и подключится. Станция ему никак не помешает :(
Я конечно не сетевик, но посмотрел трейс внимательно, RTP в сторону панасоника идут с неподсчитанной контрольной суммой в UDP заголовке - вот панасоник их и ставит в бесконечную очередь на обработку.
Checksum: 0xf366 [validation disabled] - панасоник —> софтсвич
Checksum: 0x0000 (none) - а это софтсвич —> панасоник ( и так все пакеты, ни одного нормального ).
Я конечно не сетевик, но посмотрел трейс внимательно, RTP в сторону панасоника идут с неподсчитанной контрольной суммой в UDP заголовке - вот панасоник их и ставит в бесконечную очередь на обработку.
Checksum: 0xf366 [validation disabled] - панасоник —> софтсвич
Checksum: 0x0000 (none) - а это софтсвич —> панасоник ( и так все пакеты, ни одного нормального ).
Александр Николаевич, супер! Эх, по Вам 4 уровень плачет горькими слезами...
