facility

Радиус "... км" уж больно неопределенный Хотя, присоединяюсь к вопросу.

Термин "свитч" вообще используется весьма вольно :) На самом деле мне лично нужен H.323<->SIP SBC только для сигнального трафика. Media-proxy не требуется, т.к. на уровне сети обеспечивается взаимная доступность всех Media-шлюзов. На Yate такой сценарий возможен? P.S. Спасибо, что h323<->SIP более-менее нормально работает ;)

Я может чего не понял, но в 1.3 не было полноценной поддержки RAS и при попытке сделать H.323<->SIP SBC почему-то наглухо пропадал T.38. В принципе, это все, чего Yate не хватает для того, чтобы называться полноценным "софтсвитчом 4 класса" :)

Да, я понял. Спасибо!Мне в принципе и нужно было понять, что причина нетехнического характера.

Это мягко говоря не так. В EDSS1 например нельзя передать категорию абонента, а без этого вы не обеспечите абонентам hot-choice для выбора оператора междугородной связи. Hot-choice обеспечивается набором кода выбора оператора связи и значением категории = 0. Это для pre-select нужно устанавливать категорию, чтобы без набора кода выбора оператора маршрутизировать вызовы на нужного оператора МГ/МН. Подскажите пожалуйста зачем вообще нужны категории, когда всю необходимую адресную информацию можно включить в номера вызываемого и вызывающего абонентов?

Да, так уж получилось, что у нас УПАТС. Вообще 2ВСК она поддерживает, но в ограниченном виде (не поддерживается "импульсный пакет"). В дополнение возникают эксплуатационные проблемы - то приемники тоновых сигналов виснут, то линейные сигналы некорректно выдаются и т.д. При этом отсутствуют штатные средства отладки протоколов CAS. ОКС7 вообще не поддерживается, для стыковки с зоновым по ОКС7 нужен отдельный транзитный коммутатор + ~$5000. В результате ОКС7 - доп.затраты, по 2ВСК стыковаться просто не хочется. Поэтому и возник вопрос - раз технически можно добиться на EDSS1 всего того же, что и на ОКС7, то почему это нельзя?

Если в ТУ у зонового оператора нет EDSS1 (а это наверняка так), то он вас просто не присоединит. Да, Andrei, так и есть... Первоначально в ТУ присутствуют только 2ВСК и ОКС7. Мне просто не понятно чем мотивирован такой набор сигнализаций. 2ВСК - это "сильно прошлый век", а ОКС7 - это доп. расходы и, как я понимаю, не только для нас, но и для зонового оператора. Главное, что результат, достигаемый при использовании EDSS1 и ОКС7, в нашем случае одинаковый.

Всех приветствую! Имеется вопрос по ПРИКАЗу № 135 от 01.12.2005 г. "Об утверждении порядка взаимодействия сетей фиксированной телефонной связи сети связи общего пользования для целей обеспечения права абонентов и (или) пользователей этих сетей на выбор оператора связи, оказывающего услуги междугородной и международной телефонной связи при автоматическом способе установления телефонного соединения". В п.2 Приложениия №1 сказано, что "При предварительном выборе оператора связи взаимодействие сетей связи осуществляется с использованием значений категорий пользовательского (оконечного) оборудования, назначенных для обеспечения маршрутизации вызовов на сети связи операторов связи, оказывающих услуги междугородной и международной связи (далее - категория оконечного элемента сети связи)." Вопрос №1: Обязательно ли выполнять это дословно? Поясню ситуацию... Мы - оператор с лицензией на МТС. Наше оборудование поддерживает только DSS1. Как известно, в DSS1 понятие "категории абонента" отсутствует. Чтобы выполнить вышеописанный пункт приказа, нужна сигнализация, в которой понятие "категории абонента" присутствует. Из предлагаемых зоновым оператором 2ВСК и ОКС7 нам не подходит ни одна. Конечно можно установить конвертор или транзитный коммутатор с поддержкой DSS1 и ОКС7, но это минимум ~ $5000. Придумался другой вариант реализации "права абонентов на предварительный выбор оператора связи" в виде подстановки кода оператора связи к набранному абонентом номеру. Наше оборудование это позволяет. Сценарий подстановки будет выглядеть следующим образом: - Если абонент заключил договор с Ростелеком, то при наборе 84957660166 на зонового оператора будет отправлен номер 8554957660166. - Если абонент заключил договор с МТТ, то при наборе 84957660166 на зонового оператора будет отправлен номер 8534957660166. и т.д. Таким образом правила набора номера для абонента сохраняются прежними 8 - для МГ-связи, 810 - для МН-связи. Вопрос №2: Кто-нибудь уже реализовывал такую схему? Что в ней плохого/незаконного?

МОЖНО. Это называется PLAR - Private Line Auto Ringdown. Вот похожий пример - http://www.addpac.su/remote_user.htm

Как я понял, на входе TDA 200 - ISDN PRI, на выходе - 5 аналоговых абонентских линий. Включаете: со стороны TDA 200 - AddPac 1100C (http://www.addpac.su/ap1100c.htm), со стороны абонентов - AddPac 1100B (http://www.addpac.su/ap1100b.htm). На AddPac 1100C настраиваете PLAR. Схема организации связи следующая: ССОП ---E1 (ISDN PRI)--- TDA200 ---5xFXS/FXO--- AddPac1100C ---VoIP--- AddPac1100B ---5xFXS--- ТА

Мало верится в такие цифры, хотя сам с этим продуктом не знаком, да и вера в чудеса еще почему-то осталась... Название темы несколько сбивает с толку. Речь идет о выборе Softswitch или о выборе SBC с функционалом транскодирования? Почему-то мне думается, что перекладывать функции DSP на CPU и гонять Media-трафик через устройство, которое должно заниматься управлением вызовами - наверное не самые хорошие идеи. Хотя, наверное, все можно решить методом распределения нагрузки. Ведь не все вызовы требуют транскодирования, а только от некоторых устройств, Media-трафик которых и нужно направить на SBC. Для всех остальных нужно проксировать только сигнализацию.

Вызывает удивление :) И какова масштабируемость? Сколько мощностей нужно, что такие вызовы (G.711 -> T.38 и обратно) осуществлялись?

Кхм... Программная конвертация SIP/G.711 -> H.323/T.38? Если найдете решение до наступления старости, то дайте знать :)

Нда... "на зону" говорите... :) В М-200 есть одна непроверенная функция - "Извлекать категорию из первой цифры АОН (callIn_categoryFromAON)". Если она работает так, как я думаю, то категорию можно передавать куда угодно: 2ВСК, ОКС7. Даже "на зону", век воли не видать... :)

С точки зрения сети действительно никакой разницы. Другое дело - анализ работы стека RTP конкретных устройств. Я вот, например, до сих пор не могу понять при каких условиях Avaya TN2302AP начинает отбрасывать пакеты. Главное - не понятно как сосчитать кол-во отброшенных. RTCP (SR и RR), согласно прочитанному в RFC 3550, не позволяет это сделать. Подобная информация присутствует в RFC 3611 (RTCP XR discard rate), но, как я понял, мало устройств умеет этот отчет формировать. Есть какие-нибудь соображения на этот счет?

Какова методика измерения?

Да не за что. Перед самим такие же задачи стоят, поэтому рассказал, что знаю. Может совместными усилиями родится что-нибудь полезное. Боюсь, что никак :) Измерение ping'ом - не точное. Да, я примерно так и рассуждаю. Опять же повторюсь: ICMP - не может быть точным инструментом измерения пригодности канала для RTP. Он дает лишь приближенный к реальному результат, а иногда, когда устройства запрограммированы на игнорирования части ICMP, вообще не годится для измерений. Тогда надо одновременно ловить с обоих "концов" канала связи, а потом сопоставлять результаты.

Почему?

Как я понимаю, для Cisco два варианта:1 - конвертер сигнализации DSS1 <-> ОКС-7 (например, http://www.protei.ru/products/ngn/signalli...cription.html); 2 - транзитный коммутатор DSS1 <-> ОКС-7 (например, http://www.m-200.ru/?mod1=2&mod2=5) В качества третьего (судя по всему, для вас небюджетного) варианта - не строить сеть на Cisco :)

Ну почему же... Для любителей садо-мазо оставлен вариант с подключением по 2ВСК ;)

Как вариант, можно встать sniffer'ом в разрыв между VoIP-устройствами и ловить пакеты RTCP (SR, RR), в которых VoIP-устройства в течениче сеанса связи посылают друг другу отчеты с кол-вом потерянных пакетов и средним jitter'ом за интервал измерения. К сожалению, кол-во потерянных пакетов не включает в себя опоздавшие пакеты, отброшенные буфером. Увы, из продуктов open-source сам ничего подобного не нашел. Пришлось открыть RFC 3550 и написать самому на perl + Net::Pcap + NetPacket. Измерять RTT можно при помощи ICMP Echo-Request, т.е. с помощью утилиты ping или mtr. Это даст близкий результат. Разумеется, если в сети включена приоритезация VoIP-трафика с помощью DiffServ, то лучше посылаемые ICMP-пакеты маркировать таким же значением TOS-байта (параметр ping -Q). Например, иммитировать поток, аналогичный потоку из 1000 RTP-пакетов G.711/30мс, маркированных TOS-байтом 0xB8, можно так: ping -s 252 -i 0.03 -Q 0xb8 -c 1000 <ip-адрес> * параметры -i < 0.2 и -Q можно устанавливать только из под root; * не все устройства отвечают на такое кол-во ICMP Echo-Request аналогичным кол-во ответов; в некоторых предусмотрено игонорирование некоторого кол-ва пакетов, чтобы не перегружать CPU;

Тогда это все-таки VoIP-proxy. Если происходит транскодирование, то надо проверять с какими параметрами устанавливается вызов между proxy и 5350, и с какими между proxy и SIP Phone/Gateway. Попробуйте посмотреть параметры кодеков на обоих участках (тип кодека, размер payload, наличие vad) при вызове в направлении POTS -> SIP Phone/Gateway. Если транскодирования нет (все одинаково на обоих участках), нужно оценить задержку и потери пакетов, которые вносит proxy при ретрансляции RTP.

Чего гадать то? Вставьте sniffer между SIP Phone/Gateway и Router и запишите SIP/RTP/RTCP трафик.

Ну а зачем тогда писать какие-то непонятные названия? Попонтоваться чтоли? ;)

Судя по вашим словам, рабочая группа SIGTRAN очень давно ерундой занимается. Изобретает какой-то SCTP, который видимо никому не нужен :) Что такое МС240?