RTP-kontrolprotokol - RTP Control Protocol
Den RTP Control Protocol ( RTCP ) er en søster-protokollen af Real-time Transport Protocol (RTP). Dens grundlæggende funktionalitet og pakkestruktur er defineret i RFC 3550. RTCP leverer statistikker uden for båndet og kontroloplysninger til en RTP-session. Det samarbejder med RTP om levering og emballering af multimediedata, men transporterer ikke selv mediedata.
Den primære funktion af RTCP er at give feedback på kvaliteten af den service (QoS) i distributionen medier ved jævnligt at sende statistik oplysninger såsom overførte Oktet og pakke tæller, pakketab , pakke forsinkelse variation og tur-retur forsinkelse til deltagerne i en streaming multimediesession. En applikation kan bruge denne information til at kontrollere kvaliteten af serviceparametre, måske ved at begrænse flowet eller ved hjælp af en anden codec .
| Internetprotokol suite |
|---|
| Påføringslag |
| Transportlag |
| Internet-lag |
| Linklag |
Protokolfunktioner
Typisk sendes RTP på en lige UDP- port, hvor RTCP-meddelelser sendes over den næste højere ulige nummerport.
RTCP i sig selv giver ingen flowkryptering eller godkendelsesmetoder. Sådanne mekanismer kan f.eks. Implementeres med Secure Real-time Transport Protocol (SRTP) defineret i RFC 3711.
RTCP leverer basale funktioner, der forventes implementeret i alle RTP-sessioner:
- Den primære funktion af RTCP er at indsamle statistikker om kvalitetsaspekter af mediedistributionen under en session og overføre disse data til sessionens mediekilde og andre sessionsdeltagere. Sådan information kan bruges af kilden til adaptiv mediekodning ( codec ) og påvisning af transmissionsfejl. Hvis sessionen bæres over et multicast-netværk, tillader dette ikke-påtrængende overvågning af sessionskvalitet.
- RTCP leverer kanoniske slutpunktsidentifikatorer (CNAME) til alle sessionsdeltagere. Selvom en kildeidentifikator (SSRC) af en RTP-strøm forventes at være unik, kan den øjeblikkelige binding af kildeidentifikatorer til slutpunkter ændre sig under en session. CNAME opretter unik identifikation af slutpunkter på tværs af en applikationsinstans (multipel brug af medieværktøjer) og til tredjepartsovervågning.
- Tilvejebringelse af sessionskontrolfunktioner. RTCP er et praktisk middel til at nå ud til alle sessionsdeltagere, mens RTP i sig selv ikke er det. RTP transmitteres kun af en mediekilde.
RTCP-rapporter forventes at blive sendt af alle deltagere, selv i en multicast-session, der kan involvere tusindvis af modtagere. Sådan trafik vil stige proportionalt med antallet af deltagere. For at undgå overbelastning i netværket skal protokollen således omfatte styring af sessionens båndbredde. Dette opnås ved dynamisk at kontrollere frekvensen af rapportoverførsler. RTCP-båndbreddebrug bør generelt ikke overstige 5% af den samlede sessionsbåndbredde. Desuden skal 25% af RTCP-båndbredden altid være forbeholdt mediekilder, så nye deltagere på store konferencer kan modtage afsendernes CNAME-identifikatorer uden overdreven forsinkelse.
RTCP-rapporteringsintervallet er randomiseret for at forhindre utilsigtet synkronisering af rapporteringen. Det anbefalede minimum RTCP-rapportinterval pr. Station er 5 sekunder. Stationer bør ikke sende RTCP-rapporter oftere end en gang hvert 5. sekund.
Pakkeoverskrift
| Forskydninger | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | Version | P | RC | PT | længde | ||||||||||||||||||||||||||||
| 32 | SSRC-id | ||||||||||||||||||||||||||||||||
- Version : (2 bit) Identificerer versionen af RTP, som er den samme i RTCP-pakker som i RTP-datapakker. Den version, der er defineret i denne specifikation, er to (2).
- P (polstring) : (1 bit) Angiver, om der er ekstra polstringsbyte i slutningen af RTP-pakken. Polstring kan bruges til at udfylde en blok af en bestemt størrelse, for eksempel som krævet af en krypteringsalgoritme. Den sidste byte af polstringen indeholder antallet af polstringsbyte, der blev tilføjet (inklusive sig selv).
- RC (Antal modtagelsesrapporter) : (5 bit) Antallet af modtagelsesrapportblokke indeholdt i denne pakke. En værdi på nul er gyldig.
- PT (Pakketype) : (8 bit) Indeholder en konstant til identifikation af RTCP-pakketype.
- Længde : (16 bit) Angiver længden af denne RTCP-pakke (inklusive selve headeren) i 32-bit enheder minus en.
- SSRC : (32 bits) Synkroniseringskilde-id identificerer entydigt kilden til en stream.
Bemærk, at flere rapporter kan sammenkædes til en enkelt sammensat RTCP-pakke, hver med sin egen pakkeoverskrift.
Beskedstyper
RTCP skelner mellem flere typer pakker: afsenderrapport , modtagerrapport , kildebeskrivelse og farvel . Derudover er protokollen udvidelig og tillader applikationsspecifikke RTCP-pakker. En standardbaseret udvidelse af RTCP er den udvidede rapportpakketype introduceret af RFC 3611.
- Afsenderrapport (SR)
- Afsenderrapporten sendes periodisk af de aktive afsendere i en konference for at rapportere transmissions- og modtagelsesstatistikker for alle RTP-pakker, der sendes i intervallet. Afsenderrapporten inkluderer to forskellige tidsstempler, et absolut tidsstempel, der er repræsenteret ved hjælp af tidsstempelformatet for Network Time Protocol (NTP) (som er i sekunder i forhold til midnat UTC den 1. januar 1900) og et RTP-tidsstempel, der svarer til samme tid som NTP-tidsstemplet, men i de samme enheder og med samme tilfældige forskydning som RTP-tidsstemplerne i datapakker beskrevet i denne afsenderrapport. Det absolutte tidsstempel giver modtageren mulighed for at synkronisere RTP-meddelelser. Det er især vigtigt, når både lyd og video transmitteres samtidigt, fordi lyd- og videostreams bruger uafhængige relative tidsstempler.
- Modtagerrapport (RR)
- Modtagerrapporten er for passive deltagere, dem der ikke sender RTP-pakker. Rapporten informerer afsenderen og andre modtagere om servicekvaliteten.
- Kildebeskrivelse (SDES)
- Kildebeskrivelsesmeddelelsen bruges til at sende CNAME-elementet til sessionsdeltagere. Det kan også bruges til at give yderligere information såsom navn, e-mail-adresse, telefonnummer og adresse på kildens ejer eller controller.
- Farvel (BYE)
- En kilde sender en BYE-besked for at lukke en stream. Det giver et slutpunkt mulighed for at meddele, at det forlader konferencen. Selvom andre kilder kan registrere fraværet af en kilde, er denne meddelelse en direkte meddelelse. Det er også nyttigt for en mediemixer.
- Applikationsspecifik meddelelse (APP)
- Den applikationsspecifikke meddelelse giver en mekanisme til at designe applikationsspecifikke udvidelser til RTCP-protokollen.
Skalerbarhed i store implementeringer
I store applikationer, såsom i Internet Protocol Television (IPTV), kan der forekomme meget lange forsinkelser (minutter til timer) mellem RTCP-rapporter på grund af RTCP-båndbreddekontrolmekanismen, der kræves for at kontrollere overbelastning (se protokolfunktioner ). Acceptable frekvenser er normalt mindre end en pr. Minut. Dette giver potentialet for uhensigtsmæssig rapportering af de relevante statistikker fra modtageren eller får mediasenderen til at være unøjagtig i forhold til sessionens aktuelle tilstand. Der er indført metoder til at afhjælpe problemerne: RTCP-filtrering, RTCP-forspænding og hierarkisk aggregering .
Hierarkisk sammenlægning
Den hierarkiske aggregering (eller også kendt som RTCP-feedbackhierarki) er en optimering af RTCP-feedbackmodellen, og dens mål er at flytte det maksimale antal brugergrænser yderligere sammen med QoS-måling ( Quality of Service ). Den RTCP båndbredde er konstant og tager kun 5% af sessionen båndbredde. Derfor afhænger rapporteringsintervallet om QoS blandt andet af et antal sessionmedlemmer, og for meget store sessioner kan det blive meget højt (minutter eller endda timer). Det acceptable interval er dog ca. 10 sekunders rapportering. Større værdier vil medføre tidsforskudt og meget unøjagtig rapporteret status om den aktuelle sessionsstatus, og enhver optimering foretaget af afsenderen kan endda have en negativ effekt på netværks- eller QoS-forhold.
Den hierarkiske aggregering bruges med kildespecifik multicast, hvor kun en enkelt kilde er tilladt, dvs. IPTV . En anden type multicast kan være Any-Source Multicast, men det er ikke så velegnet til store applikationer med et stort antal brugere.
Fra juni 2007 bruger kun de mest moderne IPTV-systemer hierarkisk aggregering.
Feedback-mål
Feedback Target er en ny type medlem, der først blev introduceret af Internet Draft draft-ietf-avt-rtcpssm-13. Den hierarkiske aggregeringsmetode har udvidet dens funktionalitet. Dette medlems funktion er at modtage modtagerrapporter (RR) (se RTCP ) og videresende opsummerede RR-pakker, såkaldt modtageroversigtsinformation (RSI) til en afsender (i tilfælde af hierarki på et niveau).
Standarddokumenter
Se også
Bemærkninger
Referencer
Yderligere læsning
- Perkins, Colin (2003). RTP . Addison-Wesley. s. 414. ISBN 978-0-672-32249-5.
- Peterson, Larry L .; Bruce S. Davie (2007). Computernetværk (4 udgaver). Morgan Kaufmann. s. 806. ISBN 978-0-12-374013-7.
- "RTCP" . Netværksprotokoller-håndbog . Javvin Technologies. 2005. ISBN 978-0-9740945-2-6.
