webrtcを使用してアスタリスクサーバーとやり取りするか、トランシーバーとブラウザーを通信させる方法

こんにちは、ハブラフチャン。

今日は、sip-telephonyの作業、つまり、sipML5をライブラリとして使用するwebRTCを介して、当社の他の記事とWebクライアントから以前に聞いたトランシーバー(またはICN)の間のサウンドセッションをどのように編成したかについて説明します。 PBXとしてのアスタリスク11。

画像

このトピックを気にする人は誰でも-猫へようこそ。



少しの背景



私たちの部門は、アスタリスク、および少なくともgoogle chrome(モバイル版とデスクトップ版の両方)で動作するsipクライアントを開発する運用タスクを受け取りました。 これから紡いだ。



RealTracのローカルポジショニングシステムには、トランシーバーなどのモバイルデバイス、またはICN(インターコムウェアラブル)と呼ばれるモバイルデバイスがあり、他のデバイスとの全二重通信と半二重ブロードキャスト通信の両方を使用できます。 これらのデバイスは、INCPd通信サーバーと対話します。その主なタスクはINCPプロトコルパケットを処理することであり、これを介してRealTracシステムのデバイスと情報が交換されます。 特に、このサーバーは、着信音声トラフィックを処理し、それをsipパケットに再パッケージ化して、サードパーティソフトウェアでさらに作業を行います。

スイッチはアスタリスクです。



画像



ツールキット



SipML5は私たちによってランダムに選ばれたわけではありません。 まず、このライブラリはアスタリスクとの統合に適しています。 第二に、私たちはすでに類似のシステムの経験がありましたが、当社がソフトウェアのOSとしてDebian 7をサポートしていたという事実のため、特定の困難がありました。 Debianディストリビューションではアスタリスク1.8のみが利用できますが、webrtc2sipの形式でタンバリンと踊らないwebRTCはバージョン11のアスタリスクでのみ動作します。これは将来のインストールのテスト場になる可能性があるため、あまり適していません。

Debian 8のリリースにより、この機能への移行を継続することが決定されました。

React.jsは、多数の内部状態を持つさまざまな動的オブジェクトを表示するのに便利なため、UIパーツを作成するためのツールキットとして機能しました。



sipML5の簡単な紹介



クライアントは、SIPml.StackとSIPml.Sessionの2つの主要なエンティティに基づいています。



SIPml.Stackは制御データストリームです。 このオブジェクトは、サーバーとのセッションを作成する際の主要なオブジェクトとして機能します。



SIPml.Sessionは、サーバーとのsipセッションのストリームです。 サーバーとクライアント部分の間でデータを転送するために直接使用されます。



sipML5を使用するためのアルゴリズム:



ライブラリの初期化:



SIPml.init(readyCallback, errorCallback);
      
      







スタックを作成



スタックは、クライアント作業の重要なデータソースです。

 RtlsSip.stack = new SIPml.Stack({ realm: Data.property.realm, impi: Data.property.impi, impu: Data.property.impu, password: Data.property.password, display_name: Data.property.display_name, websocket_proxy_url: Data.property.websocket_proxy_url, events_listener: { events: '*', listener: eventsListener }, sip_headers: [ { name: 'User-Agent', value: 'IM-client/OMA1.0 sipML5-v1.0.0.0' }, { name: 'Organization', value: 'RTLS' } ] })
      
      







スタックを作成するときは、大量の構成データを指定する必要がありますが、その一部はオプションです。 完全なスタック情報はここで見つけることができます。



スタックオブジェクトを作成したら、それを実行する必要があります。



 RtlsSip.stack.start();
      
      







start()関数は非同期であるため、呼び出しを開始する前に、スタック起動イベントを待つ必要があることに注意することが重要です。

イベントの完全なリストはここにたくさんありますが、それらをすべてリストするのは意味がありません。



スタック作成イベントの後、登録セッションを作成する必要があります。



 RtlsSip.stack.newSession('register', { events_listener: { events: '*', listener: registerListeners} }); RtlsSip.sessions.register();
      
      







この操作中に、ユーザーログインのsip要求が発生します。



これらのアクションを実行した後、ユーザーからの電話を発信または受信する準備ができました。



電話を受ける



sipML5への着信呼び出しは、SIPml.Stackオブジェクトのイベント「i_new_call」を開始します。

一般に、通話応答ハンドラは次のとおりです。



 var eventCallback = function(){ RtlsSip.callSession = e.newSession; RtlsSip.callSession.events_listener({events: '*', listener: RtlsSip.sessionEventListener}) RtlsSip.callSession.accept( {audio_remote: document.getElementById('audio_remote'), events_listener: { events: '*', listener: RtlsSip.sessionEventListener}}) }
      
      







e.newSession-通信セッションの追加オブジェクトが含まれます。イベント「i_new_call」の場合、SIPml.Session.Callオブジェクトになります。



コールを受信するには、accept()関数が必要です。 パラメータとしてSIPml.Session.Configurationオブジェクトを受け取ります



呼び出しの初期化



呼び出しの初期化は、SIPml.Session.Callのような新しいセッションの作成に要約されます



 RtlsSip.callSession = RtlsSip.stack.newSession('call-audio', { audio_remote: document.querySelector('#audio_remote'), events_listener: { events: '*', listener: RtlsSip.sessionEventListener } });
      
      







初期化後、識別子、番号、またはURLを使用してサブスクライバーの呼び出しを開始できます(例: 'sip:johndoe@example.com'または 'johndoe'または '+33600000000')。:



 RtlsSip.callSession.call(number);
      
      







通話管理

呼び出し制御はSIPml.Session.Callクラスのメソッドです



主なものは次のとおりです。

●.hangup()-通話を終了する

●.hold()/ .resume()-通話の保留/再開

●.mute(メディア、ミュート)-着信音をミュートします。メディアはミュートするコンテンツのタイプです。 mute-boolean-ミュートの有効化/無効化。

RtlsSip.callSession.mute( 'audio'、true);



ここで見つけることができる他の多くの機能もあります



応募スキーム:



アプリケーションスキームのアーキテクチャはかなり単純です。 イデオロギーとして、データの一方向性と要素間の相互依存性の欠如。



画像



システム統合



アスタリスクサーバーの設定は、ネットワークのオープンスペースで簡単に見つけることができるため、ここでは説明しません。

Webクライアントサブスクライバの場合、独自の番号リストが割り当てられました。 プールの番号は、ユーザーアカウントの作成時にディスパッチャによって設定されます。

ディスパッチャは、半二重モードと二重モードの両方で呼び出しを行い、必要に応じて他のディスパッチャと通信できます。

デバイスはデフォルトで半二重モードで鳴ります。 デバイスの呼び出し先のディスパッチャは、デバイスが現在配置されているジオセグメントに応じて選択されます。

これにより、システムの使用時に最大限の快適さを実現できます。

要約:

現在、この技術は統合とテストのプロセスを経ています。 仕事の過程で多くの障害や問題があると確信しています。

将来、同じ機能を提供する他のテクノロジーに基づいてソリューションを試す可能性があります。



シニレス



All Articles