Перейти к содержимому
Калькуляторы

Николя

Пользователи
  • Публикации

    8
  • Зарегистрирован

  • Посещение

Все публикации пользователя Николя


  1. Уважаемый leveler, по-моему, со звонками с AddPack'а разобрались. Проблема, как было видно по дампам, именно в AddPack'е, который не хотел переоткрывать каналы. Благо, запрос переоткрытия каналов на МКД можно отключить конфигурационными механизмами. Но с Адпаком я вам настоятельно рекомендую разобраться, т.к. при интервекинге SIP/H.323 любой реинвайт вызовет переоткрытие каналов.
  2. В том объеме, как это описано в pdf'ке, функционал SBC действительно реализован. В текущей версии, действительно, не густо, но расширение готовится. ram_scan... не врет. Если media-трафик разговорной сессии будет замкнут на SSW, то в случае аварии абонент попадет в тишину. Поставляемый RHL все таки берется не с потолка. Он здорово переработан нашими разработчиками для работы с нашим ПО. Линукс поставляемый на сервере - часть общей системы, гарантирующая ее работоспособность. Думаю, что обвинение в "вешаньи на покупателя" малоконструктивны.
  3. Инженер Протея тут кажется я один, постараюсь ответить... А почему SoftSwitch class 4 должен выполнять функцию SBC? Он успешно выполняет функции SSW class 4, в этом и есть его назначение. И вообще, от куда вы взяли SBC, в текущих версиях MKD этой функциональности не заявляется. Я так понимаю, речь опять же про МКД. Смотрите какая штука... В общем случае media-трафик не замыкается на SSW, а проходит напрямую между абонентскими устройствами. В этом случае при аварии никакого разрыва соединений не будет. Поделитесь секретом, а зачем?
  4. Сложно с вами, ram_scan... У вас деструктивный взгляд на проблему. А должен быть созидательный. Поведение с вашей стороны, начиная с мелких тычков типа "неправильно (как обычно)..." до откровенного поливания говном, не настраивают на созидательный лад, согласитесь. Если есть проблема, ее нужно обсуждать и разруливать, а вы пока ограничиваетесь только радостными воплями, как Протей плохо работает! А в реальности это далеко не так. Есть параметр, помеченный как OPTIONAL. В певом TCS он должен быть, в последующих - может не быть. По-этому, он и является опциональным. Он опционален относительно сообщения, а не относительно оборудования (типа в оборудовании он может быть задан, а может не быть задан). Он должен быть задан всегда и должен передаваться в первом сообщении. См. официальный документ ITU-T http://www.itu.int/rec/dologin_pub.asp?lan...&type=items Из какого пальца вы высосали "может передаваться (если передается)" мне не ясно.
  5. Я, конечно, не филолог, но предложил бы следующую трактовку. "Опциональный параметр" - значит, что в общем случае, он необязательный, его наличие или отсутствие определяется конкретной ситуацией. Анализируя ситуацию для параметра multiplexCapability в сообщении TerminalCapabilitySet, можно прийти к выводу, что этого поля может и не быть, но первое TCS должно его включать, на что прямо указывает AnnexB.2.2 рекомендации Н.245.
  6. Уважаемый leveler, ну ведь обсуждали этот вопрос чуть выше.
  7. С башорга (Не смог удержаться)

    Тебе повезло, ты не такой, как все, Ты работаешь в офисе-е-е (С)