ICE Candidate: bu nədir, namizəd növləri və necə işləyir

ICE Candidate nədir?

ICE Candidate (Interactive Connectivity Establishment Candidate) — WebRTC protokolu ilə P2P əlaqəsi qurma prosesində əsas vahiddir. İki peer arasında məlumat ötürmək üçün istifadə edilə bilən IP ünvanı + port cütlüyünü təmsil edir. Hər bir namizəd nəqliyyat protokolu (UDP, TCP), əlaqə növü və prioritet haqqında məlumat ehtiva edir.

ICE Candidate hər bir cihazda ayrıca formalaşır. Cihaz bütün mövcud şəbəkə interfeyslərini toplayır, STUN serveri vasitəsilə xarici ünvanı sorğulayır və TURN serverindən rele ünvanını əlavə edir. Alınan namizədlər siyahısı SDP (Session Description Protocol) formatında siqnal kanalı vasitəsilə uzaq peera göndərilir.

RFC 8445 (IETF, 2018) spesifikasiyasına görə, ICE nominated pairs mexanizmindən istifadə edir: bütün namizədlər toplandıqdan sonra onların STUN sorğuları vasitəsilə cüt-cüt sınaqdan keçirilməsi aparılır. Sınaqdan ilk keçən cüt nominated (təyin edilmiş) elan edilir və multimedia ötürülməsi üçün istifadə olunur. Qalan cütlər əlaqə qırılması halında ehtiyatda qalır.

ICE-in WebRTC yığınında rolu

WebRTC — P2P kommunikasiyaları üçün açıq standartdır, lakin cihazlar arasında birbaşa əlaqə çox vaxt NAT (Network Address Translation) və firewalllar səbəbindən mümkün olmur. ICE Candidate bir neçə alternativ əlaqə yolu təklif edərək bu problemi həll edir. ICE (Interactive Connectivity Establishment) protokolu WebRTC-nin məcburi komponentidir və W3C WebRTC (2025) spesifikasiyasında təsvir edilmişdir.

Mobil tətbiq tərtibatçıları Google WebRTC (Android üçün) və iOS üçün native qabıqlar kimi WebRTC kitabxanalarından istifadə edirlər. Onların hər birində ICE prosesi avtomatik idarə olunur, lakin namizəd növlərini başa düşmək tərtibatçıya server infrastrukturunu konfiqurasiya etməyə və əlaqə keyfiyyətini optimallaşdırmağa imkan verir.

ICE namizədləri ilə SDP formatı

ICE Candidate SDP mesajının tərkibində a=candidate atributları şəklində ötürülür. Hər bir sətir foundation, component ID, nəqliyyat protokolu, prioritet, IP ünvanı, port və namizəd növünü ehtiva edir. Aşağıda müxtəlif növ üç namizədi olan SDP fraqmentinin nümunəsi verilmişdir:

// ICE namizədləri ilə nümunə SDP
a=candidate:1 1 UDP 2130706431 192.168.1.10 54321 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 54322 typ srflx
a=candidate:3 1 TCP 1019212287 198.51.100.7 54323 typ relay raddr 203.0.113.5 rport 3478

priority sahəsi namizədlərin sınaqdan keçirilmə qaydasını müəyyən edir. Prioritet nə qədər yüksəkdirsə, namizəd bir o qədər tez yoxlanılacaq. Host namizədləri həmişə ən yüksək prioritetə, relay isə ən aşağı prioritetə malikdir.

ICE namizədlərinin növləri

RFC 8445 spesifikasiyası dörd növ ICE namizədi müəyyən edir, onların hər biri uzaq peera çatmağın müəyyən bir yoluna uyğundur. Namizəd növü onun prioritetinə, əlaqə qurma vaxtına və server infrastrukturuna olan tələblərə təsir edir.

Host namizədləri

Host namizəd cihazın yerli şəbəkə interfeysinin IP ünvanından formalaşır. Cihaz peer ilə eyni yerli şəbəkədədirsə, host namizəd minimal gecikmə ilə birbaşa əlaqəni təmin edir. Mobil cihazlar üçün host namizədlər WiFi interfeysi, mobil LTE/5G əlaqəsi və zərurət olduqda VPN tunelləri üçün yaradılır.

Host namizədlər ən yüksək prioritetə (UDP üçün 2130706431) malikdir və ilk sınaqdan keçirilənlərdir. Hər iki peer NAT arxasındadırsa, onların host namizədləri şəxsi ünvanlar (192.168.x.x, 10.x.x.x) olacaq və onlar vasitəsilə birbaşa əlaqə mümkün deyil. ICE srflx və relay namizədlərini sınaqdan keçirməyə keçir.

SRFLX və PRFLX namizədləri

SRFLX (Server Reflexive) namizəd — STUN serverindən alınan xarici IP ünvanı və portdur. Cihaz STUN sorğusu göndərdikdə, server onun NAT-dan sonra ictimai ünvanını görür və onu geri qaytarır. Bu namizəd müxtəlif NATlar arxasında olan peerlər arasında birbaşa əlaqə qurmağa imkan verir, əgər onların NAT cihazları Hairpinning-i dəstəkləyirsə.

PRFLX (Peer Reflexive) namizəd bir peerdən STUN sorğusu gözlənilməz ünvana gəldikdə dinamik olaraq aşkar edilir. Bu növ hər iki peer eyni vaxtda sorğu göndərdikdə və NAT müvəqqəti bağlama yaratdıqda yaranır. PRFLX namizədi srflx-dən daha yüksək, lakin host-dan aşağı prioritetə malikdir.

Mobil tətbiqlərdə srflx namizədləri WiFi və mobil şəbəkə arasında keçid zamanı xüsusilə vacibdir. Cihaz şəbəkəni dəyişdikdə, IP ünvanı dəyişir və ICE namizədləri yenidən toplamalıdır. Bu proses ICE restart adlanır və yeni SDP-nin yenidən göndərilməsini tələb edir.

TURN vasitəsilə Relay namizədləri

Relay namizəd — trafikin bir peerdən digərinə ötürüldüyü TURN serverindəki ünvandır. Bu növ birbaşa P2P əlaqəsi mümkün olmadıqda (simmetrik NAT, korporativ firewall) ehtiyat variant kimi istifadə olunur. Rele kanalı gecikmə əlavə edir və server yükünü artırır, buna görə də optimal parametrlərdə TURN serveri bütün sessiyaların yalnız 10–15%-i üçün istifadə olunur.

Məşhur TURN server tətbiqləri: coturn (açıq mənbə), Twilio Network Traversal, Metered TURN. TURN provayderinin seçimi mobil tətbiqlərdə media əlaqəsinin keyfiyyətinə təsir edir — server əlavə gecikməni minimuma endirmək üçün coğrafi olaraq istifadəçilərə yaxın yerləşməlidir.

ICE prosesi necə işləyir

ICE prosesi — şəbəkə topologiyasının qeyri-müəyyənliyi şəraitində etibarlı P2P əlaqəsinin qurulmasını təmin edən çoxmərhələli protokoldur. Alqoritm RFC 8445-də təsvir edilmişdir və dörd məcburi mərhələni əhatə edir: namizədlərin toplanması, çeşidlənməsi, sınaqdan keçirilməsi və nominasiyası.

Mərhələ 1: namizədlərin toplanması

Hər bir cihaz bütün mövcud şəbəkə ünvanlarını toplayır. Bunun üçün WebRTC mühərriki yerli interfeysləri (host) sadalayır, STUN serverinə sorğu göndərir (srflx) və TURN serverindən rele ünvanını tələb edir (relay). Eyni zamanda cihaz peerdən daxil olan STUN sorğusu alarsa, prflx namizədini aşkar edə bilər.

Mobil inkişafda bu mərhələ əlaqə qurma vaxtı üçün kritikdir. iOS və Android-də namizədlərin toplanması şəbəkə sürətindən, STUN/TURN serverlərinin əlçatanlığından və aktiv şəbəkə interfeyslərinin sayından asılı olaraq 200 ms-dən 2 saniyəyə qədər çəkə bilər.

Mərhələ 2: cütlərin formalaşdırılması və çeşidlənməsi

Siqnal kanalı vasitəsilə uzaq peerdən namizədlər siyahısı alındıqdan sonra yerli ICE mühərriki bütün mümkün namizəd cütlərini (yerli + uzaq) formalaşdırır. Hər bir cüt RFC 8445-dən düsturla prioritet alır, bu hər iki namizədin prioritetlərini və istiqaməti (incoming/outgoing) nəzərə alır.

Cütlər prioritetə görə azalan sırada çeşidlənir. Ən yaxşı cütlər ilk sınaqdan keçirilir. Alqoritm host-host cütünün host-srflx, host-relay və ya relay-relay-dan əvvəl yoxlanılmasını təmin edir, sadə şəbəkə konfiqurasiyalarında əlaqə gecikməsini minimuma endirir.

Mərhələ 3: sınaqdan keçirmə və nominasiya

ICE hər bir namizəd cütü üçün STUN-binding sorğuları göndərir. STUN cavabı alınarsa — cüt etibarlıdır. İlk etibarlı cüt əsas olaraq nominated (təyin edilmiş) olur. WebRTC mühərriki bu cüt vasitəsilə media ötürməyə başlayır, qalan cütlər əsasın sıradan çıxması halında yoxlanılmağa davam edir.

Sınaq prosesi çox sayda namizəd olduqda bir neçə saniyəyə qədər çəkə bilər. WebRTC taymerlərdən istifadə edir: host cütləri üçün aqressiv taymer (20 ms), relay üçün daha konservativ (200 ms). Mobil tətbiq tərtibatçıları ICE serverlərinin sayını məhdudlaşdıraraq və ya iceTransportPolicy-ni konfiqurasiya edərək əlaqəni sürətləndirə bilər.

ICE Restart

ICE restart — bütün RTCPeerConnection-u yenidən yaratmadan ICE prosesinin yenidən başladılmasıdır. Şəbəkə dəyişikliyi, əlaqə itkisi və ya WiFi ilə mobil şəbəkə arasında keçid zamanı zəruridir. Restart zamanı bütün cari namizədlər sıfırlanır və proses yeni ufrag və pwd-nin yaradılması ilə yenidən başlayır.

iOS inkişafında ICE restart RTCPeerConnection-də restartIce() metodu ilə çağrılır. Android-də Google WebRTC-dən PeerConnection sinfində analoji metoddan istifadə olunur. ICE restart-ın düzgün işlənməsi — qeyri-sabit şəbəkə əlaqəsi olan mobil cihazlarda işləyən tətbiqlər üçün kritik tələbdir.

ICE-də STUN və TURN serverləri

STUN (Session Traversal Utilities for NAT) və TURN (Traversal Using Relays around NAT) — real internet şəraitində ICE Candidate-in uğurlu əlaqəyə zəmanət verə bilmədiyi əsas server komponentləridir. Onların düzgün konfiqurasiyası mobil tətbiqlərdə zəng keyfiyyətinə birbaşa təsir edir.

STUN: xarici ünvanın aşkarlanması

STUN serveri cihaza öz ictimai IP ünvanını və NAT-ın çıxan əlaqə üçün ayırdığı portu öyrənməyə imkan verir. STUN protokolu RFC 8489-da müəyyən edilmişdir və UDP üzərindən 3478 portunda işləyir, həmçinin TCP-ni dəstəkləyir. Google pulsuz istifadə edilə bilən ictimai STUN serverləri təqdim edir (stun.l.google.com:19302).

Mobil inkişafda STUN sorğusu — 50–200 ms çəkən yüngül əməliyyatdır. Bununla belə, bəzi korporativ və mobil şəbəkələr UDP trafikini bloklayır, ICE-i STUN rabitəsi üçün TCP-dən istifadə etməyə və ya birbaşa TURN-a keçməyə məcbur edir.

TURN: trafikin retranslyasiyası

TURN serveri — media trafikinin retranslyatorudur. Birbaşa P2P əlaqəsi mümkün olmadıqda (simmetrik NAT, firewall), cihaz məlumatları TURN-a göndərir, o da onları digər peera ötürür. TURN — etibarlı, lakin xərcli mexanizmdir: gecikmə əlavə edir (30–100 ms) və bütün media sessiyalarının cəminə bərabər ötürmə qabiliyyəti tələb edir.

WebRTC Stats Report (2025) məlumatlarına görə, mobil şəbəkələrdə WebRTC sessiyalarının təxminən 8–15%-i TURN tələb edir. TURN trafikinin xərclərini optimallaşdırmaq üçün tərtibatçılar əlaqənin ilkin sınaqdan keçirilməsindən istifadə edir və yalnız P2P uğursuz olduqda TURN kanalını aktivləşdirirlər.

Mobil tətbiq üçün STUN/TURN seçimi

Mobil layihədə ICE üçün infrastruktur seçərkən nəzərə alınır: gecikməni minimuma endirmək üçün serverlərin coğrafi yerləşməsi, UDP və TCP dəstəyi, TURN trafikinin dəyəri və SLA. Məşhur həllər: müstəqil quraşdırma üçün coturn, bulud istifadəsi üçün Twilio, Agora və LiveKit.

Mobil inkişafda ICE Candidate

Mobil tərtibatçılar üçün ICE Candidate-i başa düşmək nəzəriyyədən kənara çıxır — səsli və videozəngləri olan tətbiqlər yaratarkən bu praktiki zərurətdir. iOS və Android platformaları WebRTC üçün native API-lər təqdim edir, onlar ICE ilə işi avtomatlaşdırır, lakin tərtibatçı ICE serverlərinin konfiqurasiyasına və şəbəkə dəyişikliyi hadisələrinin işlənməsinə cavabdehdir.

iOS-da ICE konfiqurasiyası

iOS-da WebRTC WebRTC.framework çərçivəsi və ya CocoaPods vasitəsilə GoogleWebRTC kitabxanası vasitəsilə mövcuddur. ICE serverləri RTCConfiguration-də RTCIceServer massivi vasitəsilə konfiqurasiya edilir:

let config = RTCConfiguration()
let stunServer = RTCIceServer(urlStrings: ["stun:stun.l.google.com:19302"])
let turnServer = RTCIceServer(urlStrings: ["turn:turn.example.com:3478"],
                                    username: "user",
                                    credential: "pass")
config.iceServers = [stunServer, turnServer]
let pc = RTCPeerConnection(configuration: config)

RTCPeerConnection yaradıldıqdan və offer() və ya answer() çağırıldıqdan sonra mühərrik avtomatik olaraq ICE namizədlərini toplayır. iceGatheringStateChange hadisəsi toplama statusunun dəyişməsi barədə, iceConnectionState isə əlaqə vəziyyəti barədə xəbərdarlıq edir.

Android-də ICE konfiqurasiyası

Android eyni Google WebRTC kitabxanasından istifadə edir. ICE serverləri PeerConnection.RTCConfiguration vasitəsilə təyin edilir. Tərtibatçı ICE siyasətini iceTransportsType vasitəsilə idarə edə bilər — relay rejimi yalnız TURN-dan istifadə etməyə məcbur edir, bu etibarlılığı artırır, lakin gecikməni də artırır:

val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.l.google.com:19302").createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("pass")
        .createIceServer()
)
val config = PeerConnection.RTCConfiguration(iceServers)
config.iceTransportsType = PeerConnection.IceTransportsType.ALL
config.bundlePolicy = PeerConnection.BundlePolicy.MAXBUNDLE

bundlePolicy parametri ICE namizədlərinin sayına təsir edir — MAXBUNDLE rejimi bütün media axınlarını bir nəqliyyatda birləşdirir, namizədlərin ümumi sayını azaldır və əlaqəni sürətləndirir.

Mobil tətbiqdə ICE hadisələrinin işlənməsi

Tərtibatçının işləməli olduğu əsas ICE hadisələri: ICE əlaqə vəziyyəti (ICE connection state), toplama vəziyyətinin dəyişməsi (ICE gathering state) və yeni namizədin aşkarlanması. ICE toplama və sınaqdan keçirməni başa vurduqdan sonra onun vəziyyəti connected və ya completed-ə keçir.

Mobil şəbəkələrdə tez-tez WiFi və mobil rabitə arasında keçidlər baş verir. Şəbəkə dəyişdikdə ICE restart etməlidir, əks halda media axını kəsilir. Tərtibatçılar restartIce()-in avtomatik çağırılması üçün NetworkManager (iOS) və ya ConnectivityManager (Android) monitorinqini həyata keçirirlər.

Mobil tətbiqdə ICE-in uğurlu tətbiqi daxildir: etibarlı STUN/TURN serverlərinin seçilməsi, şəbəkə dəyişikliyi zamanı ICE restart-ın düzgün işlənməsi, əlaqə statusunu UI-də göstərmək üçün iceConnectionState-in konfiqurasiyası və RTCStatsReport vasitəsilə statistikanın monitorinqi.