WebRTC или как научих нашия CRM да звъни на телефони
Компанията, в която работех, продава услуги онлайн. Всяка сутрин дежурната смяна сортира общия куп натрупани заявления и започва да звъни на клиенти за уточняване на поръчки. През деня операторите приемат и входящи обаждания. Преди моето начинание те използваха следния настолен SIP клиент за разговори:
Но най-важният проблем беше липсата на интеграция с нашата уеб система и база данни. Такива на пръв поглед прости задачи като отваряне на клиентска карта за входящо повикване, запазване на статистика за обажданията за всеки служител и наблюдение на тяхната дейност от административния уеб интерфейс - всичко това е много трудно да се направи с настолен софтфон, дори ако има подходящи възможности за интегриране на браузъра, например, с помощта на плъгини.
Възникна идеята цялата вътрешна работа и обаждания да се обединят в една система и база данни. Отдавна завършвам нашия CRM с функцията на вграден дайлер със запис на разговори. За да реализирам обаждания, разгледах редица технологии и стигнах до извода, че не са толкова много. Имаше няколко внедрявания с отворен код и комерсиални, както и няколко SAAS услуги, които не бяха подходящи поради вътрешни политики за сигурност - за обработка на обаждания през собствен сървър.
В началото се опитах да използвам sipml5:
Ето как SIP заявките изглеждат от страната на браузъра в конзолата за отстраняване на грешки:
В резултат на това започнах да тествам Web Call Server. Това не е SAAS и ви позволява да обработвате повиквания през вашия сървър, което в този случай беше необходимо:
Функциите са приблизително същите като тези на sipml5, същите WebRTC извиквания към SIP и обратно. Има и Flash поддръжка, но не беше необходима, тъй като всички оператори използват предимно Chrome и Firefoxбраузър, а тези, които използват IE, трябваше да преминат към по-„правилни“ браузъри.
Товарът получава JS софтфон с отворен код, който може да бъде преначертан и адаптиран за уеб страница.
Основната разлика от sipml5 е взаимодействието със сървъра чрез API, а не чрез SIP през Websockets. Тези. Няма SIP стек от страната на браузъра. Намира се само от страната на сървъра. Това направи задачата на фронтенд разработчика малко по-лесна, т.к SIP стекът от страна на браузъра беше объркващ и при работа с Javascript API и CSS стана възможно да се съсредоточите върху предния край.
И така, как да приложа всичко това.
1. Взех следния сървър на Amazon EC2: Не се нуждаете от много памет и дисково пространство. С изключение на трупи. И изчислителната мощност на процесора при такива задачи може да бъде важна, така че взех не най-слабия екземпляр.
2. Вдигна Apache за уеб интерфейса, инсталира и стартира WCS сървъра.
Оказа се, че API има специална функция loginByToken за това:
Отне много усилия, за да разберем как работи тази функция. С помощта на документация и примери успяхме да разберем, че всичко работи по следния начин:
1) При създаване на токен от страна на CRM се използва алгоритъмът за криптиране AES, който криптира низ, който включва потребителското име и парола за SIP, както и друга необходима информация.
Ключът за криптиране е известен само на нашия сървър, където е внедрен CRM, както и на WCS сървъра. Освен това датата на изтичане на токена се задава от специалния атрибут expires, така че да не може да се използва повторно. Токенът е шифрован в режим AES CTR. По-долу е даден пример с openssl, в койтогенерира се криптиран токен с предаването на SIP парола:
В резултат на това получих нещо като:
В този случай процедурата за автоматична регистрация на токена ще започне веднага след презареждане на страницата. 2 и 3) loginByToken и дешифриране.
От страната на сървъра конфигурацията съдържа ключове за криптиране за AES:
По този начин, когато пристигне токен с префикс „CRM:“, съответният ключ се използва за дешифрирането му.
В резултат на дешифрирането на WCS сървърът получава предварително шифрования низ:
и взема всички данни, необходими за SIP регистрация от този XML низ.
3) Веднага след като сървърът дешифрира данните, той изпраща заявка за SIP REGISTER до SIP и при отговор 401 връща нормално удостоверяване на Digest, използвайки SIP данните за вход и паролата, декриптирани в предишната стъпка.
Някои резултати от въвеждането на повиквания в браузъра:
1. Обажданията вече се правят от сайта и се приемат на сайта, където всички действия се записват в системата.
2. Стана възможно да се слушат записани разговори, което помага за разрешаване на конфликтни ситуации с клиенти и разногласия между служителите. Това е важно за нашия разпределен офис.
3. Броят на получените обаждания се е увеличил с около 20%. Стана ясно, че операторите невинаги вдигат телефона при обаждане на клиента. В момента можем да кажем, че всичко работи по предназначение. Проблемните ситуации бяха разрешени без сериозно потапяне в материалната база на SIP.
Сред недостатъците може да се отбележи невъзможността за инсталиране под Windows. Между другото, аз също трябваше да се занимавам с инсталацията под Linux и интеграцията и изглежда, че само напреднал потребител / разработчик може да го овладее.
WebRTC аудио разговорите работят стабилно и без допълнителен браузърдобавки като Flash Player. Така че можем да кажем, че успях да реализирам планираната интеграция и две седмици работа не бяха пропилени.
Hardcore conf в C++. Каним само професионалисти.