WebRTCまたはCRMに電話をかける方法を教えた方法

私が働いていた会社は、インターネット上でサービスの販売に従事しています。 毎朝、勤務中のシフトは、蓄積されたアプリケーションの一般的なスタックを分解し、顧客に電話をかけて注文を明確にします。 日中は、オペレーターも着信を受信します。 私の仕事が始まる前に、彼らは次のデスクトップSIPクライアントを呼び出しに使用しました。







このダイヤラーは各従業員のコンピューターにインストールされ、電話を受け、必要に応じて電話をかけました。 設定を変更するには、すべてのマシンを移動して、すべてを手動で行う必要がありました。 同時に、従業員がリモートで作業している場合、その方法を電話で相談する必要がありました。 そして、しばしばそれは非常に困難でした。



しかし、主な問題は、Webシステムおよびデータベースとの統合の欠如でした。 着信通話用に顧客カードを開く、各従業員の通話統計を保存する、管理Webインターフェイスから自分のアクティビティを監視するといった一見単純なタスクは、対応する統合機能を備えていても、デスクトップソフトフォンではすべて非常に困難ですブラウザ、たとえばプラグインを使用します。



すべての内部作業と呼び出しを1つのシステムとデータベースにまとめるというアイデアがありました。 通話記録機能を備えた内蔵ダイヤラーの機能を使用して、CRMを長い間吹き替えました。

電話をかけるために、私はいくつかの技術を調べ、あまり多くはないという結論に達しました。 いくつかのオープンソースと商用の実装、および内部のセキュリティポリシーのために適切ではなかったいくつかのSAASサービスがありました-独自のサーバーを介して呼び出しを処理するためです。



最初はsipml5を使用しようとしました ：







ドキュメントはネットワークから断片的に収集する必要がありました。 その結果、ブラウザ側にSIPスタックを備えた多かれ少なかれ稼働中の電話が手に入りました。







インストール、テスト、および設定は約2週間続きました。その結果、回避できなかった小さなバグがいくつか見つかりました。たとえば、それらの1つはSSLを介してWebsocket設定に関連付けられていました。 そして、Chromeブラウザバージョン35のリリース後、ウェブ電話はまったく機能しなくなりました。



さらに、私はオペレーターにSIPアカウントを開示したくありませんでした。ブラウザー側のSIPスタックは、Websocketを介したそれらの公開使用と送信を暗示しています。 WebsocketがSSLを介して動作する場合でも、潜在的な攻撃者はjsコードを破棄し、SIPパスワードを引き出す可能性があります。 WebサーバーにSIPダイジェスト認証を委任するオプションがありましたが、その実装に到達することはできませんでした。



これは、ブラウザ側のSIPリクエストがデバッグコンソールでどのように見えるかです。







JavascriptからSIPスタックへのフルアクセスは、一般的に悪くありません。 これには利点があります。たとえば、JS SIPシグナリングの何らかの統合バグの修正を試みることができます。 ただし、注意点が1つあります。 現在、SIPベンダーの90％以上が、JS SIPを実行する2014年1月のセッション開始プロトコル（SIP）RFC 7118のトランスポートとしてのWebSocketプロトコルの仕様をサポートしていません。つまり、webrtc2sipモジュールはステートフルSIPとして動作する必要がありますプロキシと実際にサーバー側のSIPスタックサポートを複製します。 このレイアウトは、さらなる作業とサポートのために非常に困難に思えたので、SIPスタックをブラウザー側に残し、ホストできるサーバーパーツを使用して、このようなタスク用のよりシンプルでわかりやすいAPIを見つけることにしました。



その結果、彼はWeb Call Serverのテストを開始しました。 これはSAASではなく、サーバーを介して呼び出しを処理できるようにします。この場合は必要でした：







関数はsipml5とほぼ同じで、SIPを呼び出すWebRTCも同じです。逆も同様です。 Flashのサポートもありますが、すべてのオペレーターは主にChromeとFirefoxブラウザーを使用し、IEを使用するユーザーはより「正しい」ブラウザーに切り替える必要があったため、必要ありませんでした。



負荷は、Webページに再描画および適合できるオープンソースのJSソフトフォンに与えられます。



sipml5との主な違いは、SIP over Websocketではなく、APIを介したサーバーとの対話です。 つまり ブラウザ側にSIPスタックはありません。 サーバー側にのみあります。 これにより、開発者にとってフロントエンドタスクが少し簡単になりました。 ブラウザ側のSIPスタックは混乱を招き、Javascript APIとCSSを使用する場合、フロントエンドに集中することが可能になりました。







だから、私はそれをすべて実装した方法。



1. Amazon EC2でこのサーバーを使用しました 。

メモリとディスク容量はあまり必要ありません。 ログを除きます。 そして、そのようなタスクでのCPUの計算能力は重要になる可能性があるため、最も弱いインスタンスではありませんでした。







2. Webインターフェイス用にApacheを起動し、WCSサーバーをインストールして起動しました。







3. chromeページに標準のWeb電話が表示され、そのコードはgithubにあります。

電話のインターフェイスがあまり気に入らなかったので、すぐにデザインを変更することにしました。右側のデバッグコンソールは非常に便利でした。 残念ながら、後で通常のユーザーを怖がらせないように削除する必要がありました。







4.電話機能についてテスト済みのWeb電話。 これには以前のSIPアカウントを使用しました。 すべてが正常に機能します。 そして、彼は携帯電話、そしてSIP電話に電話をかけ、通話の保持と転送、そしてブラックジャックと...







同様に、携帯電話での作業。



5. web-CRMにweb-phoneコードを適合させ、そのデザインを再描画したところ、次のようになりました。







私たちは、適応についてより詳細に検討する必要があります。 デザインの再描画はこれに限定されませんでした。

最初の重大なタスクは、SIPサーバーでのWeb電話の自動登録でした。 そうしないと、オペレーターはCRMシステムのログインとパスワードを入力した後、SIPログインとパスワードを再度入力する必要があります。 統合の方法について疑問が生じました。



APIには、このための特別なloginByToken関数があることがわかりました。

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この機能がどのように機能するかを理解するために、一生懸命努力しなければなりませんでした。

ドキュメントと例を使用して、これがすべて次のように機能することがわかりました。







1）CRM側でトークンを作成する場合、AES暗号化アルゴリズムが使用されます。これは、ユーザーのSIPユーザー名とパスワード、およびその他の必要な情報を含む文字列を暗号化します。



暗号化キーは、CRMが展開されているサーバーとWCSサーバーのみが知っています。 さらに、トークンの有効期間は特別な属性の有効期限によって設定されるため、トークンを再利用することはできません。

トークンの暗号化は、AES CTRモードで発生します。 以下にopensslの例を示します。この例では、暗号化されたトークンが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」、右側が先ほど作成したトークンです。

このトークンを次の形式でweb-phoneのflashphoner.xml構成に挿入します。

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、ページがリロードされた直後に自動トークン登録手順が開始されます。

2および3）loginByTokenおよび復号化。



サーバー側では、AESの暗号化キーが構成に登録されます。

  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 REGISTER要求をSIPに送信し、前の手順で復号化した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とWebコールサーバーのみがSIPログインとパスワードを知っています。 このデータは、開いた形でブラウザに届きません。

したがって、私は、2つの異なるアカウント（CRM用とSIP用）を保存せずに、オペレーターのページに電話を埋め込むことができました。これは非常に不便だからです。 これで、ページのロード直後にloginByTokenが呼び出され、電話は準備完了状態になります。



ブラウザ呼び出しを実装した結果：



1.呼び出しがサイトから行われ、サイトで受信され、すべてのアクションがシステムに記録されます。



2.記録された会話を聞くことが可能になり、顧客との対立や従業員間の意見の不一致を解決するのに役立ちます。 これは、分散オフィスにとって重要です。



3.着信数は約20％増加しました。 クライアントが電話をかけたときに、オペレーターが常に電話をかけるとは限らないことが明らかになりました。

現時点では、すべてが意図したとおりに機能していると言えます。 SIPハードウェアに没頭することなく、問題の状況を解決できました。



欠点の中で、Windowsでインストールできないことに注意することができます。 ところで、Linuxのインストールと統合では、いじくり回す必要がありましたが、上級ユーザー/開発者だけがそれをマスターするようです。



WebRTCオーディオコールは、Flash Playerなどの追加のブラウザプラグインなしで安定して動作します。 したがって、計画された統合を実装できたため、2週間の作業は無駄にならなかったと言えます。