ru.cisco

 
 - RU.CISCO ---------------------------------------------------------------------
 From : Roman Nikitchenko                    2:464/36       05 Aug 2002  17:51:42
 To : All
 Subject : Re: VoIP signaling and media addresses
 -------------------------------------------------------------------------------- 
 

 Vladimir Kravchenko wrote:
 
 >From: Vladimir Kravchenko <jimson@mostcom.ru>
 >
 >  
 >
 >>>>>>"RN" == Roman Nikitchenko writes:
 >>>>>>            
 >>>>>>
 > RN> Как мнинмум для Load balancing и роутинга по QoS на основании внешнего
 > RN> модуля принятия решений. У cisco, насколько я понимаю, такое должно
 > RN> строиться на основе Netflow, но я что-то пока не видел.
 >load balancing на основании данных по IP трафику ?
 >весело но непонятно зачем, вопрос балансировки ставился, возможно это будет
 >реализовано, но немного по другому
 >
 
 Да, пока все это лишь "возможно". Hа самом деле речь идет о балансировке 
 на публичных каналах. где посторонняя нагрузка меняется динамически и у 
 нас даже не всегда есть возможность прямо получить данные об этой 
 нагрузке... Hо есть желание использовать эти дешевые каналы. RSVP - 
 хорошо, конечно, но это не тот случай. А высказывания вроде 'VoIP на 
 ethernet must die' исходят только от буржуев или от тех, кто никогда не 
 пользовался xDSLными удлинителями этого самого ethernet-а для 
 корпоративных сетей. Все мешается в одну кучу, ставить хорошие роутеры 
 со всех концов - очень уж накладно. Короче, применение такому роутингу есть.
 
 > RN> А насчет номера - как насчет proxy, реализующего hunting group или
 > RN> call deflection на лету... ?
 >это называется LAR, почитай как это реализовано, и удивись :)
 >
 
 Удивляться не буду, LAR - самое простое решение вопроса. Почитай как это 
 концепция реализована на www.vovida.org в случае внешних условий, 
 динамически влияющих на сам состав группы, порядок ее просмотра и т.д. 
 Вот это решение действительно динамическое и первое приложение у него - 
 телефонизация офиса (зависящая от времени и т.д. карта роутинга, 
 голосовые меню и другие feature server-а ). LAR не даст этого.
 
 > правил трансляций может быть сколь огодно много.
 >
 
 ... еще раз повторюсь: иногда нужна не трансляция, а генерация номеров. 
 Это, кстати, относится и к hunting group, если сама разводка по офису 
 сделана средствами ведомственной АТС. Как минимум трансляция должна быть 
 динамическая.
 
 > RN> соответствующая процедура H.245, за счет отдельных ее элементов на
 > RN> кошках работает T.38 (udp факсы с подменой голосового канала на время
 > RN> передачи факса ).
 >Пространно сказано. Я лично совсем не понял при чем тут указание кодека
 >"налету".
 >
 
 Говорил не я, не знаю, что в оригинальном письме имелось ввиду под 'на 
 лету', но как минимум payload-type никто в RTP потоке динамически менять 
 не запрещал.
 
 > T.38 передается по отдельному логическому каналу,
 >
 
 ... который все равно отличается только payload type и LC номерами.
 
 > при этом при
 >детекте факса вначале идет разрушение логического канала для передачи audio
 >и затем открывается логический канал под T.38. Возможно и обратной
 >проключении audio канала, но киски частелько рвут соединение при
 >"возвращении" голос
 >
 
 Да, есть такое, 8) по моему личному опыту еще чаще они это делают при 
 уходе на T.38 при использовании IOS-ов вроде 12.2(4)T и т.д. А 
 исполльзование Q931 IE segmented-message в Q931 Facility ( на пакетных 
 сетях, да еще и криво заполненного! ) меня просто повергло в глубокое 
 удивление минуты на 2...
 
 Мда, о приличных фичах можно спорить долго, о их правильной реализации - 
 еще дольше. А реально, учитывая объем воровства софта в xUSSR, воз и 
 ныне там. IOSы неподобранные, снятые с левых FTP ( может в Москве и не 
 совсем так... :) ), прокси самописные, подавляющее большинство - на 
 стеке openH323, который хорошим назвать трудно, а пропатчить его - 
 работы немеряно и подходит только для частных условий ( вон, только что 
 груду наследников написал, фактически с полным перекрытием, чтобы 
 получить от генератора звонков на средней машине хотя бы 8x30 ).
 
 P.S. Автор оригинального письма, видимо, задал вопросы в пустоту, без 
 особых раздумьев.
 
 >
 >--
 >Vladimir Kravchenko / PK Mostcom JSC / system engineer
 >Tel: +7 095 2312255 / UIN: 132038843 / Email: jimson@mostcom.ru 
 >  
 >
 
 -- 
 
 С уважением,
 Роман Hикитченко, Trifle Co., Ltd.
 _,,,_|\_/|_,,,_
 
 --- Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.1b) Gecko/20020722
  * Origin: Apex NCC Public Internet News Server (2:464/36@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор