Passa al contenuto principale

17. Preserving Candidate Order While Trickling (Preservazione dell'ordine dei candidati durante il trickling)

Un aspetto importante di ICE regolare è che i controlli di connettività per una fondazione e un componente specifici vengono tentati simultaneamente da entrambi gli agenti, in modo che i firewall o NAT davanti agli agenti mettano in whitelist entrambi gli endpoint e consentano a tutti i pacchetti tranne il primo ("suicide") di passare. Questo è anche importante per congelare i candidati al momento giusto. Sebbene questo non sia cruciale, preservare questo comportamento in Trickle ICE è probabile che migliori le prestazioni ICE.

Per raggiungere questo obiettivo, durante il trickling dei candidati, gli agenti dovrebbero (SHOULD) rispettare l'ordine dei componenti come riflesso dai loro ID di componente; cioè, i candidati per un dato componente non dovrebbero (SHOULD NOT) essere trasmessi prima dei candidati per un componente con un numero ID inferiore all'interno della stessa fondazione. Inoltre, i candidati dovrebbero (SHOULD) essere accoppiati, seguendo le procedure della Sezione 12, nello stesso ordine in cui vengono trasmessi.

Ad esempio, la seguente descrizione SDP contiene due componenti (RTP e RTCP) e due fondazioni (host e server-reflexive):

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

Per queste informazioni sui candidati, il candidato host RTCP non verrebbe trasmesso prima del candidato host RTP. Allo stesso modo, il candidato server-reflexive RTP verrebbe trasmesso con o prima del candidato server-reflexive RTCP.

Ultimo aggiornamento il