Transportní protokol v reálném čase - Real-time Transport Protocol

Sada internetového protokolu
Aplikační vrstva
Transportní vrstva
Internetová vrstva
Propojit vrstvu

The Transportní protokol v reálném čase (RTP) je síťový protokol pro doručování zvuku a videa IP sítě. RTP se používá v komunikačních a zábavních systémech, které zahrnují streamování médií, jako telefonie, videokonference aplikace včetně WebRTC, televizní služby a webové push-to-talk funkce.

RTP obvykle běží znovu Protokol uživatele Datagram (UDP). RTP se používá ve spojení s RTP Control Protocol (RTCP). Zatímco RTP přenáší mediální toky (např. Audio a video), RTCP se používá ke sledování statistik přenosu a kvalita služeb (QoS) a pomůcky synchronizace více proudů. RTP je jedním z technických základů Voice over IP a v této souvislosti se často používá ve spojení s a signalizační protokol tak jako Protokol zahájení relace (SIP), který navazuje připojení přes síť.

RTP byl vyvinut pracovní skupinou pro přenos zvuku a videa v Pracovní skupina pro internetové inženýrství (IETF) a poprvé publikováno v roce 1996 jako RFC  1889 který byl poté nahrazen RFC  3550 v roce 2003.

Přehled

RTP je určen pro end-to-end, reálný čas převod streamování médií. Protokol poskytuje možnosti pro chvění kompenzace a detekce ztráta paketů a dodání mimo objednávku, které jsou běžné zejména při přenosu UDP v síti IP. RTP umožňuje přenos dat do více cílů prostřednictvím Vícesměrové vysílání IP.[1] RTP je považován za primární standard přenosu zvuku / videa v sítích IP a používá se s přidruženým formátem profilu a užitečného zatížení.[2] Návrh RTP je založen na architektonickém principu známém jako rámování aplikační vrstvy kde jsou v aplikaci implementovány funkce protokolu na rozdíl od operačních systémů zásobník protokolu.

Reálný čas multimédia streamovací aplikace vyžadují včasné dodání informací a k dosažení tohoto cíle často mohou tolerovat ztrátu paketů. Například ztráta paketu ve zvukové aplikaci může mít za následek ztrátu zlomku sekundy zvukových dat, což lze při použití vhodných chyba maskování algoritmy.[3] The protokol kontroly přenosu (TCP), ačkoli je standardizován pro použití RTP,[4] se v aplikacích RTP obvykle nepoužívá, protože TCP upřednostňuje spolehlivost před včasností. Místo toho je většina implementací RTP postavena na Protokol uživatele Datagram (UDP).[3] Jiné transportní protokoly speciálně určené pro multimediální relace jsou SCTP[5] a DCCP,[6] ačkoli od roku 2012, nejsou široce používány.[7]

RTP byl vyvinut pracovní skupinou Audio / Video Transport organizace pro standardy IETF. RTP se používá ve spojení s dalšími protokoly, jako je H.323 a RTSP.[2] Specifikace RTP popisuje dva protokoly: RTP a RTCP. RTP se používá k přenosu multimediálních dat a RTCP se používá k pravidelnému odesílání řídicích informací a parametrů QoS.[8]

Protokol přenosu dat, RTP, přenáší data v reálném čase. Informace poskytované tímto protokolem zahrnují časová razítka (pro synchronizaci), pořadová čísla (pro detekci ztráty paketů a přeskupování) a formát užitečného zatížení, který označuje kódovaný formát dat.[9] Řídicí protokol, RTCP, se používá pro zpětnou vazbu QoS (Quality of Service) a synchronizaci mezi mediálními proudy. Šířka pásma RTCP provozu ve srovnání s RTP je malá, obvykle kolem 5%.[9][10]

RTP relace se obvykle iniciují mezi komunikujícími partnery pomocí signalizačního protokolu, jako je H.323, Protokol zahájení relace (SIP), RTSP nebo Cinkot (XMPP ). Tyto protokoly mohou používat Protokol popisu relace určit parametry relací.[11]

Pro každý multimediální stream je vytvořena relace RTP. Zvukové a obrazové toky mohou používat samostatné relace RTP, což umožňuje přijímači selektivně přijímat komponenty konkrétního streamu.[12] Návrh RTP a RTCP je nezávislý na transportním protokolu. Aplikace nejčastěji používají UDP s čísly portů v neprivilegovaném rozsahu (1024 až 65535).[13] The Stream Control Protocol přenosu (SCTP) a Protokol kontroly zahlcení datagramu (DCCP) lze použít, když je požadován spolehlivý přenosový protokol. Specifikace RTP doporučuje sudá čísla portů pro RTP a použití dalšího lichého čísla portu pro přidruženou relaci RTCP.[14]:68 Jeden port lze použít pro RTP a RTCP v aplikacích, které multiplexují protokoly.[15]

RTP používají multimediální aplikace v reálném čase, jako je hlas přes IP, audio přes IP, WebRTC a Televize internetového protokolu

Profily a formáty užitečného zatížení

Hlavní článek: RTP užitečné formáty

RTP je navržen tak, aby přenášel velké množství multimediálních formátů, což umožňuje vývoj nových formátů bez revize standardu RTP. Za tímto účelem nejsou informace vyžadované konkrétní aplikací protokolu zahrnuty do obecné RTP hlavičky. Pro každou třídu aplikací (např. Audio, video) definuje RTP a profil a související formáty užitečného zatížení.[8] Každá instance RTP v konkrétní aplikaci vyžaduje specifikaci profilu a formátu užitečného zatížení.[14]:71

Profil definuje kodeky použité ke kódování dat užitečného zatížení a jejich mapování na kódy formátu užitečného zatížení v poli protokolu Typ užitečného zatížení (PT) záhlaví RTP. Každý profil je doprovázen několika specifikacemi formátu užitečného zatížení, z nichž každý popisuje přenos konkrétních kódovaných dat.[2] Příklady zvukových formátů užitečného zatížení jsou G.711, G.723, G.726, G.729, GSM, QCELP, MP3, a DTMF a příklady užitečných zatížení videa jsou H.261, H.263, H.264, H.265 a MPEG-1 /MPEG-2.[16] Mapování MPEG-4 audio / video streamy do RTP paketů je specifikováno v RFC  3016 a užitečná zatížení videa H.263 jsou popsána v RFC  2429.[17]

Mezi příklady profilů RTP patří:

Záhlaví paketu

Pakety RTP se vytvářejí na aplikační vrstvě a předávají se transportní vrstvě k doručení. Každá jednotka dat RTP médií vytvořená aplikací začíná záhlaví RTP paketu.

Záhlaví RTP paketu
OfsetyOktet0123
OktetBit [A]012345678910111213141516171819202122232425262728293031
00VerzePXCCMPTPořadové číslo
432Časové razítko
864SSRC identifikátor
1296Identifikátory CSRC
...
12 + 4 × CC96 + 32 × CCID záhlaví rozšíření specifické pro profilDélka záhlaví rozšíření
16 + 4 × CC128 + 32 × CCZáhlaví rozšíření
...

Záhlaví RTP má minimální velikost 12 bajtů. Po záhlaví mohou být přítomna volitelná rozšíření záhlaví. Následuje RTP užitečné zatížení, jehož formát je určen konkrétní třídou aplikace.[20] Pole v záhlaví jsou následující:

  • Verze: (2 bity) Označuje verzi protokolu. Aktuální verze je 2.[21]
  • P (polstrování): (1 bit) Používá se k označení, zda jsou na konci RTP paketu další bajty vyplnění. Výplň lze použít k vyplnění bloku určité velikosti, například podle požadavku šifrovacího algoritmu. Poslední bajt výplně obsahuje počet bajtů výplně, které byly přidány (včetně jeho samotného).[14]:12[21]
  • X (rozšíření): (1 bit) Označuje přítomnost znaku hlavička rozšíření mezi záhlaví a daty užitečného zatížení. Záhlaví rozšíření je specifické pro aplikaci nebo profil.[21]
  • CC (počet CSRC): (4 bity) Obsahuje počet identifikátorů CSRC (definovaných níže), které následují po SSRC (definovaných níže).[14]:12
  • M (značka): (1 bit) Signalizace použitá na úrovni aplikace způsobem specifickým pro profil. Pokud je nastaveno, znamená to, že aktuální data mají pro aplikaci zvláštní význam.[14]:13
  • PT (Payload type): (7 bitů) Označuje formát užitečného zatížení a určuje tak jeho interpretaci aplikací. Hodnoty jsou specifické pro profil a mohou být dynamicky přiřazovány.[22]
  • Pořadové číslo: (16 bitů) Pořadové číslo se zvyšuje pro každý odeslaný datový paket RTP a má být použit přijímačem k detekci ztráty paketu[1] a ubytovat se dodání mimo objednávku. Počáteční hodnota pořadového čísla by měla být náhodně vytvořena útoky se známým prostým textem na Zabezpečený přenosový protokol v reálném čase obtížnější.[14]:13
  • Časové razítko: (32 bitů) Používá přijímač k přehrávání přijatých vzorků ve vhodný čas a interval. Pokud je k dispozici několik mediálních proudů, časová razítka mohou být v každém proudu nezávislá.[b] Granularita načasování je specifická pro konkrétní aplikaci. Například audio aplikace, která vzorkuje data jednou za 125 µs (8 kHz, běžná vzorkovací frekvence v digitální telefonii), použije tuto hodnotu jako rozlišení hodin. Video streamy obvykle používají hodiny 90 kHz. Granularita hodin je jednou z podrobností, která je uvedena v profilu RTP pro aplikaci.[23]
  • SSRC: (32 bitů) Identifikátor zdroje synchronizace jednoznačně identifikuje zdroj streamu. Zdroje synchronizace ve stejné relaci RTP budou jedinečné.[14]:15
  • CSRC: (Každý 32 bitů, počet záznamů je označen symbolem Počet CSRC pole) Přispívající ID zdroje výčet přispívajících zdrojů do streamu, který byl vygenerován z více zdrojů.[14]:15
  • Rozšíření záhlaví: (volitelně, přítomnost označena Rozšíření Pole) První 32bitové slovo obsahuje identifikátor specifický pro profil (16 bitů) a specifikátor délky (16 bitů), který označuje délku rozšíření v 32bitových jednotkách, s výjimkou 32 bitů záhlaví rozšíření. Následuje data záhlaví rozšíření.[14]:18

Návrh aplikace

Funkční multimediální aplikace vyžaduje další protokoly a standardy používané ve spojení s RTP. Protokoly jako SIP, Cinkot, RTSP, H.225 a H.245 slouží k zahájení, ovládání a ukončení relace. Pro kódování dat užitečného zatížení, jak je uvedeno v příslušném profilu RTP, se používají další standardy, například H.264, MPEG a H.263.[24]

Odesílatel RTP zachytí multimediální data, poté je zakóduje, orámuje a odešle jako RTP pakety s příslušnými časovými značkami a zvyšujícími se časovými značkami a pořadovými čísly. Odesílatel nastaví typ užitečného zatížení pole v souladu s vyjednáváním připojení a používaným profilem RTP. Přijímač RTP detekuje chybějící pakety a může změnit pořadí paketů. Dekóduje mediální data v paketech podle typu užitečné zátěže a prezentuje stream svému uživateli.[24]

Standardizované dokumenty

  • RFC  3550, Standard 64, RTP: Transportní protokol pro aplikace v reálném čase
  • RFC  3551, Standard 65, RTP profil pro audio a video konference s minimální kontrolou
  • RFC  4855, Registrace typu média formátů užitečného zatížení RTP
  • RFC  4856, Registrace typu média formátů užitečného zatížení v profilu RTP pro audio a video konference
  • RFC  7656, Taxonomie sémantiky a mechanismů pro zdroje protokolu RTP (Real-Time Transport Protocol)
  • RFC  3190, RTP formát užitečného zatížení pro 12bitové verze DAT audio a 20- a 24bitový lineární vzorkovaný zvuk
  • RFC  6184, Formát RTP užitečného zatížení pro H.264 Video
  • RFC  3640, Formát RTP užitečné zátěže pro transport základních proudů MPEG-4
  • RFC  6416, Formát RTP užitečného zatížení pro MPEG-4 Audio / vizuální toky
  • RFC  2250, Formát RTP užitečného zatížení pro MPEG1 /Video MPEG2

Viz také

Poznámky

  1. ^ Bity jsou seřazeny od nejvýznamnějšího k nejméně významnému; bit offset 0 je nejvýznamnější bit prvního oktetu. Vysílají se oktety síťová objednávka. Pořadí bitového přenosu je středně závislé.
  2. ^ RFC  7273 poskytuje prostředky pro signalizaci vztahu mezi hodinami médií různých proudů.

Reference

  1. ^ A b Daniel Hardy (2002). Síť. De Boeck Université. p.298.
  2. ^ A b C Perkins 2003, str. 55
  3. ^ A b Perkins 2003, str. 46
  4. ^ RFC  4571
  5. ^ Farrel, Adrian (2004). Internet a jeho protokoly. Morgan Kaufmann. p. 363. ISBN  978-1-55860-913-6.
  6. ^ Ozaktas, Haldun M .; Levent Onural (2007). TROJROZMĚRNÁ TELEVIZE. Springer. p. 356. ISBN  978-3-540-72531-2.
  7. ^ Hogg, Scott. „A co Stream Control Transmission Protocol (SCTP)?“. Síťový svět. Citováno 2017-10-04.
  8. ^ A b Larry L. Peterson (2007). Počítačové sítě. Morgan Kaufmann. p.430. ISBN  978-1-55860-832-0.
  9. ^ A b Perkins 2003, str. 56
  10. ^ Peterson 2007, str. 435
  11. ^ RFC  4566: SDP: Session Description Protocol, M. Handley, V. Jacobson, C. Perkins, IETF (červenec 2006)
  12. ^ Zurawski, Richard (2004). „Protokoly RTP, RTCP a RTSP“. Příručka pro průmyslové informační technologie. CRC Press. str.28–7. ISBN  978-0-8493-1985-3.
  13. ^ Collins, Daniel (2002). Msgstr "Přeprava hlasu pomocí IP". Hlas přes IP nosiče. McGraw-Hill Professional. str.47. ISBN  978-0-07-136326-6.
  14. ^ A b C d E F G h i RFC  3550
  15. ^ Multiplexování datových a kontrolních paketů RTP na jednom portu. IETF. Duben 2010. doi:10.17487 / RFC5761. RFC 5761. Citováno 21. listopadu 2015.
  16. ^ Perkins 2003, str. 60
  17. ^ Chou, Philip A .; Mihaela van der Schaar (2007). Multimédia přes IP a bezdrátové sítě. Akademický tisk. str.514. ISBN  978-0-12-088480-3.
  18. ^ Perkins 2003, str. 367
  19. ^ Breese, Finley (2010). Sériová komunikace přes RTP / CDP. BoD - Books on Demand. str.[1]. ISBN  978-3-8391-8460-8.
  20. ^ Peterson 2007, str. 430
  21. ^ A b C Peterson 2007, str. 431
  22. ^ Perkins 2003, str. 59
  23. ^ Peterson, str.432
  24. ^ A b Perkins 2003, s. 11–13

externí odkazy