Comments 14
Само устройство конвертирует E1 в протокол TDMoE. Так что между asterisk и elf2 не должно быть маршрутизатора. Натыкался на упоминания, что мол работает в пределах только одного свитча. Это не так, у меня прокинут vlan через 4 свитча.
Мне вот интересно — а что произойдет, если влить много трафика в один из транков? Ну допустим в первый и четвертый свитчи воткнуто по компьютеру и качается много трафика. Вы QoS настраивали? А еще при заполнении портовых буферов на свитчах возникнет небольшой джиттер — как TDMoE переживет это, какой у него джиттер буфер?
Ну и наконец — зачем мучиться с подобными костылями, если можно было поставить полноценный E1-SIP шлюз, и с астериском общаться по сипу?
Про буфер лучше глянуть документацию/суппорт производителя. У меня проблем с джиттером нет.
Костыль тупо дешевле, причем в разы.
Костыль тупо дешевле, причем в разы.
А вы тестировали? Вот есть цепочка из четырех свитчей (словом «дофига» это не описать). Пустите iperf в десяток потоков между подключенными к ними компьютерами, и чтобы линковая скорость у каждого из компьютеров соответствовала транкам. Что-то мне подсказывает, что начнут происходить очень нехорошие и одновременно забавные вещи.
Если где-то говорилось про «чтоб всё к одному свитчу подключалось», то, возможно, причина в нетерпимости протокола к потерям пакетов и неуверенности вендора в том, что администратор сумеет выполнить правильные настройки на транках.
Поискав навскидку, первым на глаза попался www.pbxware.ru/catalog/voip_shlyuzy/alvis/voip_shlyuz_alvis_gw_2e1_rackmount_version/. Разница в цене — раза в два. И потоков тоже два.
Если где-то говорилось про «чтоб всё к одному свитчу подключалось», то, возможно, причина в нетерпимости протокола к потерям пакетов и неуверенности вендора в том, что администратор сумеет выполнить правильные настройки на транках.
Поискав навскидку, первым на глаза попался www.pbxware.ru/catalog/voip_shlyuzy/alvis/voip_shlyuz_alvis_gw_2e1_rackmount_version/. Разница в цене — раза в два. И потоков тоже два.
Да скорее всего так и есть. При наличии времени надо будет развлечься.
По поводу alvis они недавно появились, и очень низкая цена для устройств такого класса, у вас есть положительный опыт их использования?
Мне было бы очень интересно на них посмотреть, но абсолютно незнакомый бренд и агрессивный маркетинг (предлагают покупателям сами все настроить) наводят на мысль о контейнере из Китая и компании из 2,5 человек тут, которые по реализации данного продукта с веселым гиканьем разбегутся.
По поводу alvis они недавно появились, и очень низкая цена для устройств такого класса, у вас есть положительный опыт их использования?
Мне было бы очень интересно на них посмотреть, но абсолютно незнакомый бренд и агрессивный маркетинг (предлагают покупателям сами все настроить) наводят на мысль о контейнере из Китая и компании из 2,5 человек тут, которые по реализации данного продукта с веселым гиканьем разбегутся.
У вас slip и skip счетчики в консоли и в dahdi драйвере не растут? В консоли видно, что вы синхронизируте эльф с внутренних часов (clock = internal, скорее всего нужно брать синхронизацию с атс, а потом передавать её на asterisk), а в dahdi.conf у спана пишете 0 в конце, т.е. опять же внутренняя синхронизация. Слышны будут щелочки и факсы ходить не будут.
На счет того, что плохо tdmoe работает не соглашусь, операторы используют такой протокол в своих сетях. Если ваша сеть затыкается на нескольких пользователях, то стоит задуматься о соединении коммутаторов более скоростными линиями.
Сказано, что не работает через маршрутизатор из-за того, что в пакетах не указаны ip-заголовки и по умолчанию маршрутизатор отбросит такие пакеты.
На счет того, что плохо tdmoe работает не соглашусь, операторы используют такой протокол в своих сетях. Если ваша сеть затыкается на нескольких пользователях, то стоит задуматься о соединении коммутаторов более скоростными линиями.
Сказано, что не работает через маршрутизатор из-за того, что в пакетах не указаны ip-заголовки и по умолчанию маршрутизатор отбросит такие пакеты.
>На счет того, что плохо tdmoe работает не соглашусь, операторы используют такой протокол в своих сетях.
Какие-то операторы используют кольца через весь город на L2 свитчах, не умеющих даже быстрые вариации STP (про MPLS или протоколы для кольцевых топологий и речи нет). Это не значит, что так надо делать или даже что это хорошо работает. И как оно все-таки переживает небольшие потери пакетов? Весь поток случайно не упадет с ошибкой до ручного пинка?
Да, IP поверх TDM до сих пор где-то используется, но вот про использование TDM поверх пакетных сетей мне слышать не доводилось.
Какие-то операторы используют кольца через весь город на L2 свитчах, не умеющих даже быстрые вариации STP (про MPLS или протоколы для кольцевых топологий и речи нет). Это не значит, что так надо делать или даже что это хорошо работает. И как оно все-таки переживает небольшие потери пакетов? Весь поток случайно не упадет с ошибкой до ручного пинка?
Да, IP поверх TDM до сих пор где-то используется, но вот про использование TDM поверх пакетных сетей мне слышать не доводилось.
Как переживает небольшие потери? Точно весь поток не упадет :) Работает 1 год 2 таких модуля без проблемно.
Исходя из мануала работает TDM через Ethernet (не IP) примерно так — фреймы пишутся в кадры и наоборот. Есть внутренний буфер. Если он переполняется или не успевает отправиться возникают проскальзывания потока, что в общем то допустимо, все протоколы, используемые поверх этих потоков умеют восстанавливать утерянные пакеты.
Сейчас PBX показывает, что на два потока eth1 receive 605.83 KB/s, так что трафик тут небольшой.
В рекомендациях так же указано, что хорошо это работает когда висит на отдельном физическом интерфейсе и ненагруженном коммутаторе.
Если вы хотите сказать, что все это плохо, то лучше предложите и расскажите об альтернативах!
Исходя из мануала работает TDM через Ethernet (не IP) примерно так — фреймы пишутся в кадры и наоборот. Есть внутренний буфер. Если он переполняется или не успевает отправиться возникают проскальзывания потока, что в общем то допустимо, все протоколы, используемые поверх этих потоков умеют восстанавливать утерянные пакеты.
Сейчас PBX показывает, что на два потока eth1 receive 605.83 KB/s, так что трафик тут небольшой.
В рекомендациях так же указано, что хорошо это работает когда висит на отдельном физическом интерфейсе и ненагруженном коммутаторе.
Если вы хотите сказать, что все это плохо, то лучше предложите и расскажите об альтернативах!
>Работает 1 год 2 таких модуля без проблемно.
Ну это несерьезно. Вот если бы сотни, разбросанные по разным городам и разным операторам связи, в идеале с периодически падающим WAN каналом между шлюзом и PBX — другой разговор.
>фреймы пишутся в кадры и наоборот.
«Фрейм» и «кадр» — синонимы.
>все протоколы, используемые поверх этих потоков умеют восстанавливать утерянные пакеты
Не припомню у q.931 механизмов подтверждений и перепосылки сообщений. H.323 полагается на TCP в этом вопросе. То есть на нижележащие протоколы.
>В рекомендациях так же указано, что хорошо это работает когда висит на отдельном физическом интерфейсе и ненагруженном коммутаторе.
У случае топикстартера «прокинут vlan через 4 свитча». Рискну предположить, что QoS там ни в каком виде не существует, а еще есть неслабая переподписка.
>то лучше предложите и расскажите об альтернативах!
А что рассказывать? Проще всего не передавать TDM поверх пакетных сетей. Ставится шлюз, на одном плече которого, например, E1, а на другом тот же SIP в сторону PBX. Вариант — MGCP/SCCP, где PBX почти полностью управляет шлюзом. Всё это легко поднимается, сопровождается и траблшутится (в моем случае — те самые много сотен устройств, большинство из которых уже много лет работает беспроблемно, а голосовой трафик в g.711 на отдельных участках достигает сотен мегабит, и это всё свой трафик, мы не оператор связи). А решения вроде TDMoE — какие-то костыли вроде небезызвестного SONET over IP/MPLS, единственное условное преимущество которых — чуть большая дешевизна. По мне, приличные шлюзы вроде Медиантов (если потоков много) или цискиных роутеров (если потоков мало) ничтожно дешевы по сравнению с теми системами, которые собственно создают или принимают вызовы.
Ну это несерьезно. Вот если бы сотни, разбросанные по разным городам и разным операторам связи, в идеале с периодически падающим WAN каналом между шлюзом и PBX — другой разговор.
>фреймы пишутся в кадры и наоборот.
«Фрейм» и «кадр» — синонимы.
>все протоколы, используемые поверх этих потоков умеют восстанавливать утерянные пакеты
Не припомню у q.931 механизмов подтверждений и перепосылки сообщений. H.323 полагается на TCP в этом вопросе. То есть на нижележащие протоколы.
>В рекомендациях так же указано, что хорошо это работает когда висит на отдельном физическом интерфейсе и ненагруженном коммутаторе.
У случае топикстартера «прокинут vlan через 4 свитча». Рискну предположить, что QoS там ни в каком виде не существует, а еще есть неслабая переподписка.
>то лучше предложите и расскажите об альтернативах!
А что рассказывать? Проще всего не передавать TDM поверх пакетных сетей. Ставится шлюз, на одном плече которого, например, E1, а на другом тот же SIP в сторону PBX. Вариант — MGCP/SCCP, где PBX почти полностью управляет шлюзом. Всё это легко поднимается, сопровождается и траблшутится (в моем случае — те самые много сотен устройств, большинство из которых уже много лет работает беспроблемно, а голосовой трафик в g.711 на отдельных участках достигает сотен мегабит, и это всё свой трафик, мы не оператор связи). А решения вроде TDMoE — какие-то костыли вроде небезызвестного SONET over IP/MPLS, единственное условное преимущество которых — чуть большая дешевизна. По мне, приличные шлюзы вроде Медиантов (если потоков много) или цискиных роутеров (если потоков мало) ничтожно дешевы по сравнению с теми системами, которые собственно создают или принимают вызовы.
А это не шлюз, а модуль внешний, считай банк каналов для asterisk. Задача не в передаче потока по Ethernet же!
это ваши циски — костыли ненужные, чтобы вас кормить, знатоков этого проприентарного навоза. Задача была решена у топикстартера быстро, дешево, просто и надежно. Что ещё нужно?
это ваши циски — костыли ненужные, чтобы вас кормить, знатоков этого проприентарного навоза. Задача была решена у топикстартера быстро, дешево, просто и надежно. Что ещё нужно?
>А это не шлюз, а модуль внешний, считай банк каналов для asterisk.
В этом и главная проблема.
>это ваши циски — костыли ненужные, чтобы вас кормить, знатоков этого проприентарного навоза.
А продукция компании Parabel случаем не проприетарна и не навоз?
Или, может, вы считаете, что «циски» очень сложные, и на настройку фич уровня описанных в топике может потребоваться более чем час-два (с нуля, без предыдущего опыта работы с этим оборудованием)?
Я не уверен ни про «быстро», ни про «дешево» (нередко экономия капекса означает потери в опексе), ни про «просто» (сам черт ногу сломит в этих русскоязычных таблицах), ни про «надежно» (две железки, не глючащие аж целый год — это потрясающая статистика, но все-таки...).
Ну хозяин — барин.
В этом и главная проблема.
>это ваши циски — костыли ненужные, чтобы вас кормить, знатоков этого проприентарного навоза.
А продукция компании Parabel случаем не проприетарна и не навоз?
Или, может, вы считаете, что «циски» очень сложные, и на настройку фич уровня описанных в топике может потребоваться более чем час-два (с нуля, без предыдущего опыта работы с этим оборудованием)?
Я не уверен ни про «быстро», ни про «дешево» (нередко экономия капекса означает потери в опексе), ни про «просто» (сам черт ногу сломит в этих русскоязычных таблицах), ни про «надежно» (две железки, не глючащие аж целый год — это потрясающая статистика, но все-таки...).
Ну хозяин — барин.
Так в чём проблема то?
вы вообще читали название статьи?
Подключать одну атс к другой через третью, как предлагаете вы — вот проблема.
Парабел делает отличное железо и хорошо его поддерживает.
Циску настроить — просто, но она не нужна, лишние мозги и заморочки.
Русскоязычные таблицы не относятся к оборудованию парабел — это консоль русской атс, соглашусь, выглядит пугающе и непонятно.
На счет надежности — сколько компонентов используется в циске? А тут только нужные для работы, причем мировых производителей, а не домашних мастеров, как вы думаете.
Конечно, в эльфе нет мозгов, он делает только то, что нужно, в нем нет ОС.
Вы просто привыкли везде циски ставить с расчетом на изменение ТЗ и теперь другого не видите.
вы вообще читали название статьи?
Подключать одну атс к другой через третью, как предлагаете вы — вот проблема.
Парабел делает отличное железо и хорошо его поддерживает.
Циску настроить — просто, но она не нужна, лишние мозги и заморочки.
Русскоязычные таблицы не относятся к оборудованию парабел — это консоль русской атс, соглашусь, выглядит пугающе и непонятно.
На счет надежности — сколько компонентов используется в циске? А тут только нужные для работы, причем мировых производителей, а не домашних мастеров, как вы думаете.
Конечно, в эльфе нет мозгов, он делает только то, что нужно, в нем нет ОС.
Вы просто привыкли везде циски ставить с расчетом на изменение ТЗ и теперь другого не видите.
Sign up to leave a comment.
Интеграция Asterisk c minicom DX-500 при помощи ELF2-AE