Protocol de mesagerie în timp real - Real-Time Messaging Protocol

Protocolul de mesagerie în timp real ( RTMP ) este un protocol de comunicare pentru streaming audio, video și date pe internet. Dezvoltat inițial ca protocol proprietar de Macromedia pentru streaming între un player Flash și un server, Adobe (care a achiziționat Macromedia) a lansat o versiune incompletă a specificațiilor protocolului pentru uz public.

Protocolul RTMP are mai multe variante:

1. RTMP propriu-zis, protocolul „simplu” care funcționează deasupra protocolului de control al transmisiei (TCP) și folosește implicit numărul portului 1935.
2. RTMPS, care este RTMP printr-o conexiune Transport Layer Security (TLS / SSL).
3. RTMPE, care este criptat RTMP folosind propriul mecanism de securitate Adobe. În timp ce detaliile implementării sunt proprietare, mecanismul utilizează primitive criptografice standard din industrie.
4. RTMPT, care este încapsulat în cererile HTTP pentru traversarea firewall-urilor. RTMPT se găsește frecvent utilizând cereri de text clar pe porturile TCP 80 și 443 pentru a ocoli majoritatea filtrării traficului corporativ. Sesiunea încapsulată poate transporta pachete simple RTMP, RTMPS sau RTMPE.
5. RTMFP, care este RTMP peste User Datagram Protocol (UDP) în loc de TCP, înlocuind RTMP Chunk Stream. Suita Secure Protocol în timp real a fluxului media a fost dezvoltată de Adobe Systems și permite utilizatorilor finali să se conecteze și să comunice direct între ei (P2P).

În timp ce motivația principală pentru RTMP a fost să fie un protocol pentru redarea videoclipurilor Flash, acesta este utilizat și în alte aplicații, cum ar fi Adobe LiveCycle Data Services ES .

Operatie de baza

RTMP este un protocol bazat pe TCP care menține conexiuni persistente și permite comunicarea cu latență redusă. Pentru a livra fluxuri fără probleme și pentru a transmite cât mai multe informații posibil, acesta împarte fluxurile în fragmente, iar dimensiunea lor este negociată dinamic între client și server. Uneori, este păstrat neschimbat; dimensiunile implicite ale fragmentelor sunt 64 de octeți pentru datele audio și 128 octeți pentru datele video și majoritatea celorlalte tipuri de date. Fragmentele din diferite fluxuri pot fi apoi intercalate și multiplexate pe o singură conexiune. Cu bucăți de date mai lungi, protocolul poartă astfel doar un antet de un octet pe fragment, astfel încât să suporte foarte puține cheltuieli generale . Cu toate acestea, în practică, fragmentele individuale nu sunt de obicei intercalate. În schimb, intercalarea și multiplexarea se realizează la nivelul pachetelor, pachetele RTMP pe mai multe canale active diferite fiind intercalate în așa fel încât să se asigure că fiecare canal își îndeplinește lățimea de bandă, latența și alte cerințe de calitate a serviciului. Pachetele intercalate în acest mod sunt tratate ca indivizibile și nu sunt intercalate la nivel de fragment.

RTMP definește mai multe canale virtuale pe care pachetele pot fi trimise și primite și care funcționează independent unul de celălalt. De exemplu, există un canal pentru gestionarea cererilor și răspunsurilor RPC, un canal pentru date de flux video, un canal pentru date de flux audio, un canal pentru mesaje de control în afara benzii (negocierea dimensiunii fragmentelor etc.) etc. . În timpul unei sesiuni tipice RTMP, mai multe canale pot fi active simultan la un moment dat. Când datele RTMP sunt codificate, se generează un antet de pachet. Antetul pachetului specifică, printre altele, ID-ul canalului pe care urmează să fie trimis, un timestamp al momentului în care a fost generat (dacă este necesar) și dimensiunea sarcinii utile a pachetului. Acest antet este apoi urmat de conținutul real de încărcare utilă al pachetului, care este fragmentat în funcție de dimensiunea fragmentului convenit în prezent, înainte de a fi trimis prin conexiune. Antetul pachetului în sine nu este niciodată fragmentat, iar dimensiunea sa nu se ia în considerare pentru datele din primul fragment al pachetului. Cu alte cuvinte, doar sarcina utilă reală a pachetului (datele media) este supusă fragmentării.

La un nivel superior, RTMP încapsulează fluxuri audio MP3 sau AAC și video multimedia FLV1 și poate efectua apeluri de procedură la distanță (RPC) utilizând formatul mesajului de acțiune . Orice servicii RPC necesare sunt realizate asincron, utilizând un singur model de cerere / răspuns client / server, astfel încât să nu fie necesară comunicarea în timp real.

Criptare

Sesiunile RTMP pot fi criptate folosind oricare dintre cele două metode:

• Utilizarea mecanismelor standard TLS / SSL din industrie . Sesiunea RTMP de bază este pur și simplu înfășurată într-o sesiune normală TLS / SSL.
• Folosind RTMPE, care împachetează sesiunea RTMP într-un strat de criptare mai ușor.

Tunelare HTTP

În RTMP Tunneled (RTMPT), datele RTMP sunt încapsulate și schimbate prin HTTP , iar mesajele de la client (media player, în acest caz) sunt adresate portului 80 (implicit pentru HTTP) de pe server.

În timp ce mesajele din RTMPT sunt mai mari decât mesajele RTMP echivalente non-tunelate datorită antetelor HTTP, RTMPT poate facilita utilizarea RTMP în scenarii în care utilizarea RTMP non-tunelat nu ar fi posibilă altfel, cum ar fi atunci când clientul este în spatele acestuia un firewall care blochează traficul de ieșire non-HTTP și non-HTTPS.

Protocolul funcționează prin trimiterea de comenzi prin adresa URL POST și mesaje AMF prin corpul POST. Un exemplu este

POST /open/1 HTTP/1.1

pentru a se deschide o conexiune.

Document de caiet de sarcini și licență de brevet

Adobe a lansat o specificație pentru versiunea 1.0 a protocolului din 21 decembrie 2012. Pagina de destinație web care duce la respectiva specificație notează că „Pentru a beneficia clienții care doresc să își protejeze conținutul, specificația RTMP deschisă nu include măsurile RTMP sigure unice ale Adobe” .

Un document care însoțește specificația Adobe acordă licență de brevet „neexclusivă, fără redevențe, netransferabilă, nesublicențială, personală, la nivel mondial” pentru toate implementările protocolului, cu două restricții: una interzice utilizarea pentru interceptarea datelor în flux („orice tehnologie care interceptează fluxul de conținut video, audio și / sau de date pentru stocare pe orice dispozitiv sau mediu "), iar altul interzice eludarea„ măsurilor tehnologice de protecție a conținutului audio, video și / sau de date, inclusiv oricare dintre măsurile RTMP sigure ale Adobe ” .

Brevete și litigii conexe

Stefan Richter, autorul unor cărți despre Flash, a remarcat în 2008 că, deși Adobe este vag în ceea ce privește brevetele care se aplică RTMP, brevetul SUA 7.246.356 pare să fie unul dintre ele.

În 2011, Adobe a dat în judecată Wowza Media Systems, pretinzând, printre altele, încălcarea brevetelor lor RTMP. În 2015, Adobe și Wowza au anunțat că procesele au fost soluționate și respinse cu prejudicii.

Structura pachetelor

Diagrama pachetelor RTMP

Pachetele sunt trimise printr-o conexiune TCP care este stabilită mai întâi între client și server. Acestea conțin un antet și un corp care, în cazul comenzilor de conectare și control, este codificat utilizând formatul mesajului de acțiune (AMF). Antetul este împărțit în Antetul de bază (prezentat ca detașat de restul, în diagramă) și antetul mesajului blocat . Antetul de bază este singura parte constantă a pachetului și este de obicei compus dintr-un singur octet compozit , unde cei doi biți cei mai semnificativi sunt tipul de bucată ( fmt în specificație), iar restul formează ID-ul fluxului. În funcție de valoarea primelor, unele câmpuri ale antetului mesajului pot fi omise și valoarea lor derivată din pachetele anterioare, în timp ce în funcție de valoarea acestora din urmă, antetul de bază poate fi extins cu unul sau doi octeți suplimentari (ca în cazul din diagrama care are trei octeți în total (c)). Dacă valoarea celor șase biți rămași ai antetului de bază (BH) (cel mai puțin semnificativ) este 0, atunci BH este de doi octeți și reprezintă de la flux ID 64 la 319 (64 + 255); dacă valoarea este 1, atunci BH este de trei octeți (cu ultimii doi octeți codificați pe 16 biți Little Endian) și reprezintă de la flux ID 64 la 65599 (64 + 65535); dacă valoarea este 2, atunci BH este un octet și este rezervat pentru mesaje și comenzi de control de protocol de nivel scăzut. Antetul mesajului conține informații despre meta-date, cum ar fi dimensiunea mesajului (măsurată în octeți), Delta Timestamp și tipul mesajului . Această ultimă valoare este un singur octeț și definește dacă pachetul este un pachet RTMP audio, video, de comandă sau de "nivel scăzut", cum ar fi un ping RTMP.

Un exemplu este prezentat mai jos ca fiind capturat atunci când un client flash execută următorul cod:

var stream:NetStream = new NetStream(connectionObject);

aceasta va genera următorul fragment:

Pachetul începe cu un antet de bază cu un singur octet (0x03) în care cei doi biți cei mai semnificativi (b 00 000011) definesc un tip de antet bucată de 0, în timp ce restul (b00 000011 ) definesc un ID de flux de bucăți de 3. Cele patru posibile valorile tipului de antet și semnificația lor sunt:

• b00 = antet de 12 octeți (antet complet).
• b01 = 8 octeți - de tipul b00. fără a include ID-ul mesajului (4 ultimi octeți).
• b10 = 4 octeți - Antetul de bază și marcajul temporal (3 octeți) sunt incluse.
• b11 = 1 octet - este inclus doar antetul de bază.

Ultimul tip (b11) este întotdeauna utilizat în cazul mesajelor agregate unde, în exemplul de mai sus, al doilea mesaj va începe cu un id de 0xC3 (b11000011) și ar însemna că toate câmpurile antet mesaj ar trebui să fie derivate din mesajul cu un ID de flux de 3 (care ar fi mesajul chiar deasupra acestuia). Cei șase biți cel mai puțin semnificativi care formează ID-ul fluxului pot lua valori cuprinse între 3 și 63. Unele valori au o semnificație specială, cum ar fi 1, care reprezintă un format de ID extins, caz în care urmează doi octeți. O valoare de două este pentru mesajele de nivel scăzut, cum ar fi Ping și Set Client Bandwidth.

Următorii octeți ai antetului RTMP (inclusiv valorile din exemplul de pachet de mai sus) sunt decodificați după cum urmează:

• octet # 1 (0x03) = Tip antet bucată.
• octet # 2-4 (0x000b68) = Delta marcajului de timp.
• octet # 5-7 (0x000019) = Lungimea pachetului - în acest caz este 0x000019 = 25 octeți.
• octet # 8 (0x14) = ID tip mesaj - 0x14 (20) definește un mesaj de comandă codificat AMF0 .
• octet # 9-12 (0x00000000) = ID flux de mesaje. Aceasta este în ordine puțin endiană

Octetul ID tip mesaj definește dacă pachetul conține date audio / video, un obiect la distanță sau o comandă. Unele valori posibile pentru sunt:

• 0x01 = Setați mesajul pentru dimensiunea pachetului.
• 0x02 = Încetează.
• 0x03 = Recunoaște.
• 0x04 = Mesaj de control.
• 0x05 = Lățime de bandă a serverului
• 0x06 = Lățimea de bandă a clientului.
• 0x07 = Control virtual.
• 0x08 = pachet audio.
• 0x09 = pachet video.
• 0x0F = Date extinse.
• 0x10 = Container extins.
• 0x11 = Comandă extinsă (o comandă de tip AMF3).
• 0x12 = Date (Invocare (informațiile onMetaData sunt trimise ca atare)).
• 0x13 = Container.
• 0x14 = Comandă (o comandă de tip AMF0).
• 0x15 = UDP
• 0x16 = Agregat
• 0x17 = Prezent

După antet, 0x02 denotă un șir de dimensiuni 0x000C și valori 0x63 0x72 ... 0x6D (comanda "createStream"). În continuare, avem un 0x00 (număr), care este id-ul tranzacției cu valoarea 2.0. Ultimul octet este 0x05 (nul) ceea ce înseamnă că nu există argumente.

Invocați structura mesajului (0x14, 0x11)

Unele dintre tipurile de mesaje prezentate mai sus, cum ar fi Ping și Setare lățime de bandă client / server, sunt considerate mesaje de protocol RTMP de nivel scăzut, care nu utilizează formatul de codificare AMF. Mesajele de comandă pe de altă parte, indiferent dacă AMF0 (tip de mesaj 0x14) sau AMF3 (0x11), utilizează formatul și au forma generală prezentată mai jos:

(String) <Command Name>
(Number) <Transaction Id>
(Mixed)  <Argument> ex. Null, String, Object: {key1:value1, key2:value2 ... }

ID-ul tranzacției este utilizat pentru comenzile care pot avea un răspuns. Valoarea poate fi fie un șir ca în exemplul de mai sus, fie unul sau mai multe obiecte, fiecare compus dintr-un set de perechi cheie / valoare în care cheile sunt întotdeauna codificate ca șiruri, în timp ce valorile pot fi orice tip de date AMF, inclusiv tipuri complexe, cum ar fi matrice.

Structura mesajului de control (0x04)

Mesajele de control nu sunt codificate AMF. Încep cu un ID de flux 0x02 care implică un antet complet (tip 0) și au un tip de mesaj 0x04. Antetul este urmat de șase octeți care sunt interpretați ca atare:

• # 0-1 - Tip de control.
• # 2-3 - Al doilea parametru (aceasta are semnificație în anumite tipuri de control)
• # 4-5 - Al treilea parametru (același)

Primii doi octeți ai corpului mesajului definesc tipul de Ping, care poate lua aparent șase valori posibile.

• Tipul 0 - Clear Stream: Trimis când conexiunea este stabilită și nu conține date suplimentare
• Tastați 1 - Ștergeți tamponul.
• Tipul 2 - Flux uscat.
• Tipul 3 - Timpul tampon al clientului. Al treilea parametru deține valoarea în milisecunde.
• Tastați 4 - Resetați un flux.
• Tipul 6 - Ping clientul de pe server. Al doilea parametru este ora curentă.
• Tipul 7 - Răspunsul Pong de la client. Al doilea parametru este momentul în care clientul primește Ping.
• Tipul 8 - Cerere UDP.
• Tipul 9 - Răspuns UDP.
• Tipul 10 - Limita lățimii de bandă.
• Tipul 11 ​​- Lățime de bandă.
• Tipul 12 - Lățimea de bandă a clapetei de accelerație.
• Tipul 13 - Flux creat.
• Tipul 14 - Flux șters.
• Tipul 15 - Setați accesul la citire.
• Tastați 16 - Setați accesul la scriere.
• Tastați 17 - Solicitare Meta Stream.
• Tipul 18 - Răspuns Meta Stream.
• Tipul 19 - Obțineți limita segmentului.
• Tipul 20 - Setați limita segmentului.
• Tastați 21 - La Deconectare.
• Tipul 22 - Setați legătura critică.
• Tipul 23 - Deconectați.
• Tastați 24 - Actualizare Hash.
• Tastați 25 - Hash Timeout.
• Tastați 26 - Cerere Hash.
• Tipul 27 - Răspuns Hash.
• Tipul 28 - Verificați lățimea de bandă.
• Tastați 29 - Setați accesul la probele audio.
• Tipul 30 - Setați accesul la probele video.
• Tipul 31 - Accelerația începe.
• Tipul 32 - Capăt de accelerație.
• Tipul 33 - Notificare DRM.
• Tipul 34 - RTMFP Sync.
• Tipul 35 - Interogare IHello.
• Tipul 36 - Înainte IHello.
• Tipul 37 - Redirecționează IHello.
• Tipul 38 - Notificați EOF.
• Tastați 39 - Proxy Continuați.
• Tastați 40 - Proxy Remove Upstream.
• Tipul 41 - Set RTMFP Keepalives.
• Tipul 46 - Segmentul nu a fost găsit.

Pong este numele pentru un răspuns la un Ping cu valorile utilizate așa cum se vede mai sus.

ServerBw / ClientBw Structura mesajelor (0x05, 0x06)

Acest lucru se referă la mesaje care au legătură cu rata de biți a clientului în sus și a serverului în aval. Corpul este compus din patru octeți care arată valoarea lățimii de bandă cu o posibilă extensie a unui octet care setează Limit Type. Aceasta poate avea una dintre cele trei valori posibile care pot fi: dur, moale sau dinamic (fie moale, fie tare).

Setați dimensiunea bucății (0x01)

Valoarea primită în cei patru octeți ai corpului. Există o valoare implicită de 128 octeți și mesajul este trimis numai atunci când se dorește o modificare.

Protocol

Diagrama strângerii de mână RTMP

Strângere de mână

După stabilirea unei conexiuni TCP, o conexiune RTMP se stabilește mai întâi efectuând o strângere de mână prin schimbul a trei pachete din fiecare parte (denumită și Chunks în documentația oficială). Acestea sunt denumite în specificațiile oficiale C0-2 pentru pachetele trimise de client și respectiv S0-2 pentru partea serverului și nu trebuie confundate cu pachetele RTMP care pot fi schimbate numai după terminarea strângerii de mână. Aceste pachete au o structură proprie și C1 conține un câmp care setează marca de timp „epocă”, dar din moment ce aceasta poate fi setată la zero, așa cum se face în implementările terților, pachetul poate fi simplificat. Clientul inițializează conexiunea trimițând pachetul C0 cu o valoare constantă de 0x03 reprezentând versiunea de protocol curentă. Urmează drept cu C1 fără a aștepta primirea S0 care conține 1536 octeți, primii patru reprezentând marcajul de timp, al doilea patru fiind 0, iar restul fiind aleator (și care poate fi setat la 0 în terță parte implementări). C2 și S2 sunt un ecou al lui S1 și, respectiv, C1, cu excepția celui de-al doilea patru octeți fiind momentul în care mesajul respectiv a fost primit (în loc de 0). După primirea C2 și S2, strângerea de mână este considerată completă.

Conectați

În acest moment, clientul și serverul pot negocia o conexiune prin schimbul de mesaje codate AMF . Acestea includ perechi de valori cheie care se referă la variabilele necesare pentru stabilirea unei conexiuni. Un exemplu de mesaj de la client este:

(Invoke) "connect"
(Transaction ID) 1.0
(Object1) { app: "sample", flashVer: "MAC 10,2,153,2", swfUrl: null,
              tcUrl: "rtmpt://127.0.0.1/sample ", fpad: false,
              capabilities: 9947.75 , audioCodecs: 3191, videoCodecs: 252,
              videoFunction: 1 , pageUrl: null, objectEncoding: 3.0 }

Flash Media Server și alte implementări utilizează conceptul de „aplicație” pentru a defini conceptual un container pentru conținut audio / video și alt conținut, implementat ca un folder pe rădăcina serverului care conține fișierele media care trebuie transmise în flux. Prima variabilă conține numele acestei aplicații ca „eșantion”, care este numele furnizat de serverul Wowza pentru testarea lor. flashVerȘirul este același ca și returnat de Acțiune script getversion()funcția. audioCodecȘi videoCodecsunt codificate ca duble și semnificația lor pot fi găsite în spec originală. Același lucru este valabil și pentru videoFunctionvariabila care în acest caz este constanta SUPPORT_VID_CLIENT_SEEK care se explică de la sine. De un interes special este cel objectEncodingcare va defini dacă restul comunicării va folosi sau nu formatul AMF3 extins . Deoarece versiunea 3 este valoarea implicită curentă, clientului flash trebuie să i se spună în mod explicit în codul Action-script să utilizeze AMF0 dacă este solicitat. Serverul răspunde apoi cu un ServerBW, un ClientBW și o secvență de mesaje SetPacketSize, urmată în cele din urmă de o Invocare, cu un mesaj de exemplu.

(Invoke) "_result"
(transaction ID) 1.0
(Object1) { fmsVer: "FMS/3,5,5,2004", capabilities: 31.0, mode: 1.0 }
(Object2) { level: "status", code: "NetConnection.Connect.Success",
                   description: "Connection succeeded",
                   data: (array) { version: "3,5,5,2004" },
                   clientId: 1728724019, objectEncoding: 3.0 }

Unele dintre valorile de mai sus sunt serializate în proprietăți ale unui obiect generic Action-script care este apoi transmis ascultătorului de evenimente NetConnection. Se clientIdva stabili un număr pentru ca sesiunea să fie pornită de conexiune. Codificarea obiectelor trebuie să se potrivească cu valoarea setată anterior.

Rulează video

Pentru a porni un flux video, clientul trimite o invocație „createStream” urmată de un mesaj ping, urmată de o invocație „redare” cu numele fișierului ca argument. Serverul va răspunde apoi cu o serie de comenzi „onStatus” urmate de datele video încapsulate în mesajele RTMP.

După stabilirea unei conexiuni, media este trimisă prin încapsularea conținutului etichetelor FLV în mesaje RTMP de tip 8 și respectiv pentru audio și video.

Tunelare HTTP (RTMPT)

Aceasta se referă la versiunea HTTP a tunelului protocolului. Comunică prin portul 80 și transmite datele AMF din cererea și răspunsurile HTTP POST. Secvența pentru conectare este următoarea:

POST /fcs/ident2 HTTP/1.1
Content-Type: application/x-fcs\r\n

HTTP/1.0 404 Not Found

POST /open/1 HTTP/1.1
Content-Type: application/x-fcs\r\n

HTTP/1.1 200 OK
Content-Type: application/x-fcs\r\n
    1728724019

Prima cerere are o /fcs/ident2cale și răspunsul corect este o eroare 404 Not Found. Clientul trimite apoi o cerere / open / 1 în care serverul trebuie să răspundă cu un 200 ok adăugând un număr aleatoriu care va fi folosit ca identificator de sesiune pentru comunicarea menționată. În acest exemplu, 1728724019 este returnat în corpul răspunsului.

POST /idle/1728724019/0 HTTP/1.1
HTTP/1.1 200 OK
   0x01

De acum înainte /idle/<session id>/<sequence #>este o cerere de sondare în care ID-ul sesiunii a fost generat și returnat de pe server și secvența este doar un număr care crește cu unul pentru fiecare cerere. Răspunsul adecvat este un 200 OK cu un număr întreg returnat în corpul care semnifică intervalul de timp. Datele AMF sunt trimise prin/send/<session id>/<sequence #>

Implementări software

RTMP este implementat în aceste trei etape:

• Codificator video live
• Server de streaming media live și la cerere
• Client live și la cerere

rtmpdump

Instrumentul de linie de comandă client RTMP open source rtmpdump este conceput pentru a reda sau a salva pe disc fluxul complet RTMP, inclusiv protocolul RTMPE pe care îl folosește Adobe pentru criptare. RTMPdump rulează pe Linux, Android, Solaris, Mac OS X și majoritatea altor sisteme de operare derivate de Unix, precum și pe Microsoft Windows. Suportând inițial toate versiunile de Windows pe 32 de biți, inclusiv Windows 98, de la versiunea 2.2, software-ul va rula numai pe Windows XP și versiuni ulterioare (deși versiunile anterioare rămân pe deplin funcționale).

Pachetele pachetului de software rtmpdump sunt disponibile în principalele depozite open-source (distribuții Linux). Acestea includ aplicațiile front-end „rtmpdump”, „rtmpsrv” și „rtmpsuck”.

Dezvoltarea RTMPdump a fost reluată în octombrie 2009, în afara Statelor Unite, pe site-ul MPlayer . Versiunea actuală caracteristici îmbunătățite considerabil funcționalitatea, și a fost rescris pentru a profita de avantajele limbajului de programare C . În special, funcționalitatea principală a fost încorporată într-o bibliotecă (librtmp) care poate fi ușor utilizată de alte aplicații. Dezvoltatorii RTMPdump au scris, de asemenea, suport pentru librtmp pentru MPlayer , FFmpeg , XBMC , cURL , VLC și o serie de alte proiecte software open source. Utilizarea librtmp oferă acestor proiecte suport complet al RTMP în toate variantele sale, fără niciun efort suplimentar de dezvoltare.

FLVstreamer

FLVstreamer este un fork al RTMPdump, fără codul despre care Adobe susține că încalcă DMCA din SUA. Aceasta a fost dezvoltată ca răspuns la încercarea Adobe din 2008 de a suprima RTMPdump. FLVstreamer este un client RTMP care va salva un flux de conținut audio sau video de pe orice server RTMP pe disc, dacă criptarea (RTMPE) nu este activată pe flux.

Vezi si

• Informații de streaming protejate despre RTMPS și RTMPE
• Video la cerere (VoD)
• Extensii sursă media (MSE)
• WebSocket

Referințe

linkuri externe

• Pagina dezvoltatorului Adobe - RTMP - specificație oficială