🕍 🥩 🎇 WebRTC या मैंने फोन को कॉल करने के लिए हमारे सीआरएम को कैसे सिखाया 💟 👸🏾 👩🏻‍💻

जिस कंपनी में मैं काम करता था, वह इंटरनेट पर सेवाओं की बिक्री में लगी हुई है। प्रत्येक सुबह, ड्यूटी पर बदलाव, संचित अनुप्रयोगों के सामान्य ढेर को अलग कर देता है और आदेशों को स्पष्ट करने के लिए ग्राहकों को कॉल करना शुरू कर देता है। दिन के दौरान, ऑपरेटर भी इनकमिंग कॉल प्राप्त करते हैं। मेरे उपक्रम की शुरुआत से पहले, उन्होंने कॉल के लिए निम्नलिखित डेस्कटॉप एसआईपी क्लाइंट का उपयोग किया:

यह डायलर प्रत्येक कर्मचारी के कंप्यूटर पर स्थापित किया गया था, कॉल प्राप्त की और जहां आवश्यक हो, कॉल किया। सेटिंग्स में कोई भी परिवर्तन करने के लिए, सभी मशीनों के चारों ओर जाना और मैन्युअल रूप से सब कुछ करना आवश्यक था। उसी समय, यदि कर्मचारी दूर से काम करता है, तो उसे फोन से सलाह लेनी चाहिए कि यह सब कैसे किया जाए। और अक्सर यह काफी मुश्किल था।

लेकिन मुख्य समस्या हमारे वेब-सिस्टम और डेटाबेस के साथ एकीकरण की कमी थी। आने वाले कॉल के लिए ग्राहक कार्ड खोलने, प्रत्येक कर्मचारी के लिए कॉल आँकड़े सहेजने और प्रशासनिक वेब इंटरफ़ेस से उनकी गतिविधि की निगरानी करने जैसे सरल कार्य, डेस्कटॉप सॉफ्टफ़ोन के साथ करना बहुत मुश्किल होता है, भले ही इसके साथ एकीकरण क्षमता हो। ब्राउज़र, उदाहरण के लिए प्लगइन्स का उपयोग करना।

एक सिस्टम और डेटाबेस में सभी आंतरिक काम और कॉल को संयोजित करने का विचार था। मैंने कॉल रिकॉर्डिंग के साथ बिल्ट-इन डायलर के फ़ंक्शन के साथ लंबे समय तक हमारे सीआरएम को डब किया।

कॉल करने के लिए, मैंने कई तकनीकों की जांच की और इस निष्कर्ष पर पहुंचा कि उनमें से बहुत सारे नहीं हैं। कुछ खुले स्रोत और वाणिज्यिक कार्यान्वयन थे, साथ ही कई एसएएएस सेवाएं जो आंतरिक सुरक्षा नीतियों के कारण उपयुक्त नहीं थीं - अपने स्वयं के सर्वर के माध्यम से कॉल को संसाधित करने के लिए।

शुरुआत में मैंने sipml5 का उपयोग करने की कोशिश की:

प्रलेखन को नेटवर्क से टुकड़ों में एकत्र किया जाना था। नतीजतन, मुझे ब्राउज़र की तरफ एसआईपी स्टैक के साथ कम या ज्यादा काम करने वाला फोन मिला:

स्थापना, परीक्षण और सेटिंग्स लगभग 2 सप्ताह तक चलीं, नतीजतन, मुझे कई छोटे लेकिन अप्रिय बग मिले, जिन्हें दरकिनार नहीं किया जा सकता था, उदाहरण के लिए, उनमें से एक एसएसएल के माध्यम से वेबसोकेट सेटिंग्स से जुड़ा था। और क्रोम ब्राउज़र के रिलीज़ होने के बाद वेब फोन के 35 संस्करण ने काम करने से इनकार कर दिया।

इसके अलावा, मैं ऑपरेटरों के लिए एसआईपी खातों का खुलासा नहीं करना चाहता था, और ब्राउज़र साइड पर एसआईपी स्टैक का अर्थ उनके खुले उपयोग और वेबसोकेट के माध्यम से भेजना है। भले ही Websockets SSL के माध्यम से काम करता हो, एक संभावित हमलावर के पास js कोड को फाड़ने और SIP पासवर्ड को बाहर निकालने का अवसर होता है। हमारे वेब सर्वर पर एसआईपी डाइजेस्ट प्रमाणीकरण को सौंपने के लिए एक विकल्प था, लेकिन इसके कार्यान्वयन के लिए संभव नहीं था।

यह कैसे ब्राउज़र साइड SIP अनुरोध डीबग कंसोल में दिखता है:

जावास्क्रिप्ट से एसआईपी स्टैक तक पूर्ण पहुंच आमतौर पर खराब नहीं होती है। इसके अपने फायदे हैं, उदाहरण के लिए, आप JS SIP सिग्नलिंग में किसी प्रकार के एकीकरण बग को ठीक करने का प्रयास कर सकते हैं। लेकिन एक कैविएट है। एसआईपी विक्रेताओं के 90% से अधिक लोग वर्तमान में द वेवसकेट प्रोटोकॉल के विनिर्देशन का समर्थन नहीं करते हैं, जो कि सत्र पहल प्रोटोकॉल (एसआईपी) आरएफसी 7118 के लिए ट्रांसपोर्टेशन के रूप में है , जो जेएस एसआईपी चलाता है, जिसका अर्थ है कि वीब्रैक 2 एसआईपी मॉड्यूल स्टेटस एसआईपी के रूप में काम करना चाहिए। परदे के पीछे और वास्तव में डुप्लिकेट सर्वर साइड SIP स्टैक समर्थन। यह लेआउट आगे के काम और समर्थन के लिए बहुत मुश्किल लग रहा था, और मैंने ब्राउज़र पक्ष पर एसआईपी स्टैक को छोड़ने और ऐसे कार्यों के लिए कुछ और सरल और समझने योग्य एपीआई खोजने का फैसला किया, जिनके सर्वर भाग को होस्ट किया जा सकता था।

परिणामस्वरूप, उन्होंने वेब कॉल सर्वर का परीक्षण शुरू किया। यह SAAS नहीं है और आपको अपने सर्वर के माध्यम से कॉल संसाधित करने की अनुमति देता है, जो इस मामले में आवश्यक था:

फ़ंक्शन लगभग Sipml5 के समान हैं, वही WebRTC SIP को कॉल करता है और इसके विपरीत। फ्लैश के लिए भी समर्थन है, लेकिन यह आवश्यक नहीं था, क्योंकि सभी ऑपरेटर मुख्य रूप से क्रोम और फ़ायरफ़ॉक्स ब्राउज़र का उपयोग करते हैं, और आईई का उपयोग करने वालों को अधिक "सही" ब्राउज़रों पर स्विच करना पड़ता था।

लोड एक खुले स्रोत जेएस सॉफ्टफ़ोन को दिया जाता है जिसे वेब पेज के लिए फिर से तैयार और अनुकूलित किया जा सकता है।

Sipml5 से मुख्य अंतर एपीआई के माध्यम से सर्वर के साथ बातचीत है, और वेबसैट पर एसआईपी के माध्यम से नहीं। यानी ब्राउज़र साइड पर कोई SIP स्टैक नहीं है। यह केवल सर्वर साइड पर स्थित है। इससे डेवलपर के लिए फ्रंट-एंड का काम थोड़ा आसान हो गया। ब्राउज़र साइड पर एसआईपी स्टैक ने इसे भ्रम में डाल दिया, और जब जावास्क्रिप्ट एपीआई और सीएसएस के साथ काम करते हैं, तो सामने के छोर पर ध्यान केंद्रित करना संभव हो गया।

इसलिए, मैंने यह सब कैसे लागू किया।

1. मैंने इस सर्वर को Amazon EC2 पर लिया:

मेमोरी और डिस्क स्थान की आवश्यकता नहीं है। सिवाय लॉग के। और ऐसे कार्यों में सीपीयू की कंप्यूटिंग शक्ति महत्वपूर्ण हो सकती है, इसलिए यह सबसे कमजोर उदाहरण नहीं है।

2. वेब इंटरफ़ेस के लिए अपाचे उठाया, WCS सर्वर को स्थापित और लॉन्च किया।

3. क्रोम पेज पर एक मानक वेब-फोन दिखाई दिया, जिसका कोड जीथब पर है ।

मुझे वास्तव में फ़ोन इंटरफ़ेस पसंद नहीं आया, मैंने तुरंत इसे फिर से डिज़ाइन करने का निर्णय लिया, और दाईं ओर डिबग कंसोल काफी उपयोगी निकला। यह एक अफ़सोस की बात है कि बाद में इसे हटा दिया गया ताकि एक सामान्य उपयोगकर्ता को डराने के लिए नहीं।

4. कॉल करने की क्षमता पर वेब-फोन का परीक्षण किया। मैंने इसके लिए अपने पिछले SIP खातों का उपयोग किया। सब कुछ वैसा ही काम करना चाहिए जैसा कि होना चाहिए। और वह मोबाइल फोन, और एसआईपी-फोन पर कॉल करता है, और प्रतिधारण और स्थानांतरण, और लाठी और कॉल ...

इसी तरह, मोबाइल फोन के साथ काम करना।

5. मैंने अपने वेब-सीआरएम के लिए वेब-फोन कोड को अनुकूलित किया, इसके डिजाइन को फिर से तैयार किया और अब यह इस तरह दिखता है:

हमें अधिक विस्तार से अनुकूलन पर ध्यान देना चाहिए, क्योंकि डिज़ाइन को फिर से डिज़ाइन करना सीमित नहीं था।

पहला गंभीर कार्य एक एसआईपी सर्वर पर वेब-फोन का स्वत: पंजीकरण था। CRM सिस्टम के लिए लॉगिन और पासवर्ड दर्ज करने के बाद, ऑपरेटर को फिर से SIP लॉगिन और पासवर्ड दर्ज करना होगा। सवाल यह है कि कैसे एकीकृत किया जाए।

यह पता चला है कि एपीआई के पास इसके लिए एक विशेष लॉगिनबाइटन फ़ंक्शन है:

function loginByToken(token) {     trace("Phone - loginByToken "+ token);       connectingViewBeClosed = false;       var result = flashphoner.loginByToken(flashphonerLoader.urlServer, token, document.URL);       closeLoginView();       openConnectingView("Connecting...", 0); }

यह समझने के लिए कि यह फ़ंक्शन कैसे काम करता है, मुझे कड़ी मेहनत करनी थी।

दस्तावेज़ीकरण और उदाहरणों का उपयोग करते हुए, मुझे पता चला कि यह सब कुछ इस तरह से काम करता है:

1) सीआरएम साइड पर टोकन बनाते समय, एईएस एन्क्रिप्शन एल्गोरिथ्म का उपयोग किया जाता है, जो एक स्ट्रिंग को एन्क्रिप्ट करता है जिसमें उपयोगकर्ता के एसआईपी उपयोगकर्ता नाम और पासवर्ड और साथ ही अन्य आवश्यक जानकारी शामिल होती है।

एन्क्रिप्शन कुंजी केवल हमारे सर्वर के लिए जानी जाती है जहां CRM तैनात है, साथ ही साथ WCS सर्वर भी। इसके अलावा, टोकन की वैधता अवधि विशेष विशेषता द्वारा निर्धारित की जाती है, ताकि इसकी पुन: उपयोग करना संभव न हो।

टोकन एन्क्रिप्शन एईएस सीटीआर मोड में होता है। नीचे एक उदाहरण है जो कि Opensl के साथ है, जिसमें SIP पासवर्ड ट्रांसमिशन के साथ एक एन्क्रिप्टेड टोकन उत्पन्न होता है:

  echo -ne '<root status="ok" description="test" registerRequired="true" login="user5" authenticationName="user5" password="password" outboundProxy="proxy.my" domain="proxy.my" port="5060" visibleName="AAA" api_key="App1" expires="1394839040761100000"/>' | openssl enc -aes-128-ctr -nosalt -K 8263D535FFFFFFFF7B0F60 -iv 00000000000000000000000000000000 | xxd -p

नतीजतन, मुझे कुछ इस तरह मिला:

  CRM:cf4693eedaafda1390b261dcf29d45bd3556d64b1f69cd84db8c3ac8721e7e139b80be75e39da18154e897596e9317084faee0d24d6a6197b62a93a2647b263059167b2664179a5866738260c77372e04fe22104ebe1c7530e9215f50d111fd24384755d28d06673e866159c0b6b83289c045619e8481f9c2a6b56b182f393a7dea06b38b7856436895402a5b40f0525a17822ae0f3204b606e4f0169d1ca9176e8e1b696683d12c7db8208946c204e94f3c8ff285f2bcef4ca9b12187cf541ce37d508d3663ef65f944b01db9aea5c0f10002a376d051cbf1b19bc34f76b6d2a4e1ad1450ae412b51b3af1d3860167f5416b3d2c9eeff94d60b82279e8685beb543893e8a09dee640d7366e478d0d1ee7368e0b63b511

हमारे एप्लिकेशन का नाम बाईं ओर "CRM" है, और दाईं ओर पहले बनाया गया टोकन है।

मैं इस टोकन को निम्न रूप में वेब-फोन के फ्लैशफोनर.एक्सएमएल विन्यास में सम्मिलित करता हूं:

 <token>CRM:cf4693eed...</token>

इस मामले में, पृष्ठ को फिर से लोड किए जाने के तुरंत बाद स्वचालित टोकन पंजीकरण प्रक्रिया शुरू हो जाएगी।

2 और 3) loginByToken और डिक्रिप्शन।

सर्वर की ओर, एईएस के लिए एन्क्रिप्शन कुंजी को विन्यास में पंजीकृत किया गया है:

  CRM=8263D535FFFFFFFF7B0F60

इस प्रकार, जब एक उपसर्ग "CRM:" के साथ आता है, तो इसी कुंजी को डिक्रिप्ट करने के लिए उपयोग किया जाता है।

डिक्रिप्शन के परिणामस्वरूप, WCS सर्वर पहले से एन्क्रिप्टेड स्ट्रिंग प्राप्त करता है:

 <root status="ok" description="test" registerRequired="true" login="user5" authenticationName="user5" password="password" outboundProxy="proxy.my" domain="proxy.my" port="5060" visibleName="AAA" api_key="App1" expires="1394839040761100000"/>

और इस से XML स्ट्रिंग SIP पंजीकरण के लिए आवश्यक सभी डेटा लेती है।

3) जैसे ही सर्वर ने डेटा को डिक्रिप्ट किया है, यह SIP को SIP REGISTER अनुरोध भेजता है और पिछले चरण में डिक्रिप्ट किए गए SIP लॉगिन और पासवर्ड का उपयोग करके 401 में एक सामान्य डाइजेस्ट प्रमाणीकरण लौटाता है।

 REGISTER sip:sipnet.ru;lr SIP/2.0 Call-ID: 345ec5157b1a66de3a3a275bdba36197@192.168.1.90 CSeq: 2 REGISTER From: <sip:crm1@sipnet.ru>;tag=73a499a8 To: <sip:crm1@sipnet.ru> Via: SIP/2.0/UDP 192.168.1.90:30000;branch=z9hG4bK2622ce723c34760d6a3f43dd631329e1 Max-Forwards: 70 User-Agent: WebRTC Allow: UPDATE,MESSAGE,BYE,ACK,REFER,INVITE,NOTIFY,INFO,OPTIONS,CANCEL Contact: <sip:crm1@192.168.1.90:30000>;expires=3600 Expires: 3600 Authorization: Digest username="crm1",realm="etc.tario.ru",nonce="4A0674BEDF81E0B3F65D",uri="sip:sipnet.ru;lr",response="0762b862c544007f4fb7c43277312a3d",algorithm=MD5,opaque="opaq",qop=auth,cnonce="1234567890",nc=00000001 Content-Length: 0

इस स्थिति में, केवल CRM और वेब कॉल सर्वर SIP लॉगिन और पासवर्ड जानते हैं। यह डेटा ब्राउज़र को खुले रूप में नहीं मिलता है।

इस प्रकार, मैंने ऑपरेटर के पेज में फोन को दो अलग-अलग खातों - सीआरएम के लिए एक और एसआईपी के लिए स्टोर करने के लिए मजबूर करने में कामयाब रहा, क्योंकि यह बहुत असुविधाजनक है। अब, पेज लोड होने के ठीक बाद, loginByToken को कॉल किया जाता है और फोन तैयार अवस्था में चला जाता है।

ब्राउज़र कॉल को लागू करने के कुछ परिणाम:

1. कॉल अब साइट से बनाई गई हैं और साइट पर प्राप्त की जाती हैं, जहां सिस्टम में सभी क्रियाएं रिकॉर्ड की जाती हैं।

2. रिकॉर्ड की गई बातचीत को सुनना संभव हो गया, जो ग्राहकों के साथ संघर्ष और कर्मचारियों के बीच मतभेदों को सुलझाने में मदद करता है। यह हमारे वितरित कार्यालय के लिए महत्वपूर्ण है।

3. प्राप्त कॉल की संख्या में लगभग 20% की वृद्धि हुई। यह स्पष्ट हो गया कि जब ग्राहक कहते हैं तो ऑपरेटर हमेशा फोन नहीं उठाते हैं।

फिलहाल, हम कह सकते हैं कि सब कुछ उद्देश्य के अनुसार काम करता है। हम एसआईपी हार्डवेयर में गंभीर विसर्जन के बिना समस्या की स्थितियों को हल करने में कामयाब रहे।

कमियों के बीच विंडोज के तहत स्थापित करने में असमर्थता को नोट किया जा सकता है। वैसे, लिनक्स इंस्टॉलेशन और इंटीग्रेशन के साथ, मुझे भी टिंकर करना था और ऐसा लगता है कि केवल एक उन्नत उपयोगकर्ता / डेवलपर ही इसमें महारत हासिल करेगा।

WebRTC ऑडियो कॉल, बिना किसी अतिरिक्त ब्राउज़र प्लग-इन और फ़्लैश प्लेयर जैसे काम करता है। इसलिए हम कह सकते हैं कि मैं योजनाबद्ध एकीकरण को लागू करने में कामयाब रहा और दो सप्ताह का काम बर्बाद नहीं हुआ।

WebRTC या मैंने फोन को कॉल करने के लिए हमारे सीआरएम को कैसे सिखाया

More articles: