Pull to refresh

Comments 26

А в чем проблема с установкой под Windows? Вы имеете ввиду middleware-сегмент или операторскую (клиентскую) часть?
Клиентской то части, конечно же, без разницы, где работать. Это же браузер. Не будет работать разве что под iOS, т.к. там WebRTC нет в браузере.
Имеется ввиду middleware только под Linux.
Проблемы Websockets с SSL связаны с тем что Хром до 35 версии поддерживал алгоритм шифрования SDES/SRTP, после 35 поддерживать перестал. Теперь он поддерживает только DTLS/SRTP основанный на сертификатах.
Спасибо, ценная информация. Многим может пригодиться. Хотя тогда выходит, что с Websockets это вообще никак не связано, потому что DTLS/SRTP это уже сам WebRTC, а не Websockets.
Я сталкивался с такой-же проблемой, она действительно исходит из поддержки DTLS/SRTP. Разрешилось всё переустановкой doubango и webrtc2sip с правильной версией openssl библиотеки.
Клиентской то части, конечно же, без разницы, где работать. Это же браузер. Не будет работать разве что под iOS, т.к. там WebRTC нет в браузере.
Имеется ввиду middleware только под Linux.
На Linode аналогичная конфигурация будет в два раза дешевле, чем на AWS.
Тоже SSD (но больше места), и больше vCPU.
Честно говоря, SAAS решения не рассматривали совсем. Стараемся все хостить у себя, на своих серверах.
Если не секрет, а что за CRM? Или это внутренний продукт?
Пока внутренняя самописная системка на PHP/MySQL. Есть мысли ее тиражировать, но пока только мысли.
Да, в начале поста как раз есть ссылка на sipml5.
Речь шла именно о решении, когда sip стэк будет на стороне сервера, а не на фронтэнде, как у sipML.
А я не люблю Sipml5. Он очень большой и глючный. Когда я пилил сип по вебртц у себя, то я очень матерился на doubango-telecom за их webrtc2sip/sipml5. В итоге сейчас использую freeswitch+jssip.

Кому интересно могу написать статью, как я добился работы sip via webrtc на продакшне )
+1 — sipml5 меня тоже постоянно огорчает. Единственное, почему вынужден использовать его (sipml5) вместо JsSip — перевод звонков. Но как только JsSip поддержит transfer — сразу переведу систему на него (благо все для этого заранее подготовлено).
Выход Chrome 35 заставил патчить sipml, чтобы использовать как и раньше SDES, пока умельцы Астериска не порешают все проблемы с DTLS + WebRTC.
Статью пиши обязательно.

PS: размер sipml5 в минифицированом виде ~1 Mb — кошмар!
Ну статья уже в черновике. Буду писать о всем, с кучей матов и ненависти к некоторым продуктам)
пока умельцы Астериска не порешают все проблемы с DTLS + WebRTC.

Умельцы уже пропатчили. сейчас всеобщая и всепоглащающая проблема в другом- когда астериск делает бриджинг он посылает инвайт с транспортом AVP, и если вызываемый абонент сидит на вебфоне — он соответственно ожидает транспорт AVPF и шифрование. Как следствие при звонке вызываемый будет отвечать 603 ошибкой c комментарием failed to get local sdp.
В общем и целом — при исходящх астериск не следит за тем с какого устройства на нем сидит клиент. Как вариант можно проксировать и преобразовывать через openSIPS или Kamailio, но это уже совсем другая тема.
Подскажите пожалуйста, как вы решаете проблему ухода со страницы во время звонка? На сколько я понимаю, при активном звонке нельзя обновлять страницу или переходить по ссылкам. Мне видится только вариант создания в основном шаблоне iframe, в котором и будет происходить работа с системой (в вашем случае CRM), а web-телефон всегда должен будет располагаться в родительском окне, которое будет постоянно даже при переходе по ссылкам. Или я чего-то не знаю о технологии WebRTC и в ней уже все предусмотрено?
Да собственно никак не решаем. Пользователи системы знают, что при обновлении страницы или закрытии вкладки web-телефон отключится. А идея с iframe интересная, надо будет проверить.
Идея с фреймом сработает.
Мы предупреждаем пользователя сообщением (в случае активного звонка), что он собирается покинуть страницу и поэтому звонок будет завершен (с возможностью отмены действия).
Еще, как вариант, веб телефон можно засунуть в браузерное расширение и тогда такой проблемы вообще не будет.
Эхххх, а я надеялся, что по этому поводу уже есть красивое решение. Разрыв связи при серфинге сайта — достаточно серьезный недостаток web-телефона. Ведь оператору CRM постоянно приходится во время звонка проверять состояние заказа клиента, возможно устанавливать скидку, ну собственно много операций производить, которые могут привести к перезагрузке страницы… На фоне этого отображение карточки клиента во время звонка — сомнительный профит для web-телефона. Статистику и записи звонков на примере Астериска можно получить в интерфейсе CRM и другими способами. Сейчас думаем над альтернативными вариантами отображения карточки клиента. Вариант браузерного расширения интересен, но не кроссплатформенен и требует опыта разработки браузерных расширений, которого у нас пока нет в наличии.
Only those users with full accounts are able to leave comments. Log in, please.