Присоединяюсь. Скорее всего у провайдера настроен "ip unnumbered" но не включен "arp proxy". Впрочем, в данном случае может быть все что угодно - зависит от изобретательности оного.
Вы уверены что там мультикаст?
Если да, то можете переключить УЖЕ РАБОТАЮЩУЮ приставку из ADSL-модема в комп со сниффером, и попереключать каналы.
Можете снять сниффером поток с неуправляемого коммутатора (уже советовали ниже).
Куда более сложной задачей является сопоставление мультикаст-адреса и названия канала. Для этого нужно либо выдернуть список каналов (в m3u, или типа того), либо скриптом парсить поток, выжидая появления в нем служебной информации, либо составлять вручную.
Аскар А, а, ну тогда остается только сам SIP-сервер.
TCP-сессия устанавливается, данные ходят. Почему сервер не отвечает - не понятно. Может, у него в логах что-то?
У Вас через этот канал пинги проходят ?
ping -l 1472 -f 172.x.x.10 (для Windows)
ping -l 1472 -f 172.x.x.11 (для Windows)
ping -s 1472 -Mdo 172.x.x.10 (для Linux)
ping -s 1472 -Mdo 172.x.x.11 (для Linux)
Судя по скриншотам, TCP-сессия устанавливается, а вот при передаче данных что-то уже непонятное. Пока смотрел в маленькую картинку глаза поломал. Выложили pcap-дамп чтоли... А так не понятно в TCP ли дело, или в SIP-сервере.
Для FTP (если вы используете именно FTP, а не SCP) для решения большинства проблем достаточно переключить режим с пассивного на активный (или наоборот). Должно настраиваться в подключении.
Если используете SCP - то где-то закрыт доступ.
0rype4uk, пишите как должно выглядеть со стороны, без упоминания Астериска вообще. Знающий * разработчик сам разложит задачу на имеющийся функционал, а что останется - доработает.
У Вас ведь задача из соседнего вопроса - про рекламу во время ожидания? Так и пишите - звонящий попадает в очередь. Вместо музыки ему проигрывается рекламное сообщение. Список проигранных сообщений должен задаваться в таком-то формате. Факт полного проигрывания сообщения звонящему должен отображаться так-то. Оператору, который примет вызов должен всплыть сообщение о необходимости задать вопрос "вы прослушали рекламу про ХХХ? интересна ли вам эта реклама?" и т.д.
Чем более общими словами Вы опишите желаемое, тем больше пространства для маневра и свободы будет у разработчика!
Можно настроить переадресацию вызовов на другой телефонный номер при неответе, занятостими безусловно (все по отдельности): на самом телефоне (в меню), через отправку USSD команды (гуглить call forwarding codes, либо на сайте оператора), в ЛК оператора связи (может и не быть).
С SMS сложнее, скорее всего настроить не получится.
Совсем не уверен, но мне кажется, что там что-то вроде WiFi Calling. В этом случае в явном виде логин/пароль не используется, а аутентификация осуществляется через SIM-карту.
Это только предположение. Скорее всего оператор не изолирует абонентов (чтобы "обменивались" локальным трафиком, имели доступ к локальным ресурсам - "файлопомойкам"), а кто-то из абонентов непроизвольно "расшаривает" интернет. Так что ошибки у оператора явно нет, она в настройках у какого-то из его абонентов.
Опасаться явно не стоит, но лучше все-таки кабель от оператора включать в роутер, а не на прямую в ПК.
protsey, получается, обе стороны под Вашим управлением? И Wireshark из PCAP-дампа с обоих сторон в обоих случаях (рабочая и не рабочая конфигурация) не "видит" никаких проблем, файл проигрывается одинаково?
Смотря какая степень "защищенности". Определить факт звонка, его длительность можно и в зашифрованном канале (если не принять дополнительных мер), так что установите для себя меру защищенности, а там уже и решения наметятся.
Там где у Вас запрещающее правило DROP поставьте галочку Log, затем включите логирование правил firewall - System->Logging->Rules->ADD, Topics = Firewall, Action=Memory. Сделайте ipconfig /renew. В логи должна упасть строчка о блокировке пакета, кидайте ее сюда.
DTMF по сети GSM(или 3G) идет в голосовом тракте. Шлюз TG100, получая его в RFC2833 или INFO сам конвертирует в звуковые тоны. Может быть он делает это слишком коряво, поэтому целесообразно слать DTMF в его сторону в режиме INBAND.
Если это не помогает (а судя по сообщению, так и есть), то играть с длительностью посылок, интервалами, а также параметрами Gain на GSM-шлюзе.
Посмотрите, нет ли на TG100 возможности записи звука с канала в формате raw (на станциях Yeastar с pri и bri есть, а начинка там одинаковая что и для gsm). Если есть - откройте в Audacity, посмотрите на спектры посылок. Если все четко, без шумов и помех, то увы, голос портит или сам модуль GSM, или мобильная сеть.
Внутри Yeastar стоит Asterisk, ваша CRM сможет с ним общаться через AMI (Asterisk Manager Interface).
Где ставить - зависит от деятельности компании. Если бизнес-процессы заточены под внутреннюю связь (компания самодостаточна, главное обеспечить связь между сотрудниками) - то ставить в офисе, чтобы не зависеть от Интернета (внутренние звонки будут работать и без него). Если главное - ответить звонящему клиенту, то лучше АТС поставить в ДЦ поближе к поставщику телефонии (даже если ваш офис будет без интернета/электричества/полыхать в огне, вызовы можно перенаправить на мобильные телефоны сотрудников, которые хотя бы скажут "АЛЁ", извинятся за ситуацию и пообещают перезвонить в ближайшее время). Но не стоить забывать про безопасность - размещать в паблик интернете SIP-сервер со слабыми паролями не стоит.
Leytenant, смотря какая аппаратная IP АТС. Зачастую в таких "аппаратных" решениях внутри стоит Asterisk, а управление через сильно урезанный (по сравнению с возможностями *) веб-интерфейс. Конечно, голый * освоить сложней, но понимание его работы облегчит видение всей системы телефонии.
Лучше, конечно, ставить на отдельный сервер/виртуалку.