Господа!

Кто сталкивался с арендованными каналами E1 через IP-облако (т.н. TDM over IP MPLS). Меня что интересует - любые IP-сети даже с протоколами туннелирования и акселерации (такие как напр. MPLS) априори в ЧНН страдают от "заторов", но в пакетных технологиях (Ethernet, Wi-Fi и т.д.) - это не заметно так как это устраняется повторной передачей пакетов и пр., а у нас 2 АТС работают, можно сказать в полном он-лайне, т.к. есть цикловая синхронизация и "опоздавший" 1 пакет нельзя поставить перед 2 (датаграмный метод).
Поэтому, я предполагаю что станции в таком случае, при "заторах" в IP-сети будут "бить" ошибки.. а при больших "задержках" - вообще пропадать..

Поделитесь опытом...

Не очень понимаю о чём тут говорить...
При плохом канале вы начнёте получать ошибку L3error, затем и L2- по сути канал развалится и связи не станет.

В IP сетях есть такое понятие как приоритезация трафика. Если вы поднимаете TDM over IP то без этого не обойтись.

Кроме приоретизации потребуется ещё и гарантированная полоса пропускания канала, т.к. для 32 тайм слотов фактически зарание и постоянно резервируется поток передачи данных.
Мы используем до 20 TDMoIP каналов для объединения АТС Меридиан и Панасоник ( Q.Sig ). Измерения показывают, что если нет ни одного разговора в потоке или их много, генерится одинаковый трафик.

В IP сетях есть такое понятие как приоритезация трафика. Если вы поднимаете TDM over IP то без этого не обойтись.

далеко не все операторы предоставляют приоритизацию, появится один участок без оного и все старания на смарку. для такой технологии однозначно требуются выделенные каналы связи, но они очень дороги, я бы воспользовался более неприхотливым способом: по Е1 соединился либо с ip-атс с потоком, либо с sip-e1 шлюзом. В этом случае, если бы появились проблемы с каналом, то были бы просто пропадания связи, а не "падение" всего потока.

Да, тот TDM over MPLS, который моб. и пр. операторы пытаються нам "втюхать" (СМ.ВЛОЖЕНИЕ) - не подходит, единственное что можно поставить - это "железки" TDM over IP MPLS GATE, которые передают в приоритетном режиме цикл.синхронизацию, а контент по мере появления или SIP/E1 Gateway - вариант, но опять же как это работает практически??

Да, тот TDM over MPLS, который моб. и пр. операторы пытаються нам "втюхать" (СМ.ВЛОЖЕНИЕ) - не подходит, единственное что можно поставить - это "железки" TDM over IP MPLS GATE, которые передают в приоритетном режиме цикл.синхронизацию, а контент по мере появления или SIP/E1 Gateway - вариант, но опять же как это работает практически??

В прилагаемом рисунке нет и намека на TDMoIP. Там довольно распространенное решение.

Yaroslav_73
Картинка "ни о чем".

далеко не все операторы предоставляют приоритизацию, появится один участок без оного и все старания на смарку.
вряд ли таких можно назвать "операторами"
тем более автор пишет о сети MPLS

по рисунку полностью согласен с колегами- он ниочем, там и намека нет на TDMoIP. Обычный, один из вариантов подключения существующей атс к ip-провайдеру, причем не самый дешевый:)

2aMster
а чем Ростелеком не оператор?:), у нас он не предоставляет приоретизацию, как бы мы не "помечали" пакеты, они идут общим скопом с другими:)

2aMster
а чем Ростелеком не оператор?:), у нас он не предоставляет приоретизацию, как бы мы не "помечали" пакеты, они идут общим скопом с другими:)
Он местами конечно оператор, а местами шаражкина контора.
Надо дрючить до посинения.

...как бы мы не "помечали" пакеты, они идут общим скопом с другими:)
"Чужие" (клиентские) атрибуты пакетов(в частности флаги приоретизации), если их обработка не оговорена с админом провайдерской сети(согласно договору о предоставлении услуг, например), зачищаются.
Это правило грамотного администрирования стыков клиент/провайдер.
Так что РТК здесь прав.:)

"Чужие" (клиентские) атрибуты пакетов(в частности флаги приоретизации), если их обработка не оговорена с админом провайдерской сети(согласно договору о предоставлении услуг, например), зачищаются.
Это правило грамотного администрирования стыков клиент/провайдер.
Так что РТК здесь прав.:)

полностью согласен. поэтому, чтобы не заморачиваться, они просто не предоставляют услугу.:)

Он местами конечно оператор, а местами шаражкина контора.
Надо дрючить до посинения.

я очень часто этим занимаюсь, т.к. они нам предоставляют много разных услуг. Даже начал получать от этого удовольствие:)

SIP/E1 Gateway - вариант, но опять же как это работает практически??

Е1 - канальный, SIP - пакетный. TDMoP пакеты могут перемешиваться в TDMoP туннеле и самое противное - теряться. На оконечных сторонах , конечно, пытаются отсортировать, но что делать если он - потерян? 2 метода: либо копирование предыдущего фрейма, либо забивание константой (той же D5).

Проблемы в PRI при таком TDMoP возникают по одной простой причине - это сигнальный асинхронный транспорт поверх синхронного. Плюс создатели PRI и не догадывались, к чему люди в 21 веке дойдут для экономии волокна у магистралов.. В том же Астериске частично не дописаны машины состояния PRI- наступает ступор.

Немаловажен и вопрос синхронизации. В TDMoP линк получает псевдо-recovery клоки. Их стабильность в некоторых случаях вызывает проблемы. Особенно при больших задержках в линке.

Плюс обычно вся TDMoP подноготная остается в руках провайдера, клиенту не так просто сделать ping или iperf как в случае SIP/RTP.

В случае схемы
УПАТС1 =e1=> шлюз e1/sip - sip == канал IP оператора => шлюз e1/sip = E1 => УПАТС2

Все потоки e1 оказываются - локальными. У них локальный источник синхронизации, на АТС и шлюзе - ноль алармов, старый-добрый PRI - спокоен.
Все проблемы решаются уже нативно: на уровне SIP/RTP. Можно и wireshark запустить и посмотреть что и как, можно и трассу iperf прогнать на UDP длиной 160 байт полосой 2М и попинать прова если гнилые свичи на последней миле.
Можно и строить не только решения точка-точка, можно организовать филиальную сеть каждый с каждым без гимора..


Раскрутили меня почти на статью)

Вообщем резюмирует все вышесказанное схемка из Мануала на HiPath 3000 (недавно увидел). Единственное что вместо LAN должно быть все что угодно - WAN, IP Network, но только не LAN. И H.323, а с ним и протокол CorNET-IP, на свалку истории как громоздкий, не гибкий, несовместимый с Интернет и т.д. Да здравствует SIP!

Ни совсем всё вы понимаете должным образом, лучше к Заврику обратитесь он сертифицировал своё оборудование вчера, сегодня. Сам на подъеме, готов к новым проектам и решениям, все секреты и расскажет :D.