Комментарии 26
А в чем проблема с установкой под Windows? Вы имеете ввиду middleware-сегмент или операторскую (клиентскую) часть?
Проблемы Websockets с SSL связаны с тем что Хром до 35 версии поддерживал алгоритм шифрования SDES/SRTP, после 35 поддерживать перестал. Теперь он поддерживает только DTLS/SRTP основанный на сертификатах.
Я сталкивался с такой-же проблемой, она действительно исходит из поддержки DTLS/SRTP. Разрешилось всё переустановкой doubango и webrtc2sip с правильной версией openssl библиотеки.
Клиентской то части, конечно же, без разницы, где работать. Это же браузер. Не будет работать разве что под iOS, т.к. там WebRTC нет в браузере.
Имеется ввиду middleware только под Linux.
Имеется ввиду middleware только под Linux.
На Linode аналогичная конфигурация будет в два раза дешевле, чем на AWS.
Тоже SSD (но больше места), и больше vCPU.
Тоже SSD (но больше места), и больше vCPU.
А почему не решились попробовать VoxImplant?
Если не секрет, а что за CRM? Или это внутренний продукт?
А open source аналоги такому решению есть?
А я не люблю Sipml5. Он очень большой и глючный. Когда я пилил сип по вебртц у себя, то я очень матерился на doubango-telecom за их webrtc2sip/sipml5. В итоге сейчас использую freeswitch+jssip.
Кому интересно могу написать статью, как я добился работы sip via webrtc на продакшне )
Кому интересно могу написать статью, как я добился работы sip via webrtc на продакшне )
Очень интересно! Ждем.
+1 — sipml5 меня тоже постоянно огорчает. Единственное, почему вынужден использовать его (sipml5) вместо JsSip — перевод звонков. Но как только JsSip поддержит transfer — сразу переведу систему на него (благо все для этого заранее подготовлено).
Выход Chrome 35 заставил патчить sipml, чтобы использовать как и раньше SDES, пока умельцы Астериска не порешают все проблемы с DTLS + WebRTC.
Статью пиши обязательно.
PS: размер sipml5 в минифицированом виде ~1 Mb — кошмар!
Выход Chrome 35 заставил патчить sipml, чтобы использовать как и раньше SDES, пока умельцы Астериска не порешают все проблемы с DTLS + WebRTC.
Статью пиши обязательно.
PS: размер sipml5 в минифицированом виде ~1 Mb — кошмар!
Ну статья уже в черновике. Буду писать о всем, с кучей матов и ненависти к некоторым продуктам)
пока умельцы Астериска не порешают все проблемы с DTLS + WebRTC.
Умельцы уже пропатчили. сейчас всеобщая и всепоглащающая проблема в другом- когда астериск делает бриджинг он посылает инвайт с транспортом AVP, и если вызываемый абонент сидит на вебфоне — он соответственно ожидает транспорт AVPF и шифрование. Как следствие при звонке вызываемый будет отвечать 603 ошибкой c комментарием failed to get local sdp.
В общем и целом — при исходящх астериск не следит за тем с какого устройства на нем сидит клиент. Как вариант можно проксировать и преобразовывать через openSIPS или Kamailio, но это уже совсем другая тема.
Из того что я знаю, умельцы все еще в процессе issues.asterisk.org/jira/browse/ASTERISK-22961
О варианте с дополнительным проксированием знаю, но он мне не по душе. Хватит с меня Астериска :)
О варианте с дополнительным проксированием знаю, но он мне не по душе. Хватит с меня Астериска :)
habrahabr.ru/post/225239/ Пожалуйста, вот статья =)
а недёшево оно, это вот WCS
Подскажите пожалуйста, как вы решаете проблему ухода со страницы во время звонка? На сколько я понимаю, при активном звонке нельзя обновлять страницу или переходить по ссылкам. Мне видится только вариант создания в основном шаблоне iframe, в котором и будет происходить работа с системой (в вашем случае CRM), а web-телефон всегда должен будет располагаться в родительском окне, которое будет постоянно даже при переходе по ссылкам. Или я чего-то не знаю о технологии WebRTC и в ней уже все предусмотрено?
Да собственно никак не решаем. Пользователи системы знают, что при обновлении страницы или закрытии вкладки web-телефон отключится. А идея с iframe интересная, надо будет проверить.
Идея с фреймом сработает.
Мы предупреждаем пользователя сообщением (в случае активного звонка), что он собирается покинуть страницу и поэтому звонок будет завершен (с возможностью отмены действия).
Еще, как вариант, веб телефон можно засунуть в браузерное расширение и тогда такой проблемы вообще не будет.
Мы предупреждаем пользователя сообщением (в случае активного звонка), что он собирается покинуть страницу и поэтому звонок будет завершен (с возможностью отмены действия).
Еще, как вариант, веб телефон можно засунуть в браузерное расширение и тогда такой проблемы вообще не будет.
Эхххх, а я надеялся, что по этому поводу уже есть красивое решение. Разрыв связи при серфинге сайта — достаточно серьезный недостаток web-телефона. Ведь оператору CRM постоянно приходится во время звонка проверять состояние заказа клиента, возможно устанавливать скидку, ну собственно много операций производить, которые могут привести к перезагрузке страницы… На фоне этого отображение карточки клиента во время звонка — сомнительный профит для web-телефона. Статистику и записи звонков на примере Астериска можно получить в интерфейсе CRM и другими способами. Сейчас думаем над альтернативными вариантами отображения карточки клиента. Вариант браузерного расширения интересен, но не кроссплатформенен и требует опыта разработки браузерных расширений, которого у нас пока нет в наличии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
WebRTC или как я научил нашу CRM звонить на телефоны