メインコンテンツまでスキップ

17. Preserving Candidate Order While Trickling (トリクル中の候補順序の保持)

通常のICEの重要な側面は、特定の基礎とコンポーネントに対する接続性チェックが両方のエージェントによって同時に試行されることです。これにより、エージェントの前のファイアウォールまたはNATが両方のエンドポイントをホワイトリストに登録し、最初の(「自殺」)パケットを除くすべてのパケットが通過できるようになります。これは、適切なタイミングで候補を凍結解除するためにも重要です。これは重要ではありませんが、Trickle ICEでこの動作を保持すると、ICEのパフォーマンスが向上する可能性があります。

これを達成するために、候補をトリクルする際、エージェントは、コンポーネントIDによって反映されるコンポーネントの順序を尊重すべきです (SHOULD)。つまり、特定のコンポーネントの候補は、同じ基礎内のより低いID番号を持つコンポーネントの候補の前に送信されるべきではありません (SHOULD NOT)。さらに、候補は、セクション12の手順に従って、送信される順序と同じ順序でペアリングされるべきです (SHOULD)。

たとえば、次のSDP記述には、2つのコンポーネント(RTPとRTCP)と2つの基礎(ホストとサーバー再帰)が含まれています:

v=0
o=jdoe 2890844526 2890842807 IN IP4 10.0.1.1
s=
c=IN IP4 10.0.1.1
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
m=audio 5000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=candidate:1 1 UDP 2130706431 10.0.1.1 5000 typ host
a=candidate:1 2 UDP 2130706431 10.0.1.1 5001 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 5000 typ srflx
    raddr 10.0.1.1 rport 8998
a=candidate:2 2 UDP 1694498815 192.0.2.3 5001 typ srflx
    raddr 10.0.1.1 rport 8998

これらの候補情報の場合、ホストRTCP候補はホストRTP候補の前に送信されません。同様に、サーバー再帰RTP候補は、サーバー再帰RTCP候補と同時またはそれより前に送信されます。

に最終更新