> позволяет пользователям отслеживать АТС при быстром наборе помощью до 24 виртуальных BLF-клавиш.
> включая передачу вызова
> запись вызова
> Стандартный SIP-программофон
Пожалуйста, попробуй Google-translate — мне кажется, он лучше переведет в автоматическом режиме.
Ага, понял. Пара мнений:
1. patches.kcare.com — клево, но хочется понимать какие уязвимости есть именно на данной конкретной машине. Т.е. хочется diff'a а не описания latest bunch'a.
2. Roll-back нужен. Вот просто потому, что не то что сервис-провайдеры без этого не должны жить, но и интерпрайз, будь он неладен.
3. Хочется ж интеграции. С системой мониторинга, к примеру. Хорошо, если на всем парке одно и то же ядро, но по факту не всегда даже ось-то одна и та же =)
Это очень энтерпрайзно, конечно, но вопрос есть: какие все-таки ограничения у продукта? Какого рода патчи он не сможет применить?
И еще, если говорить о «бизнес-критичных» серверах, то есть такие вопросы:
— Как перед применением отревьюить список патчей?
— Как откатить последний примененный банч патчей?
— История применения патчей?
— Возможна ли периодическиая проверка без фактического обновления, только нотификация?
> Опять неверное утверждение.
Я не про общий случай, а про ситуацию, когда нат задает соответствие srcHost:srcPort — dstHost:dstPort. Как работает в общем случае я прекрасно знаю.
Нет, не любой способ будет костыльным. Если пара srcHost:srcPort соединения определяется на транспортном уровне, то не требуется модифицировать служебные заголовки протоколов верхних уровней. А это уже почти «безкостыльное» решение.
Два хоста за симметричным НАТом, действительно, нерешаемая задача без использования дополнительных узлов. И TURN тут был бы актуален.
В итоге мы бы получили только одну исключительную топологию, а не неопределенное количество =)
ZRTP — конкретная реализация Sercure RTP. Так что, по-прежнему, необходимо установить SIP сессию и в ней объявить медиа-порты. Затем гнать медиа уже в новом UDP-соединении.
STUN работает, если находится на том же хосте, что и целевой. Будем поставлять STUN сервер с каждой клиентской софтиной? Да и как я уже отвечал, для чего придумывать костыли, когда протокол жестко не предопределен?
P.S.: Для однозначности, я пользуюсь терминологией из вики.
Здорово, хорошее расширение. Но TURN предполагает, на сколько я знаю, наличие некоего релея для проксирования трафика. Кто будет выступать в его роли в нашем случае?
Так или иначе, что при использовании SIP, что Jingle придется приделывать костыли, надеясь, что все варианты топологий будут перекрыты. Мне кажется, логичнее было бы использовать протоколы совмещающие сигнализацию и медиа и задающие рабочие порты на транспортном уровне.
Действенный вариант, принимается =) Хотя, при наличии SIP TLS\SIPS и SRTP, использовать шфированный туннель только чтобы обойти проблему NAT'а, ИМХО, нелогично. Все-таки средства надо выбирать сообразно поставленным задачам.
Да, теперь в Амстердаме.
> включая передачу вызова
> запись вызова
> Стандартный SIP-программофон
Пожалуйста, попробуй Google-translate — мне кажется, он лучше переведет в автоматическом режиме.
1. patches.kcare.com — клево, но хочется понимать какие уязвимости есть именно на данной конкретной машине. Т.е. хочется diff'a а не описания latest bunch'a.
2. Roll-back нужен. Вот просто потому, что не то что сервис-провайдеры без этого не должны жить, но и интерпрайз, будь он неладен.
3. Хочется ж интеграции. С системой мониторинга, к примеру. Хорошо, если на всем парке одно и то же ядро, но по факту не всегда даже ось-то одна и та же =)
Это очень энтерпрайзно, конечно, но вопрос есть: какие все-таки ограничения у продукта? Какого рода патчи он не сможет применить?
И еще, если говорить о «бизнес-критичных» серверах, то есть такие вопросы:
— Как перед применением отревьюить список патчей?
— Как откатить последний примененный банч патчей?
— История применения патчей?
— Возможна ли периодическиая проверка без фактического обновления, только нотификация?
Как-то так, наверно
в Европев Скайпе, только зарегистрировать аккаунт в системе (если не будет чего-то типа OpenId) и запустить клиентскую программу.Я не про общий случай, а про ситуацию, когда нат задает соответствие srcHost:srcPort — dstHost:dstPort. Как работает в общем случае я прекрасно знаю.
Нет, не любой способ будет костыльным. Если пара srcHost:srcPort соединения определяется на транспортном уровне, то не требуется модифицировать служебные заголовки протоколов верхних уровней. А это уже почти «безкостыльное» решение.
Два хоста за симметричным НАТом, действительно, нерешаемая задача без использования дополнительных узлов. И TURN тут был бы актуален.
В итоге мы бы получили только одну исключительную топологию, а не неопределенное количество =)
Никакого туннелирования ZRTP не предполагает.
P.S.: Для однозначности, я пользуюсь терминологией из вики.
Так или иначе, что при использовании SIP, что Jingle придется приделывать костыли, надеясь, что все варианты топологий будут перекрыты. Мне кажется, логичнее было бы использовать протоколы совмещающие сигнализацию и медиа и задающие рабочие порты на транспортном уровне.
IAX2, как пример решения.
Хотя да, у UDP нет такого богатства состояний соединения =)