I.はじめに
WebRTCオーディオおよびビデオ通信の両側は、通信するピアの通信アドレスを知る必要があります.WebRTCはICEを使用して、通信ピアとの通信接続を確立します.ICEの重要なステップは、候補情報を収集することです.ローカルエンドは送信する必要があります.自身のホスト候補、NAT マッピングされた候補、リレー候補、およびその他の情報がピアに送信され、ピアもローカルに候補情報を送信する必要があります. 2 つのパーティはメディア接続検出を実行し、検出後にのみ通信を続行できます成功しています。
二. candidate
候補は候補とも呼ばれ、ホスト候補（ホスト候補）、サーバーリフレクション候補（srflx 候補）、リレー候補（リレー候補）など、ネットワークアドレス情報が含まれています。各種候補の意味は次のとおりです。
ホスト候補(Local Address)は、ローカルで使用するIPアドレスとポートで、例えばifconfig/ipconfigでWLANネットワークカードのIPアドレスは192.168.0.105、ポート51417は使用可能です。
Server Reflexive Address は、NAT マッピング後に使用される IP アドレスとポートです。
中継候補 (Relayed Address) は、TURN サーバーが開いた IP アドレスとポートです. TURN サーバーは、ピア NAT トラバーサルが失敗し、P2P 通信が確立できない場合に、TURN サーバーを介してデータパケットを転送するために使用されます. TURN サーバー通常、パブリック IP を持つマシン上にデプロイされます。
候補格式：a=candidate:{foundation} {component} {protocol} {priority} {ip} {port} typ {type} generation {generation} ufrag {username} network_id {id} network_cost {cost}
次の候補を例に取り、それが表す意味を説明します。
a=candidate:1221703924 1 udp 2122260223 192.168.0.105 51417 typ ホスト生成 0 ufrag Q8Wv ネットワーク ID 1 ネットワークコスト 10
typ host はローカル候補を意味し、使用する IP は 192.168.0.105、ポートは 51417、UDP プロトコルを使用、優先度は 2122260223、世代は代数を意味し、初期値は 0、候補が更新された場合、生成値が増加し、古い候補が置き換えられます。
WebRTC の例では、候補を収集できるツールが提供されています. このツールを使用して、ローカル アドレスとサーバー再帰アドレスを収集できます. TURN サーバーを構築し、TURN サービス アドレスを ICE サーバーに追加すると、中継アドレスも収集できます.
3.WebRTCコレクション候補のソースコード解析
ローカル SDP が createOffer によってローカルに生成されると、setLocalDescription が呼び出されてローカルの説明情報に設定され、候補が setLocalDescription に収集されます。
次のように、PeerConnection::DoSetLocalDescription が ApplyLocalDescription を完了すると、transport_controller_->MaybeStartGathering() を実行して候補の収集を開始します。
void PeerConnection::DoSetLocalDescription(
std::unique_ptr<SessionDescriptionInterface> desc,
rtc::scoped_refptr<SetSessionDescriptionObserver> observer) {
// 省略...(详见src/pc/peer_connection.cc)
error = ApplyLocalDescription(std::move(desc));
// 省略...
// MaybeStartGathering needs to be called after posting
// MSG_SET_SESSIONDESCRIPTION_SUCCESS, so that we don't signal any candidates
// before signaling that SetLocalDescription completed.
transport_controller_->MaybeStartGathering();
// 省略...
}現在のスレッドがネットワーク スレッドでない場合は、MaybeStartGathering のタスクをネットワーク スレッドに送信します。それ以外の場合は、dtls->ice_transport()->MaybeStartGathering() のロジックを実行します。
MaybeStartGathering のロジックは、現在の状態が候補を収集していない、または ICE の再起動を準備している状態である場合は、収集中の状態になり、 allocator_sessions_ にセッションを追加 (セッションは PortAllocatorSession オブジェクト) してから、セッションの StartGettingPorts。
StartGettingPorts を呼び出した後の駆動プロセスは、GetPortConfiguarations -> OnConfigReady -> OnAllocate -> OnAllocationSequenceObjectsCreated です。
GetPortConfigurations は、最初に PortConfiguration オブジェクト config を作成し、次に stun_servers、turn_servers アドレス情報を config オブジェクトに追加します。
OnConfigReady は、PortConfiguration オブジェクトを configs_ に詰め込むことです。
DoAllocate は OnAllocate で呼び出され、DoAllocate で最も重要なロジックは、ネットワークごとに AllocationSequence オブジェクトを生成することです (Network オブジェクトに慣れていない場合は、まずこのブログを読んで、WebRTC がネットワーク カード情報を収集するプロセスを理解してください)。
DoAllocate で Network、PortConfiguration、および sequence_flags を使用して AllocationSequence オブジェクトが作成された後、AllocationSequence オブジェクトに対して Init 初期化が実行されます。
AllocationSequence::Init は BasicPacketSocketFactory::CreateUdpSocket を呼び出して、ネットワークに対応する IP アドレスと範囲 [min_port, max_port] から選択された使用可能なポートにバインドされるソケットを作成します。ソケット作成の呼び出しプロセスは次のとおりです。
AllocationSequence::Init が実行された後、AllocationSequence::Start が呼び出されます。この関数は、主に MSG_ALLOCATION_PHASE メッセージをネットワーク スレッドに送信し、UDPPort、TcpPort、StunPort、RelayPort およびその他のオブジェクトの作成を駆動します。
ホスト候補の収集方法をCreateUDPPortsを例に説明します.サーバーリフレクションアドレス候補の収集についてはこちらのブログを、リレーアドレス候補の収集についてはこちらのブログをお読みください.
CreateUDPPorts のロジックは、まず UDPPort オブジェクトを作成し、次に BasicPortAllocatorSession::AddAllocatedPort で UDPPort を追加して処理します。
BasicPortAllocatorSession::AddAllocatedPort は、主にポート content_name や component などの属性を対象とし、いくつかのイベント コールバック処理関数を関連付けてから、PrepareAddress を実行します。
PrepareAddress は OnLocalAddressReady を呼び出し、OnLocalAddressReady は AddAddress を呼び出して候補を作成します。
ここまでで、ローカル候補が作成されました. サーバーリフレクションアドレス候補の収集については、このブログを参照してください. リレーアドレス候補の収集については、このブログを参照してください. 候補情報が作成された後、ネットワークスレッドは MSG_SEQUENCEOBJECTS_CREATED メッセージを送信します. , Callback OnAllocationSequenceObjectsCreated 候補の作成が完了しました。
