発信

注:このページでは,Jamiアカウントの原則を詳細に説明します.SIPアカウントでは,SIPプロトコルを使用します.

ジャミに電話しよう!

デイモン側

共同で通話する際には,ジャミは主にICE,SIP,TLSなどの既知のプロトコルを使用します.しかし,それを分散させるためには,通話を作成するプロセスは少し異なります.

  1. DHTの連絡先の存在を検索 (詳細については 連絡先管理)

  2. 連絡先が見つかったら,既知の候補者 (各ネットワークインターフェースのIP + リレーアドレス (TURN) + 反射アドレス (UPnP,公開) を発表する電話要求を送信します.

  3. 連絡先の返信を待て (彼らは既知のアドレスに返信します).

  4. ICE を通してソケットを交渉する.実際,ICE の 2 つのセッションが交渉されます. TCP で 1 つ (好ましい) と UDP で 1 つ (反発として).

  5. その後,ソケットは TLS (TCPの場合) または DTLS (UDPの場合) で暗号化されます.

  6. 連絡先は電話を受け入れたり拒否したりできます.連絡先が電話を受け入れるとき,ICE輸送 (UDPのみ) が交渉され,メディアのための4つの新しいソケットを作成します.

  7. 呼び出しが動いている!

交換ICE候補者

ヽjamiaccount.cpp (JamiAccount::startOutgoingCall`) で本当にすべてが始まります.ICEオブジェクトが既備され,DHTを通じて連絡が確認されると,連絡の呼び出し要求が作成されます.この要求は,次のとおり定義されているリモート ICEセッションに必要なすべての情報を含みます:

dht::IceCandidates(callvid,  blob)

callvidは,呼び出しを識別するために使用されたランダム番号であり,ブロックは,セッションのパスワード, ufrag と ICE候補を含む2つのコンチェンジされた ICEメッセージ (IceTransport::packIceMsg in ice_transport.cpp) を含む.

0d04b935
7c33834e7cf944bf0e367b42
H6e6ca382 1 UDP 2130706431 2607:fad8:4:6:9eb6:d0ff:dead:c0de 14133 typ host
H42c1g477 1 UDP 2130706431 fe80::9eb6:d0ff:fee7:1412 14133 typ host
Hc0a8027e 1 UDP 2130706431 192.168.0.123 34567 typ host
Sc0a8027e 1 UDP 1694498815 X.X.X.X 32589 typ srflx
0d04b932
7c33834e7cf944bf0e367b47
H6e6ca682 1 TCP 2130706431 2607:fad8:4:6:9eb6:d0ff:dead:c0de 50693 typ host tcptype passive
H6e6ca682 1 TCP 2130706431 2607:fad8:4:6:9eb6:d0ff:dead:c0de 9 typ host tcptype active
H42c1b577 1 TCP 2130706431 fe80::9eb6:d0ff:fee7:1412 50693 typ host tcptype passive
H42c1b577 1 TCP 2130706431 fe80::9eb6:d0ff:fee7:1412 9 typ host tcptype active
Hc0a8007e 1 TCP 2130706431 192.168.0.123 42751 typ host tcptype passive
Hc0a8007e 1 TCP 2130706431 192.168.0.123 9 typ host tcptype active
Sc0a8007e 1 TCP 1694498815 X.X.X.X 42751 typ srflx tcptype passive

ヽxxxxxx (`) ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ ヽ

ICEセッションは,すべての候補者がいたとき (送信者に対して,連絡先からの返信が受信されたとき) 両側から作成されます.

ICE交渉

待ち通りの通話は,まずTCP交渉が終了するまで待つ (失敗した場合,UDPの通話まで待つ) ヽJamiAccount::handlePendingCallList() によって管理されます.ICE交渉のコードは主に [pjproject]https://github.com/pjsip/pjproject) によって管理されますが,Jamiにとって,興味深い部分は, ice_transport.cppにあります.さらに,現在上流に合併されていない *pjproject* の上にいくつかの重要なパッチ/機能を追加します (例えば, TCP 上のICE).これらのパッチは, contrib/src/pjproject` に存在します.

制御ソケットを暗号化する

ロッケットが IceTransport インスタンスの作成と管理された後,その後に SipTransport に包装され,これは TlsIceTransport に対応する SipTransport に包装されます.メインコードは JamiAccount::handlePendingCall() に位置し,包装は SipTransportBroker::getTlsIceTransport に完成します.最後に,私たちのセッションは daemon/src/security/tls_session.cpp で TlsSession によって管理され,GnuTLS ライブラリを使用します.

TCPソケットが交渉されている場合,制御ソケットは TLS (1.3になります.あなたの同級 gnutls バージョンがサポートしている場合).代わりに UDPソケットが交渉されている場合 (交渉のファイアウォール制限/問題などのために),ソケットは DTLS (依然として同じ部分によって管理されます).

制御ソケットは,招待状,カスタムメッセージ (Jami は電話開始時にこのソケットにあなたのプロフィールのVCardを送信するか,カメラの回転時に) など,SIPパケットを送信するために使用されます.

関連記事:

  • ビデオ・ローテーション・サポートの改善

  • ファイル共有支援

メディアソケット

メディアソケットは,先ほど作成された TLS セッションを通じて鍵を交渉する SRTP ソケットです. TODO

建築

()

複数の流れ

デイモンのバージョン 13.3.0 から,マルチストリームが完全にサポートされています.この機能は,ユーザーが同時に電話中に複数のビデオを共有できるようにします.次の部分では,関連するすべての変更を説明します.

プジプ

メディアストリームを交渉すること. 実際,メディアストリームごとに2つのUDPソケットを使用します.

  1. メディアを追加したいのは 会議主人がなら 交渉すべきことは何もありません ビデオを既に ストリームに混ぜて ビデオミクサーに直接追加します

  2. 会議情報がないので,マルチストリームがサポートされていません.

  3. メディアの2つが 交渉される

ヽPJ_ICE_COMP_BITSは,ICEセッションごとにより多くのソケットを生成できるように, PJ_ICE_COMP_BITSに変更されました (これは 2^5`に対応しているので,32ストリームです).

切り替えを減らし入力,サポート要求メディア変更

ダイモンでは,古いAPI switchInputは,現在 DEPRECATED; switchSecondaryInputと同じです:

<method name="switchInput" tp:name-for-bindings="switchInput">
    <tp:docstring>
        Switch input for the specified call
    </tp:docstring>
    <arg type="s" name="accountId" direction="in"/>
    <arg type="s" name="callId" direction="in"/>
    <arg type="s" name="input" direction="in"/>
    <arg type="b" direction="out" />
</method>

<method name="switchSecondaryInput" tp:name-for-bindings="switchSecondaryInput">
    <tp:added version="11.0.0"/>
    <tp:docstring>
        Switch secondary input for the specified conference
    </tp:docstring>
    <arg type="s" name="accountId" direction="in" />
    <arg type="s" name="conferenceId" direction="in"/>
    <arg type="s" name="input" direction="in"/>
    <arg type="b" direction="out" />
</method>

requestMediaChangeは,電話と会議の両方において,これを置き換え,

<method name="requestMediaChange" tp:name-for-bindings="requestMediaChange">
    <tp:added version="11.0.0"/>
    <tp:docstring>
        <p>Request changes in the media of the specified call.</p>
    </tp:docstring>
    <arg type="s" name="accountId" direction="in" />
    <arg type="s" name="callId" direction="in">
        <tp:docstring>
        The ID of the call.
        </tp:docstring>
    </arg>
    <annotation name="org.qtproject.QtDBus.QtTypeName.In2" value="VectorMapStringString"/>
    <arg type="aa{ss}" name="mediaList" direction="in">
        <tp:docstring>
        A list of media attributes to apply.
        </tp:docstring>
    </arg>
    <arg type="b" name="requestMediaChangeSucceeded" direction="out"/>
</method>

互換性

デイモンのバージョンが < 13.3.0 で,ピアでコールを行う場合,マルチストリームが有効ではなく,古い行動が使用されます (1 ビデオのみ).

流れの識別

複数のストリームが現在存在できるので,各メディアストリームは識別子によって識別され,フォーマットは"_"です. 例えば"audio_0", "video_2"などです.

旋回

XMLは,求められたストリームを追加するために更新されました:

<?xml version="1.0" encoding="utf-8" ?>
<media_control>
  <vc_primitive>
    <stream_id>{}</stream_id>
    <to_encoder>
      <device_orientation>0</device_orientation>
    </to_encoder>
  </vc_primitive>
</media_control>

キーフレーム

XMLは,求められたストリームを追加するために更新されました:

<?xml version="1.0" encoding="utf-8" ?>
<media_control>
  <vc_primitive>
    <stream_id>{}</stream_id>
    <to_encoder><picture_fast_update/></to_encoder>
  </vc_primitive>
</media_control>

声活動

XMLは,求められたストリームを追加するために更新されました:

<?xml version="1.0" encoding="utf-8" ?>
<media_control>
  <vc_primitive>
    <stream_id>{}</stream_id>
    <to_encoder>
      <voice_activity>true</voice_activity>
    </to_encoder>
  </vc_primitive>
</media_control>

グループ通話

反映された変更は,ここで記錄されています.

顧客

バックエンドは 32 台のメディアを同時にサポートしている場合でも,カスタムクライアントを除いて,現在,カメラとビデオを同時に共有する能力のみを推奨しています.カメラはカメラボタンを介して制御され,他のメディアは"シェア"ボタンを介して制御されます.

AvAdapter (isCapturing, shareAllScreens, stopSharing) のような方法です. addMediaと removeMediaは,図書室の論理では, callModelで直接の requestMediaChangeを使用し,デザイン参照として使用できます.