När vi, pratar i en IP-telefon, hör samtalspartnerns röst i mottagaren, eller, med hjälp av ett videokonferenssystem, kommunicerar med våra kollegor och släktingar, utbyter vi en kontinuerlig ström av data. När du överför strömmande data som röst och video över ett paketnätverk är det mycket viktigt att använda mekanismer som skulle lösa följande uppgifter:
För dessa ändamål utvecklades den RTP(Real-time Transport Protocol) är ett realtidsöverföringsprotokoll, som kommer att diskuteras i dagens artikel. Protokollet utvecklades av IETF av Audio-Video Transport Working Group och beskrivs i RFC 3550.
Som regel fungerar RTP ovanpå UDP (User Datagram Protocol), för vid överföring av multimediadata är det mycket viktigt att säkerställa att de levereras i tid.
RTP inkluderar möjligheten att bestämma typen av nyttolast och tilldela ett sekvensnummer för paketet i strömmen, samt användning av tidsstämplar.
På den sändande sidan är varje paket märkt med en tidsstämpel, den mottagande sidan tar emot den och bestämmer den totala fördröjningen, varefter skillnaden i totala fördröjningar beräknas och jitter bestäms. Således blir det möjligt att ställa in en konstant fördröjning i leveransen av paket och därigenom minska effekten av jitter.
En annan funktion hos RTP är associerad med eventuell paketförlust när den passerar genom IP-nätverket, vilket uttrycks i uppkomsten av korta pauser i konversationen. Plötslig tystnad i luren har som regel en mycket negativ effekt på lyssnaren, därför, med funktionerna i RTP-protokollet, fylls sådana perioder av tystnad med så kallat "komfortbrus"
RTP fungerar tillsammans med ett annat IETF-protokoll, nämligen RTCP (Real-time Transport Control Protocol), som beskrivs i RFC 3550. RTCP är utformat för att samla in statistisk information, bestämma kvaliteten på tjänstens QoS (Quality of Service), och även för att synkronisera mellan mediaströmmar i RTP-sessionen.
Huvudfunktionen för RTCP är att skapa feedback med applikationen för att rapportera om kvaliteten på den mottagna informationen. Deltagare i en RTCP-session utbyter information om antalet mottagna och förlorade paket, jittervärde, fördröjning, etc. Baserat på analysen av denna information fattas ett beslut om att ändra överföringsparametrarna, till exempel för att minska komprimeringsförhållandet för information för att förbättra kvaliteten på dess överföring.
För att utföra dessa funktioner skickar RTCP speciella meddelanden av vissa typer:
RTP är ett enkelriktat protokoll, så tvåvägskommunikation kräver två RTP-sessioner, en på varje sida.
En RTP-session definieras av deltagarnas IP-adresser, såväl som ett par oreserverade UDP-portar från intervallet 16384 - 32767. Dessutom, för att organisera feedback med applikationen, är det också nödvändigt att upprätta en två- sätt RTCP-session. För RTCP-sessioner är portar med ett nummer ett högre än RTP upptagna. Så till exempel, om port 19554 väljs för RTP, kommer RTCP-sessionen att ta port 19555. Visuellt visas bildandet av en RTP/RTCP-session i figuren nedan.
Det här avsnittet diskuterar några aspekter av transporten av RTP-paket med nätverk och transportprotokoll. Om inte annat anges i specifikationerna för andra protokoll, gäller följande grundläggande regler vid överföring av paket.
RTP förlitar sig på lägre lagerprotokoll för att tillhandahålla separation av RTP-dataströmmar och RTCP-kontrollinformation. För UDP och liknande protokoll använder RTP ett jämnt portnummer, och motsvarande RTCP-ström använder ett portnummer som är större än ett.
RTP-informationspaket innehåller inte något längdfält, därför förlitar sig RTP på det underliggande protokollet för att också ge en längdindikation. Den maximala längden på RTP-paket begränsas endast av lägre lagerprotokoll.
Flera RTP-protokollpaket kan sändas i en protokolldataenhet i ett lägre lager, till exempel i ett UDP-paket. Detta minskar header-redundans och kan förenkla synkronisering mellan olika strömmar.
Det här avsnittet innehåller en lista över konstanter som definieras i RTP-protokollspecifikationen.
RTP (PT - nyttolasttyp) trafiktypkonstanter definieras i profiler. RTP-rubrikoktetten, som innehåller markörbitarna och trafiktypfältet, får dock inte innehålla de reserverade värdena 200 och 201 (decimal) för att skilja RTP-paket från RTCP SR- och RR-paket. För ett standardformat med en markörbit och ett sjubitars trafiktypfält innebär denna begränsning att trafiktyperna 72 och 73 inte ska användas.
Värden för RTCP-pakettyper (se tabell 1) väljs i intervallet från 200 till 204 för att bättre kontrollera korrektheten av RTCP-pakethuvudet jämfört med RTP-paket. När RTCP-pakettypfältet jämförs med motsvarande oktett i RTP-huvudet, motsvarar detta intervall en markörbit av ett (vilket normalt inte är fallet i informationspaket) och den mest signifikanta biten i standardtrafiktypfältet för ett (medan statiskt definierade trafiktyper vanligtvis har PT-värden med en nolla i den mest signifikanta siffran). Detta intervall valdes också för att vara mer avlägset från värdena 0 och 255, eftersom fält som helt består av nollor eller ettor är mestadels karakteristiska för data.
Andra typer av RTCP-paket definieras av IANA-gemenskapen. Utvecklare har möjlighet att registrera de värden de behöver för experimentell forskning och sedan avregistrera sig när behovet av dessa värden inte längre behövs.
Giltiga typer av artiklar i SDES-paketet presenteras i tabell. 2. Andra SDES-objekttyper tilldelas av IANA-gemenskapen. Utvecklare har möjlighet att registrera de värden de behöver när de utför experimentella studier och sedan avregistrera dem när dessa värden inte längre behövs.
Som noterats ovan (se avsnitt 2), för fullständig beskrivning RTP-protokoll för en specifik applikation kräver ytterligare dokument av två typer: profilbeskrivning och trafikformat.
RTP kan användas för många klasser av applikationer med vitt skilda krav. Flexibilitet för att anpassa sig till dessa krav säkerställs genom att använda olika profiler (se ). Vanligtvis använder en applikation bara en profil och ingen explicit indikation på vilken profil som finns i det här ögonblicket i bruk, nej.
Ett valfritt dokument av den andra typen, trafikformatspecifikationen, definierar hur en viss typ av trafik (t.ex. H.261-kodad video) ska överföras enligt RTP. Samma trafikformat kan användas för flera profiler och kan därför definieras oberoende av profilen. Profildokument ansvarar endast för att detta format matchas med PT-värdet .
Profilbeskrivningen kan definiera följande poster, men denna lista är inte uttömmande.
Rubrik för RTP-datapaketet. Oktetten i rubriken på RTP-datapaketet, som innehåller tokenbiten och trafiktypfältet, kan omdefinieras enligt profilen för att uppfylla olika krav, till exempel för att tillhandahålla fler eller färre tokenbitar (avsnitt 3.3).
trafiktyper. En profil definierar vanligtvis en uppsättning trafikformat (t.ex. mediakodningsalgoritmer) och en standard statisk mappning av dessa format och PT-värden. Vissa av trafikformaten kan definieras med hänvisning till individuella trafikformatbeskrivningar. För varje definierad typ av trafik måste profilen ange den klockfrekvens som krävs för RTP-tidsstämpeln som ska användas (avsnitt 3.1).
RTP-datapakethuvudtillägg. Om några ytterligare funktionalitet inom en profilapplikationsklass som inte beror på typen av trafik, kan ytterligare fält bifogas till den fasta rubriken för RTP-datapaketet .
RTP-datapakethuvudförlängningar. Innehållet i de första 16 bitarna av RTP Data Packet Header Extension-strukturen ska specificeras om användningen av denna mekanism tillåts av profilen. .
Typer av RTCP-paket. Nya, applikationsklassspecifika typer av RTCP-paket kan definieras (och registreras hos IANA).
RTCP-rapporteringsintervall. Profilen måste definiera de värden som används för att beräkna RTCP-rapporteringsintervallet: RTCP-sessionens bandbreddsfraktion, minsta rapporteringsintervall och bandbreddsdelningen mellan sändare och mottagare.
SR/RR-paketförlängning. Om tillgänglig ytterligare information om en sändare eller mottagare som ska sändas regelbundet kan en förlängningssektion definieras för RTCP SR- och RR-paket.
Använder SDES. Profilen kan definiera relativa prioriteringar för RTCP SDES-objekt som ska sändas eller uteslutas (se avsnitt 4.2.2); alternativ syntax eller semantik för en CNAME-sats (avsnitt 4.4.1); LOC-objektformat (avsnitt 4.4.5); semantiken och användningen av NOTE-satsen (avsnitt 4.4.7) och de nya SDES-klausulerna som ska registreras hos IANA.
Säkerhet. En profil kan definiera vilka säkerhetstjänster och algoritmer som applikationer ska använda och kan ge kontroll över deras användning (klausul 7).
Lösenordsnyckelmatchning. Profilen kan bestämma hur lösenordet som angetts av användaren omvandlas till en krypteringsnyckel.
Det underliggande protokollet. Överföringen av RTP-paket kan kräva användning av ett särskilt underliggande nätverk eller transportlagerprotokoll.
Transportöverensstämmelse. Annat än standardmappningen av RTP och RTCP till transportlageradresser som anges i avsnitt 8, såsom UDP-portar, kan definieras.
Inkapsling. RTP-paketformning kan definieras för att tillåta att flera RTP-informationspaket överförs i en enda underliggande protokolldataenhet (avsnitt 8).
Varje applikation du utvecklar bör inte kräva en ny profil. Det är mer ändamålsenligt att utöka en befintlig profil inom samma klass av applikationer, snarare än att skapa en ny. Detta kommer att göra det lättare för applikationer att interagera, eftersom varje applikation vanligtvis körs under endast en profil. Enkla tillägg, som att definiera ytterligare PT-värden eller RTCP-pakettyper, kan göras genom att registrera dem hos IANA och publicera deras beskrivningar i en profilspecifikation eller trafikformatspecifikation.
RFC 1890 beskriver en profil för användning av realtidstransportprotokollet RTP version 2 och dess tillhörande RTCP-kontrollprotokoll inom en gruppljud- eller videokonferens, den så kallade RTP-profilen för ljud- och videokonferenser (RTP-profil för ljud- och videokonferenser) med minimal kontroll). Den här profilen definierar aspekter av RTP som inte specificeras i RTP-protokollets version 2-specifikation (RFC 1889). Minimikontroll innebär att inget stöd för parameterförhandling eller medlemskontroll krävs (t.ex. vid användning av statiska trafiktyper och medlemsindikeringar från RTCP). Överväg de viktigaste bestämmelserna denna profil.
Det här avsnittet innehåller en beskrivning av ett antal objekt som kan definieras eller ändras i en profil.
Rubriken för RTP-informationspaketet. Standardformatet för fast rubrik för RTP-informationspaket (en bit markör) används.
trafiktyper. Statiska värden för trafiktyper definieras i avsnitt 11.3 och 11.4.
RTP Information Packet Header Extensions. Inga ytterligare fasta fält är bifogade till RTP-informationspakethuvuden.
RTP Information Packet Header Extensions. Inga RTP-informationspakethuvudtillägg är definierade, men applikationer som använder den här profilen KAN använda sådana tillägg. Det vill säga, applikationer bör inte anta att X-biten i RTP-huvudet alltid är noll. Applikationer måste vara beredda att ignorera rubrikexpansion. Om en rubriktillägg definieras i framtiden måste innehållet i de första 16 bitarna specificeras så att många olika tillägg kan identifieras.
Typer av RTCP-paket. Inga ytterligare RTCP-pakettyper är definierade i denna profilspecifikation.
RTCP-rapporteringsintervall. Vid beräkning av RTCP-rapporteringsintervallet ska de konstanter som föreslås i RFC 1889 användas.
SR/RR-pakettillägg. Tillägg för RTCP SR- och RR-paket är inte definierade.
Använder SDES. Applikationer kan använda vilken som helst av de beskrivna SDES-klausulerna. Medan informationen om det kanoniska namnet (CNAME) skickas i varje rapporteringsintervall, behöver de andra posterna bara skickas vart femte rapporteringsintervall.
Säkerhet. Standard-RTP-säkerhetstjänsterna är också definierade som standard med denna profil.
Lösenordsnyckelmatchning. Lösenordet som angetts av användaren konverteras med hjälp av MD5-algoritmen till en sammanfattning på 16 oktett. En N-bitars nyckel erhålls från sammandraget genom att använda dess första N bitar. Lösenordet är avsett att endast innehålla ASCII-bokstäver, siffror, bindestreck och mellanslag för att minska risken för korruption vid överföring av lösenord via telefon, fax, telex eller e-post. Lösenordet kan föregås av en. Alla tecken upp till det första snedstrecket framåt (ASCII-kod 0x2f) tas som namnet på krypteringsalgoritmen. Om det inte finns något snedstreck är standardkrypteringsalgoritmen DES-CBC.
Lösenordet som angetts av användaren konverteras till dess kanoniska form innan stängningsalgoritmen tillämpas. För att göra detta konverteras lösenordet till ISO 10646-teckenuppsättningen med UTF-8-kodning enligt definition i bilaga P till ISO/IEC 10646-1:1993 (ASCII-tecken kräver ingen konvertering); mellanslag tas bort i början och slutet av lösenordet; två eller flera mellanslag ersätts med ett mellanslag (ASCII eller UTF-8 0x20); alla bokstäver konverteras till små bokstäver
det underliggande protokollet. Profilen definierar användningen av RTP över UDP i dubbelriktat och multicast-läge.
Transportöverensstämmelse. Standardmappningen av RTP och RTCP för att transportera lageradresser används.
Inkapsling. Inkapsling av RTP-paket är inte definierad.
Den här profilen definierar standardkodningstyperna som används med RTP. Andra kodningstyper måste registreras hos IANA före användning. Vid registrering av en ny kodningstyp måste följande information lämnas:
För applikationer som inte skickar paket under pauser, särskiljs den första skuren av aktivt tal (det första paketet efter pausen) genom att sätta markörbiten i rubriken på RTP-informationspaketet till ett. Applikationer utan tystnadsundertryckning ställer in denna bit på noll.
RTP-klockan som används när RTP-tidsstämpeln genereras är oberoende av antalet kanaler och kodningstyp; det är lika med antalet samplingsperioder per sekund. För N-kanalskodning (stereo, quad, etc.) genererar varje samplingsperiod (säg 1/8000 sekund) N sampel. Det totala antalet sampel som genereras per sekund är lika med produkten av samplingshastigheten och antalet kanaler.
När du använder flera ljudkanaler numreras de från vänster till höger, med början på den första. I RTP-ljudpaket föregår data från lägre numrerade kanaler data från högre numrerade kanaler. För mer än två kanaler används följande notation:
| Antal kanaler | Systemnamn | Kanalnummer | |||||
|---|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | ||
| 2 | stereo | l | r | ||||
| 3 | l | r | c | ||||
| 4 | fyrhjuling | fl | Fr | Rl | Rr | ||
| 4 | l | c | r | S | |||
| 5 | fl | Fr | Fc | Sl | Sr | ||
| 6 | l | lc | c | r | rc | S | |
Samplen för alla kanaler som tillhör samma samplingsmoment måste vara inom samma paket. Interfolieringen av sampel från olika kanaler beror på typen av kodning.
Samplingsfrekvensen bör väljas från uppsättningen: 8000, 11025, 16000, 22050, 24000, 32000, 44100 och 48000 Hz (datorer Macintosh Apple har sina egna samplingsfrekvenser 22254,0 som kan omvandlas till 22254,027 och 7124. 11025 s acceptabel kvalitet genom att hoppa över fyra eller två sampel i en 20-ms ram). De flesta ljudkodningsalgoritmer är dock definierade för en mer begränsad uppsättning samplingshastigheter. Mottagare måste vara förberedda för att ta emot flerkanaligt ljud, men kan också välja mono.
För ljudpaketering ska standardpaketeringsintervallet vara 20 ms om inte annat anges i kodningsbeskrivningen. Paketiseringsintervallet definierar minsta ände-till-ände fördröjning. Längre paket har en relativt mindre andel byte för rubriken, men de orsakar mer fördröjning och gör paketförlusten mer betydande. För icke-interaktiva applikationer som föreläsningar eller kanaler med betydande bandbreddsbegränsningar kan en högre paketeringsfördröjning vara acceptabel. Mottagaren måste ta emot paket med en ljudsignal med en fördröjning på 0 till 200 ms. Denna gräns säkerställer en acceptabel buffertstorlek för mottagaren.
I sampelbaserade kodningar representeras varje signalsampel av ett fast antal bitar. Inom komprimerad ljuddata kan individuella provkoder passera oktettgränser. Längden på signalen som sänds i ljudpaketet bestäms av antalet sampel i paketet.
För sampelbaserade kodningstyper som producerar en eller flera oktetter per sampel, packas sampel från olika kanaler som samplades samtidigt i intilliggande oktetter. Till exempel, för stereokodning, är sekvensen av oktetter: vänster kanal, första sampel; höger kanal, första räkning; vänster kanal, andra räkning; höger kanal, andra prov osv. Vid multioktettkodning sänds den mest signifikanta oktetten först. Packningen av sampelbaserade kodningar som producerar mindre än en oktett per sampel bestäms av kodningsalgoritmen.
Den rambaserade kodningsalgoritmen omvandlar ett ljudblock med fast längd till ett annat komprimerat datablock, vanligtvis också med en fast längd. För rambaserade kodningar kan avsändaren kombinera flera sådana ramar till ett enda meddelande.
För rambaserade codecs definieras kanalordningen för hela blocket. Det vill säga, för stereoljud, kodas samplen för vänster och höger kanal oberoende av varandra; varvid kodningsramen för den vänstra kanalen föregår ramen för den högra kanalen.
Alla ramorienterade ljudkodekar måste kunna koda och avkoda flera på varandra följande ramar som sänds inom ett enda paket. Eftersom ramstorleken för ramorienterade codecs är specificerad, finns det inget behov av att använda en separat notation för samma kodning men med ett annat antal ramar per paket.
I tabell. 3 visar värdena för trafiktyper (PT) definierade av denna profil för ljudsignaler, deras konventioner och huvud specifikationer kodningsalgoritmer.
I tabell. 4 visar värdena för kodningstyper (PT), symboler för kodningsalgoritmer och tekniska egenskaper för videokodningsalgoritmer definierade av denna profil, såväl som otilldelade, reserverade och dynamiskt tilldelade PT-värden.
Trafiktypsvärden i intervallet 96 till 127 kan bestämmas dynamiskt genom konferenskontrollprotokollet, vilket inte tas upp i den här artikeln. Till exempel kan sessionskatalogen specificera att, för en given session, trafiktyp 96 betecknar PCMU-kodning, dubbelkanal vid 8000 Hz. Området för trafiktyp som är markerat med "reserverad" används inte så att RTCP- och RTP-protokollpaket kan särskiljas på ett tillförlitligt sätt .
En RTP-källa sänder bara ut en typ av trafik vid varje given tidpunkt; interleaving av olika typer av trafik i en RTP-session är inte tillåten. Flera RTP-sessioner kan användas parallellt för att transportera olika typer av trafik. Trafiktyperna som definieras i den här profilen hänvisar till antingen ljud eller video, men inte båda. Det är dock möjligt att definiera kombinerade trafiktyper som kombinerar till exempel ljud och bild, med lämplig separation i trafikformatet.
Ljudapplikationer som använder den här profilen måste som minimum kunna skicka och ta emot trafiktyperna 0 (PCMU) och 5 (DVI4). Detta möjliggör interoperabilitet utan formatförhandling.
Som definieras i RTP-protokollbeskrivningen måste RTP-data överföras på en jämnt nummererad UDP-port och motsvarande RTCP-paket måste överföras på ett portnummer som är större än ett (udda nummer).
Program som körs med den här profilen kan använda vilket par av UDP-portar som helst. Till exempel kan ett par portar tilldelas slumpmässigt av sessionshanteringsprogrammet. Ett enda fast par av portnummer kan inte anges eftersom i vissa fall måste flera applikationer som använder den här profilen köras korrekt på samma värd, och vissa operativsystem tillåter inte att flera processer använder samma UDP-port med olika multicast-adresser.
Standardportnumren kan dock vara 5004 och 5005. Program som använder flera profiler kan välja detta portpar som indikator för den profilen. Men applikationer kan också kräva att portparet anges uttryckligen.
En av de viktigaste trenderna i utvecklingen av modern telekommunikation är utvecklingen av IP-telefoni - en uppsättning nya teknologier som säkerställer överföring av multimediameddelanden (röst, data, video) genom informations- och datornätverk (ICN) byggda på grunden för IP-protokollet (Internet Protocol), inklusive lokala, företags, globala datornätverk och Internet. Begreppet IP-telefoni inkluderar Internettelefoni, som gör det möjligt att organisera telefonkommunikation mellan Internet-abonnenter, mellan abonnenter telefonnät allmän användning (PSTN) över Internet, samt telefonkommunikation mellan PSTN och Internet-abonnenter med varandra.
IP-telefoni har ett antal obestridliga fördelar som säkerställer dess snabba utveckling och expansion av datortelefonimarknaden. Det är fördelaktigt för slutanvändare som förses med telefonkommunikation till en ganska låg minutbetalning. För företag med fjärranslutna filialer låter IP-tekniken dig organisera röstkommunikation med hjälp av befintliga företags IP-nätverk. Istället för flera kommunikationsnät används ett. Den otvivelaktiga fördelen med IP-telefoni jämfört med en vanlig telefon är också möjligheten att tillhandahålla ytterligare tjänster genom användning av en multimediadator och olika Internetapplikationer. Med IP-telefoni kan alltså företag och privatpersoner utöka sina kommunikationsmöjligheter genom att införliva avancerade videokonferenser, applikationsdelning, verktyg av typen whiteboard med mera.
Vilka internationella standarder och protokoll reglerar de viktigaste parametrarna och algoritmerna för driften av hårdvaru- och mjukvarukommunikation som används i IP-telefoni? Uppenbarligen, som namnet antyder, är denna teknik baserad på IP-protokollet, som dock inte bara används för telefoni: det utvecklades ursprungligen för att överföra digital data till paketkopplad IVS.
I nätverk som inte tillhandahåller en garanterad tjänstekvalitet (dessa inkluderar nätverk byggda på basis av IP-protokollet), kan paket gå förlorade, ordningen för deras ankomst kan ändras, data som överförs i paket kan förvrängas. Olika transportlagerprocedurer används för att säkerställa tillförlitlig leverans av överförd information under dessa förhållanden. Vid överföring av digital data används TCP-protokollet (Transmission Control Protocol) för detta ändamål. Detta protokoll ger tillförlitlig dataleverans och återställer den ursprungliga paketordningen. Om ett fel upptäcks i ett paket eller om paketet går förlorat, skickar TCP-procedurerna en begäran om återsändning.
För ljud- och videokonferensapplikationer har paketfördröjningar en mycket större effekt på signalkvaliteten än enskilda dataförvrängningar. Skillnader i förseningar kan leda till luckor. Sådana applikationer kräver ett annat transportlagerprotokoll som ger paketåtersekvensering, leverans med minimal fördröjning, realtidsuppspelning vid exakt specificerade ögonblick, trafiktypigenkänning, multicast eller tvåvägskommunikation. Ett sådant protokoll är realtidstransportprotokollet RTP (Real-Time Transport Protocol). Detta protokoll reglerar överföringen av multimediadata i paket genom IVS på transportnivå och kompletteras av realtidsdataöverföringskontrollprotokollet RTCP (Real-Time Control Protocol). RTCP-protokollet ger i sin tur kontroll över leveransen av multimediadata, kontroll av tjänstens kvalitet, överföring av information om deltagarna i den aktuella kommunikationssessionen, kontroll och identifiering, och anses ibland vara en del av RTP-protokollet.
Många publikationer om IP-telefoni notera att de flesta av nätverksutrustning och speciella programvara för denna teknik är utvecklad på grundval av rekommendation H.323 från Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) (inklusive TAPI 3.0, NetMeeting 2.0, etc.). Hur relaterar H.323 till RTP och RTCP? H.323 är ett brett konceptuellt ramverk som inkluderar många andra standarder, som var och en behandlar olika aspekter av informationsöverföring. De flesta av dessa standarder, såsom ljud- och videocodec-standarder, har bred tillämpning inte bara inom IP-telefoni. När det gäller RTP / RTCP-protokollen, de utgör grunden för H.323-standarden, är fokuserade på att tillhandahålla exakt IP-teknik och ligger till grund för organisationen av IP-telefoni. Den här artikeln ägnas åt övervägandet av dessa protokoll.
RTP-transportprotokollet i realtid tillhandahåller realtidsöverföring från slut till ände av multimediadata som interaktivt ljud och video. Detta protokoll implementerar trafiktypigenkänning, paketsekvensnumrering, arbete med tidsstämplar och transmissionskontroll.
RTP-protokollets åtgärd reduceras till att tilldela varje utgående paket en tidsstämpel. På mottagningssidan anger pakettidsstämplar i vilken sekvens och med vilka fördröjningar de behöver spelas upp. Stöd för RTP och RTCP gör att den mottagande värden kan ordna de mottagna paketen i rätt ordning, minska effekten av paketfördröjningsjitter på nätverket på signalkvaliteten och återställa synkroniseringen mellan ljud och bild så att inkommande information kan höras och ses korrekt. av användare.
Observera att RTP själv inte har någon mekanism för att garantera snabb dataöverföring och tjänstens kvalitet, utan använder underliggande tjänster för att säkerställa detta. Det förhindrar inte paket som inte fungerar, men det förutsätter inte att det underliggande nätverket är absolut tillförlitligt och sänder paket i rätt ordning. Sekvensnumren som ingår i RTP gör att mottagaren kan sekvensera om avsändarens paket.
RTP-protokoll stöder både dubbelriktad kommunikation och dataöverföring till en grupp av destinationer om multicast stöds av det underliggande nätverket. RTP är utformad för att tillhandahålla den information som krävs individuella ansökningar, och i de flesta fall integrerad i applikationen.
Även om RTP anses vara ett transportlagerprotokoll, fungerar det vanligtvis ovanpå ett annat transportlagerprotokoll, UDP (User Datagram Protocol). Båda protokollen bidrar till transportlagrets funktionalitet. Det bör noteras att RTP och RTCP är oberoende av de underliggande transport- och nätverkslagren, så RTP/RTCP-protokollen kan användas med andra lämpliga transportprotokoll.
RTP/RTCP-protokolldataenheter kallas paket. Paket som genereras i enlighet med RTP-protokollet och som används för att överföra multimediadata kallas informationspaket eller datapaket (datapaket), och paket som genereras i enlighet med RTCP-protokollet och används för att överföra tjänstinformation som krävs för tillförlitlig drift av en telekonferens är kallas paket, kontroll- eller tjänstepaket (kontrollpaket). Ett RTP-paket inkluderar en fast rubrik, en valfri rubrikförlängning med variabel längd och ett datafält. Ett RTCP-paket börjar med en fast del (liknande den fasta delen av RTP-informationspaket) följt av byggblock med variabel längd.
För att RTP-protokollet ska vara mer flexibelt och applicerbart på olika applikationer är några av dess parametrar avsiktligt odefinierade, men det inkluderar konceptet med en profil. Profil (profil) är en uppsättning parametrar för RTP- och RTCP-protokoll för en specifik klass av applikationer, som bestämmer funktionerna i deras funktion. Profilen definierar användningen av individuella paketrubrikfält, trafiktyper, rubriktillägg och rubriktillägg, pakettyper, kommunikationssäkerhetstjänster och algoritmer, funktioner för användningen av det underliggande protokollet, etc. RTP-profil för ljud- och videokonferenser med minimal kontroll ). Varje applikation fungerar vanligtvis med endast en profil, och inställning av profiltyp görs genom att välja lämplig applikation. Ingen explicit indikation av profiltyp genom portnummer, protokollidentifierare, etc. tillhandahålls inte.
Således måste en fullständig RTP-specifikation för en viss applikation innehålla ytterligare dokument, som inkluderar en profilbeskrivning, samt en trafikformatbeskrivning som definierar hur en viss typ av trafik, såsom ljud eller video, kommer att behandlas i RTP.
Funktioner för multimediadataöverföring under ljud- och videokonferenser diskuteras i följande avsnitt.
Gruppljudkonferenser kräver en gruppadress för flera användare och två portar. I detta fall krävs en port för utbyte av ljuddata, och den andra används för kontrollpaket av RTCP-protokollet. Gruppadress och portinformation skickas till de avsedda telekonferensdeltagarna. Om integritet krävs kan informationen och kontrollpaketen krypteras enligt definitionen i avsnitt 7.1, i vilket fall krypteringsnyckeln också måste genereras och distribueras.
Ljudkonferensapplikationen som används av varje konferensdeltagare skickar ljuddata i små skurar, till exempel 20 ms. Varje del av ljuddata föregås av en RTP-rubrik; RTP-huvudet och data är i sin tur bildade (inkapslade) till ett UDP-paket. RTP-huvudet indikerar vilken typ av ljudkodning (t.ex. PCM, ADPCM eller LPC) som användes för att bilda data i paketet. Detta gör det möjligt att ändra kodningstyp under konferensen, till exempel när en ny deltagare anländer som använder en anslutning med låg bandbredd, eller under nätverksöverbelastning.
På Internet, liksom i andra paketkopplade datanätverk, går paket ibland förlorade och ordnas om, och försenas även flera gånger. För att motverka dessa händelser innehåller RTP-huvudet en tidsstämpel och ett sekvensnummer som gör att mottagare kan tidsinställa så att till exempel delar av en ljudsignal spelas upp kontinuerligt av högtalaren var 20:e ms. Denna tidsrekonstruktion utförs separat och oberoende för varje källa för RTP-paket i telekonferensen. Sekvensnumret kan också användas av mottagaren för att uppskatta antalet förlorade paket.
Eftersom deltagare i en telefonkonferens kan gå med och lämna under en telefonkonferens, är det användbart att veta vem som för närvarande är med i konferensen och hur bra konferensdeltagarna tar emot ljuddata. För detta ändamål skickar varje instans av ljudapplikationen under konferensen periodiskt ut på kontrollporten (RTCP-porten) för applikationer från alla andra deltagare, paketmottagningsmeddelanden som indikerar deras användarnamn. Mottagningsmeddelandet indikerar hur väl den aktuella högtalaren hörs och kan användas för att styra adaptiva kodare. Förutom användarnamnet kan även annan identifieringsinformation för bandbreddskontroll inkluderas. När du lämnar konferensen skickar webbplatsen ett RTCP BYE-paket.
Om både ljud- och videosignaler används i en telefonkonferens sänds de separat. För överföring av varje typ av trafik, oavsett den andra, introducerar protokollspecifikationen konceptet med en RTP-session (se listan över använda förkortningar och termer). En session definieras av ett specifikt par destinationstransportadresser (en nätverksadress plus ett par portar för RTP och RTCP). Paket för varje typ av trafik sänds med två olika par UDP-portar och/eller multicast-adresser. Det finns ingen direkt RTP-lageranslutning mellan ljud- och videosessioner, förutom att en användare som deltar i båda sessionerna måste använda samma kanoniska namn i RTCP-paketen för båda sessionerna så att sessionerna kan länkas.
En anledning till denna separation är att vissa konferensdeltagare behöver få ta emot endast en typ av trafik om de så önskar. Trots separationen kan synkron uppspelning av källmediedata (ljud och video) uppnås med hjälp av tidsinformationen som bärs i RTCP-paketen för båda sessionerna.
Alla webbplatser har inte alltid möjlighet att ta emot multimediadata i samma format. Tänk på fallet där deltagare från samma ort är anslutna via en låghastighetslänk till majoriteten av andra konferensdeltagare som har bredbandsnätaccess. Istället för att tvinga alla att använda en smalare bandbredd och ljudkodning av lägre kvalitet, kan en RTP-lagerkommunikationsanläggning som kallas mixer placeras i en region med låg bandbredd. Denna mixer synkroniserar om de inkommande ljudpaketen för att återställa de ursprungliga 20ms-intervallen, blandar dessa återställda ljudströmmar till en enda ström, utför ljudkodning med låg bandbredd och sänder paketströmmen över en låghastighetslänk. I detta fall kan paket adresseras till en mottagare eller en grupp av mottagare med olika adresser. För att mottagningsändpunkter ska ge en korrekt indikation av källan för meddelanden, inkluderar RTP-huvudet organ för blandare för att identifiera källorna som är involverade i bildandet av det blandade paketet.
Vissa av deltagarna i ljudkonferensen kan vara anslutna via bredbandskommunikationslinjer, men kanske inte kan nås via en IP-multicast-gruppkonferens (IPM). Till exempel kan de finnas bakom en brandvägg för applikationslager som inte tillåter någon överföring av IP-paket. För sådana fall behövs inte mixers, utan en annan typ av RTP-lagerkommunikation, kallad översättare. Av de två översättarna är en installerad utanför brandväggen och vidarebefordrar externt alla multicast-paket som tas emot via en säker anslutning till den andra översättaren som är installerad bakom brandväggen. Översättaren bakom brandväggen sänder dem igen som multicast-paket till en fleranvändargrupp begränsad till internt nätverk webbplats.
Blandare och översättare kan utformas för ett antal ändamål. Exempel: En videomixer som skalar videobilder av individer i oberoende videoströmmar och sammansätter dem till en enda videoström, som simulerar en gruppscen. Exempel på sändningar: Anslutning av en grupp av IP/UDP-bara värdar till en grupp av ST-II-bara värdar, eller kodning av videopaket för paket från individuella källor utan omtidning eller blandning. Detaljerna om hur mixers och översättare fungerar diskuteras i avsnitt 5.
Alla fält av RTP/RTCP-paket sänds över nätverket i byte (oktetter); den mest signifikanta byten sänds först. All rubrikfältsdata justeras efter dess längd . Oktetter betecknade som valfria har värdet noll.
Absolut tid (väggklocka) i RTP representeras med NTP (Network Time Protocol) tidsstämpelformat, vilket är en nedräkning i sekunder i förhållande till noll timmar den 1 januari 1900. Det fullständiga NTP-tidsstämpelformatet är ett 64-bitars osignerat fastpunktsnummer med en heltalsdel i de första 32 bitarna och en bråkdel i de sista 32 bitarna. I vissa fält med en mer kompakt representation används endast de mellersta 32 bitarna - de låga 16 bitarna av heltalsdelen och de höga 16 bitarna i bråkdelen.
De följande två avsnitten av den här artikeln (3 och 4) diskuterar paketformaten och funktionerna för RTP- respektive RTCP-protokollens funktion.
Som noterats ovan inkluderar ett RTP-paket en fast rubrik, en valfri rubrikförlängning med variabel längd och ett datafält. Den fasta rubriken för RTP-protokollpaket har följande format: .
De första tolv oktetterna finns i varje RTP-paket, medan det bidragande källans CSRC-identifieringsfält (contributing source) endast finns när det infogas av mixern. Fälten har följande syften.
Version (V): 2 bitar. Detta fält identifierar RTP-versionen. Den här artikeln fokuserar på version 2 av RTP-protokollet (värde 1 användes i den första versionen av RTP).
Komplement (P): 1 bit. Om utfyllnadsbiten är satt till ett, så innehåller paketet i slutet en eller flera utfyllnadsoktetter som inte är en del av trafiken. Den sista utfyllnadsoktetten innehåller en indikation på antalet sådana oktetter som senare ska ignoreras. Utfyllnad kan krävas av vissa chifferalgoritmer med fasta blockstorlekar eller för att bära flera RTP-paket i en enda underliggande protokollnyttolast.
Förlängning (X): 1 bit. Om förlängningsbiten är inställd följs den fasta rubriken av en rubrikförlängning med formatet definierat i .
CSRC-räknare (CC): 4 bitar. CSRC-räknaren innehåller antalet CSRC-källidentifierare som ska inkluderas (se lista över använda förkortningar och termer) som följer den fasta rubriken.
Markör (M): 1 bit. Tolkningen av markören bestäms av profilen. Det är avsett att tillåta att betydande händelser (t.ex. videoramgränser) markeras i paketströmmen. Profilen kan införa ytterligare markörbitar eller bestämma att ingen markörbit finns närvarande genom att ändra antalet bitar i trafiktypfältet (se ).
Trafiktyp (PT): 7 bitar. Det här fältet identifierar formatet för RTP-trafiken och bestämmer hur programmet ska tolka den. En profil definierar en standard statisk mappning av PT-värden och trafikformat. Ytterligare trafiktypskoder kan definieras dynamiskt via icke-RTP-faciliteter. Avsändaren av ett RTP-paket avger vid varje given tidpunkt ett enda RTP-trafiktypvärde; det här fältet är inte avsett för multiplexering av enskilda mediaströmmar (se ).
Sekvensnummer: 16 bitar. Sekvensnummervärdet ökas med ett med varje RTP-informationspaket som skickas och kan användas av mottagaren för att upptäcka förlorade paket och återställa deras ursprungliga sekvens. Det initiala värdet för sekvensnumret väljs slumpmässigt för att göra det svårt att knäcka nyckeln baserat på kända värden i detta fält (även om källan inte använder kryptering, eftersom paketen kan passera genom ett relä som använder kryptering). Tidsstämpel: 32 bitar. Tidsstämpeln återspeglar samplingstiden för den första oktetten i RTP-informationspaketet. Samplingstiden måste härledas från en timer som inkrementerar monotont och linjärt med tiden för att ge synkronisering och jitterdetektering (se avsnitt 4.3.1). Timerns upplösning bör vara tillräcklig för den önskade timingnoggrannheten och paketankomstjittermätning (en timerrapport per videobildruta är vanligtvis inte tillräckligt). Tidsfrekvensen beror på formatet för den överförda trafiken och ställs in statiskt i trafikformatprofilen eller specifikationen, eller kan ställas in dynamiskt för trafikformat som definieras genom "icke-RTP-verktyg". Om RTP-paket genereras periodiskt, bör de nominella samplingstiderna som bestäms av samplingstimern användas, inte värdena för systemtimern. Till exempel, för en ljudsignal med fast hastighet, är det önskvärt att tidsstämpelkodaren inkrementeras med en för varje sampelperiod. Om en ljudapplikation från en inmatningsenhet läser block som innehåller 160 sampel, måste tidsstämpeln ökas med 160 för varje sådant block, oavsett om blocket överfördes i ett paket eller släpptes som en paus. Tidsstämpelns initiala värde, liksom det initiala värdet för sekvensnumret, är en slumpmässig variabel. Flera på varandra följande RTP-paket kan ha lika tidsstämplar om de är logiskt genererade samtidigt, t.ex. tillhör samma videobildruta. Konsekutiva RTP-paket kan innehålla icke-monotona tidsstämplar om data inte sänds i provordning, vilket är fallet med interpolerade MPEG-videoramar (paketsekvensnumren kommer dock fortfarande att vara monotona när de sänds).
SSRC: 32 bitar. Fältet SSRC (synkroniseringskälla) identifierar synkroniseringskällan (se listan över använda förkortningar och termer). Detta ID är slumpmässigt valt så att inga två klockkällor inom samma RTP-session har samma SSRC ID. Även om sannolikheten för att flera ursprung väljer samma identifierare är låg, måste alla RTP-implementeringar vara förberedda för att upptäcka och lösa sådana kollisioner. Avsnitt 6 diskuterar sannolikheten för kollisioner tillsammans med en mekanism för att lösa dem och detektera RTP-lagerslingor baserat på SSRC-identifierarens unika karaktär. Om en källa ändrar sin ursprungliga transportadress måste den också välja en ny SSRC-identifierare så att den inte tolkas som en loopad källa.
CSRC-lista: 0 till 15 objekt, 32 bitar vardera. Listan med bidragande källor (CSRC) identifierar trafikkällorna som finns i paketet som ska inkluderas. Antalet identifierare ges av CC-fältet. Om det finns fler än femton inkluderade källor kan endast 15 av dem identifieras. CSRC ID:n infogas av mixers när SSRC ID:n används för switchade källor. Till exempel, för ljudpaket, listas SSRC-identifierarna för alla källor som blandades när paketet skapades i CSRC-listan, vilket ger en korrekt indikation av meddelandekällor till mottagaren.
Som nämnts ovan, i enlighet med RTP-protokollet, måste olika typer av trafik sändas separat, i olika RTP-sessioner. En session definieras av ett specifikt par destinationstransportadresser (en nätverksadress plus ett par portar för RTP och RTCP). Till exempel, i en telekonferens som består av separat kodat ljud och video, måste varje typ av trafik skickas i en separat RTP-session med sin egen destinationstransportadress. Ljud och video förväntas inte bäras i samma RTP-session och separeras baserat på trafiktyp eller SSRC-fält. Interfoliering av paket som har Olika typer trafik men att använda samma SSRC skulle orsaka några problem:
Genom att använda olika SSRC:er för varje typ av trafik, men skicka dem i samma RTP-session, kan de tre första problemen undvikas, men de två sista kan inte undvikas. Därför kräver specifikationen av RTP-protokollet att varje typ av trafik använder sin egen RTP-session.
Den befintliga RTP-informationspakethuvudet är komplett för den uppsättning funktioner som krävs i allmänhet för alla klasser av applikationer som kan stödja RTP. Men för bättre anpassning till specifika uppgifter kan rubriken modifieras genom modifieringar eller tillägg som definieras i profilspecifikationen.
Markörbiten och trafiktypfältet innehåller profilspecifik information, men är placerade i en fast rubrik eftersom många applikationer förväntas behöva dem. Oktetten som innehåller dessa fält kan omdefinieras av profilen för att möta olika krav, till exempel med fler eller färre markörbitar. Om några markörbitar finns, bör de placeras i oktettens högordningsbitar, eftersom profiloberoende monitorer kan observera en korrelation mellan paketförlustmönstret och markörbiten.
Ytterligare information som krävs för ett visst trafikformat (t.ex. videokodningstyp) MÅSTE finnas i paketets datafält. Den kan placeras på en viss plats i början eller inuti datamatrisen.
Om en viss klass av applikationer behöver ytterligare funktionalitet oberoende av trafikformatet, måste profilen som dessa applikationer arbetar med definiera ytterligare fasta fält som ska placeras omedelbart efter SSRC-fältet i den befintliga fasta rubriken. Dessa applikationer kommer snabbt att kunna komma åt ytterligare fält direkt, medan profiloberoende monitorer eller inspelare fortfarande kommer att kunna bearbeta RTP-paket genom att endast tolka de första tolv oktterna.
Om det anses att ytterligare funktionalitet behövs i allmänhet för alla profiler, då en ny version RTP för att göra permanent fast titeländring.
För att tillåta individuella implementeringar att experimentera med nya trafikformatoberoende funktioner som kräver att ytterligare information tas med i informationspakethuvudet, tillhandahåller RTP en pakethuvudförlängningsmekanism. Denna mekanism är utformad så att rubriktillägget kan ignoreras av andra samarbetande applikationer som inte kräver det.
Om X-biten i RTP-huvudet är inställt på ett, så läggs en rubrikförlängning med variabel längd till den fasta RTP-huvudet (efter CSRC-listan, om någon). Observera att detta rubriktillägg endast är avsett för begränsad användning. RTP-pakethuvudförlängningen har följande format:
Tillägget innehåller ett 16-bitars längdfält som indikerar antalet 32-bitars ord i det, exklusive fyroktettförlängningshuvudet (därav kan längden vara noll). Endast ett tillägg kan läggas till i en fast RTP-informationspakethuvud. För att tillåta var och en av ett flertal samverkande implementeringar att experimentera oberoende med olika header-tillägg, eller för att tillåta en viss implementering att experimentera med mer än en typ av header-tillägg, är användningen av de första 16 bitarna av tillägget odefinierad, överlåten till särskiljning identifierare eller parametrar. Formatet på dessa 16 bitar måste bestämmas av profilspecifikationen som applikationerna arbetar med.
| 1999 | ||||||||||||
| 2000 |
Kravet på att stödja flera typer av trafik med olika krav på servicekvalitet baserat på TCP/IP-protokollstacken är nu mycket relevant. Detta problem åtgärdas av Real-Time Transport Protocol (RTP), som är en IETF-standard för realtidsöverföring av data som röst eller video över ett nätverk som inte garanterar tjänstens kvalitet.
RTP-protokollet garanterar leverans av data till en eller flera mottagare med en fördröjning som inte överstiger det angivna värdet. För att göra detta innehåller protokollhuvudet tidsstämplar som är nödvändiga för framgångsrik återställning av ljud- och videoinformation, såväl som data om metoden för kodning av information.
Även om TCP-protokollet garanterar leverans av överförda data i korrekt sekvens, är trafiken inte enhetlig, det vill säga oförutsägbara förseningar inträffar under leveransen av datagram. Eftersom RTP-protokollet är medvetet om innehållet i datagram och har mekanismer för upptäckt av dataförlust, kan det minska latensen till en acceptabel nivå.
IP-protokolladressschema
Adresseringsschemat för internetarbete som används i IP-protokollet beskrivs i RFC 990 och RFC 997. Det är baserat på separationen av adresseringsnätverk från adresseringsenheter i dessa nätverk. Detta schema underlättar routing. I detta fall måste adresser tilldelas på ett ordnat (konsekutivt) sätt för att göra dirigeringen mer effektiv.
När TCP/IP-protokollstacken används i nätverket får slutenheterna unika adresser. Sådana anordningar kan vara personliga datorer, mediaservrar, routrar, etc. Vissa enheter som har flera fysiska portar, till exempel routrar, måste dock ha en unik adress på var och en av portarna. Baserat på adresseringsschemat och det faktum att vissa enheter i nätverket kan ha flera adresser, kan vi dra slutsatsen att detta schema adressering beskriver inte själva enheten i nätverket, utan en specifik anslutning av denna enhet till nätverket. Detta system leder till ett antal olägenheter. En av dem är behovet av att ändra enhetens adress när du flyttar den till ett annat nätverk. En annan nackdel är att för att arbeta med en enhet som har flera anslutningar i ett distribuerat nätverk måste du känna till alla dess adresser som identifierar dessa anslutningar.
Så för varje enhet i IP-nätverk kan vi prata om adresser på tre nivåer:
q Enhetens fysiska adress (mer exakt ett specifikt gränssnitt). För enheter på Ethernet-nätverk är detta MAC-adressen nätverkskort eller routerport. Dessa adresser tilldelas av hårdvarutillverkarna. Den fysiska adressen har sex byte: de tre övre byten är tillverkarens identifierare, de tre nedre byten tilldelas av tillverkaren;
q En IP-adress som består av fyra byte. Denna adress används i nätverkslagret referens model OSI;
q Teckenidentifierare - namn. Denna identifierare kan tilldelas godtyckligt av administratören.
När IP-protokollet standardiserades i september 1981 krävde dess specifikation att varje enhet som var ansluten till nätverket hade en unik 32-bitars adress. Denna adress är uppdelad i två delar. Den första delen av adressen identifierar nätverket där enheten finns. Den andra delen identifierar unikt själva enheten inom nätverket. Detta schema leder till en adresshierarki på två nivåer (Figur 6.23).
Nu anropas nätverksnummerfältet i adressen nätverksprefix, eftersom det identifierar nätverket. Alla arbetsstationer i nätverket delar samma nätverksprefix. De måste dock ha unika enhetsnummer. Två arbetsstationer belägna i olika nätverk, måste ha olika nätverksprefix, men de kan ha samma enhetsnummer.
För flexibilitet vid adressering dator nätverk Utformarna av protokollet bestämde att IP-adressutrymmet skulle delas in i tre olika klasser - A, B och C. Genom att känna till klassen vet du var gränsen mellan nätverksprefixet och enhetsnumret går i en 32-bitars adress . På fig. Figur 6.24 visar adressformaten för dessa grundläggande klasser.
En av de främsta fördelarna med att använda klasser är att du utifrån adressens klass kan avgöra var gränsen mellan nätverksprefixet och enhetsnumret går. Till exempel, om de två mest signifikanta bitarna i adressen är 10, är delningspunkten mellan bitarna 15 och 16.
Nackdelen med denna metod är behovet av att ändra nätverksadressen när du ansluter ytterligare enheter. Till exempel, om det totala antalet enheter i ett nätverk av klass C överstiger 255, måste dess adresser ersättas med adresser av klass B. Att ändra nätverksadresser kommer att kräva ytterligare ansträngningar från administratören för att felsöka nätverket. Nätverksadministratörer kan inte göra en smidig övergång till en ny klass av adresser eftersom klasserna är tydligt separerade. Du måste förbjuda användningen av en hel grupp nätverksadresser, ändra alla adresser till enheter i denna grupp samtidigt och först därefter tillåta att de används på nätverket igen. Dessutom minskar införandet av adressklasser det teoretiskt möjliga antalet individuella adresser avsevärt. I aktuell version IP-protokoll (version 4) det totala antalet adresser kan vara 2 32 (4 294 967 296), eftersom protokollet tillåter användning av 32 bitar för att specificera adressen. Naturligtvis minskar användningen av vissa bitar för tjänsteändamål det tillgängliga antalet individuella adresser.
Klass A är för stora nätverk. Varje klass A-adress har ett 8-bitars nätverksprefix med den mest signifikanta biten inställd på 1 och de nästa sju bitarna används för nätverksnumret. De återstående 24 bitarna används för enhetsnumret. För närvarande är alla klass A-adresser redan tilldelade. Klass A-nätverk kallas också "/8" eftersom klass A-adresser har ett 8-bitars nätverksprefix.
Det maximala antalet klass A-nätverk är 126 (2 7 -2 - två adresser subtraheras, bestående av endast nollor och ettor). Varje nätverk i denna klass stöder upp till 16 777 214 (2 24 -2) enheter. Eftersom ett klass A-adressblock kan innehålla maximalt 231 (2 147483648) individuella adresser, och IP-version 4 kan stödja maximalt 232 (4 294 967 296) adresser, upptar klass A 50 % av det totala IP-adressutrymmet. .
Klass B är avsedd för medelstora nätverk. Varje klass B-adress har ett 16-bitars nätverksprefix där de två mest signifikanta bitarna är 10 och de nästa 14 bitarna används för nätverksnumret. 16 bitar tilldelas för enhetsnumret. Klass B-nätverk kallas också "/16" eftersom klass B-adresser har ett 16-bitars nätverksprefix.
Det maximala antalet klass B-nätverk är 16 382 (2 14 -2). Varje nätverk i denna klass stöder upp till 65 534 (2 16 -2) enheter. Eftersom ett helt klass B-adressblock kan innehålla upp till maximalt 230 (1 073 741 824) individuella adresser, upptar det 25 % av det totala IP-adressutrymmet.
Klass C-adresser används i nätverk med ett litet antal enheter. Varje klass C-nätverk har ett 24-bitars nätverksprefix, där de tre mest signifikanta bitarna är 110, och de nästa 21 bitarna används för nätverksnumret. De återstående 8 bitarna tilldelas för enhetsnummer. Klass C-nätverk kallas också "/24" eftersom klass C-adresser har ett 24-bitars nätverksprefix.
Det maximala antalet klass C-nätverk är 2 097 152 (221). Varje nätverk i denna klass stöder upp till 254 (2 8 -2) enheter. Klass C upptar 12,5 % av det totala IP-adressutrymmet.
I tabell. 6.9 sammanfattar vår analys av nätverksklasser.
Tabell 6.9. Nätverksklasser
Utöver dessa tre klasser av adresser finns det ytterligare två klasser. I klass D är de fyra mest signifikanta bitarna 1110. Denna klass används för multicasting. I klass E är de fyra övre bitarna 1111. Det är reserverat för experiment.
För läsbarhet av adresser i teknisk litteratur, applikationsprogram etc. representeras IP-adresser som fyra decimaltal separerade med punkter. Vart och ett av dessa nummer motsvarar en oktett (8 bitar) av IP-adressen. Detta format kallas punktdecimal (decimalpunktsnotation) eller punktdecimalnotation (Figur 6.25).
I tabell. 6.10 listar intervallen för decimalvärden för de tre klasserna av adresser. I tabell. 6.10 XXX-post betyder ett godtyckligt fält.
Tabell 6.10. Adressvärdeintervall
Vissa IP-adresser kan inte tilldelas enheter i nätverket (tabell 6.11).
Som visas i denna tabell, i reserverade IP-adresser, motsvarar alla bitar som är nollställda någondera denna apparat, eller detta nätverk, och IP-adresser, vars alla bitar är inställda på 1, används i sändningsinformation. För att referera till hela IP-nätverket som helhet används en adress med ett enhetsnummer, med alla bitar inställda på "0". Klass A nätverksadress 127.0.0.0 är reserverad för loopback och introduceras för att testa kommunikation mellan processer på samma maskin. När en applikation använder en loopback-adress, returnerar TCP/IP-protokollstacken dessa data till applikationen utan att skicka något till nätverket. Dessutom kan denna adress användas för samverkan av separata processer inom samma maskin. Därför är det i IP-nätverk förbjudet att tilldela IP-adresser som börjar med 127 till enheter.
Förutom riktad dataöverföring till en specifik arbetsstation används aktivt sändningsöverföring, där alla stationer i det aktuella eller specificerade nätet tar emot information. Det finns två typer av sändningar i IP-protokollet: riktade och begränsade.
En riktad sändning tillåter en enhet på ett fjärrnätverk att skicka ett datagram till alla enheter i det aktuella nätverket. Ett datagram med en vidarebefordrad sändningsadress kan passera genom routrar, men det kommer bara att levereras till alla enheter i det angivna nätverket, inte till alla enheter. I en riktad sändning består destinationsadressen av ett specifikt nätverksnummer och ett enhetsnummer, varav alla bitar är 0 eller 1. Till exempel skulle adresserna 185.100.255.255 och 185.100.0.0 behandlas som riktade sändningsadresser för klassen B nätverk 185.100.xxx.xxx Ur adresseringssynpunkt är den största nackdelen med riktad sändning att kunskap om målnätets nummer krävs.
Den andra formen av sändning, som kallas begränsad sändning, sänder inom det aktuella nätverket (nätverket där den sändande enheten finns). Ett datagram med en begränsad sändningsadress kommer aldrig att passera en router. I begränsad sändning är bitarna för nätverksnummer och enhetsnummer alla nollor eller ettor. Således kommer ett datagram med destinationsadressen 255.255.255.255 eller 0.0.0.0 att levereras till alla enheter i nätverket. På fig. Figur 6.26 visar nätverk anslutna med routrar. I tabell. Figur 6.12 listar mottagarna av sändningsdatagram som skickats av arbetsstation A.
IP-protokollet stöder tre adresseringsmetoder: singel (unicast), broadcast (broadcast) och grupp (multicast).
Tabell 6.12. Broadcast Datagram-mottagare
Vid enkel adressering skickas datagram till en specifik enhet. Genomförandet av detta tillvägagångssätt är inte svårt, men om arbetsgrupp innehåller många stationer, kanske genomströmningen inte är tillräcklig, eftersom samma datagram kommer att sändas många gånger.
Med broadcast-adressering skickar applikationer ett enda datagram, som levereras till alla enheter i nätverket. Detta tillvägagångssätt är ännu enklare att implementera, men om i det här fallet sändningstrafiken inte är begränsad till det lokala nätverket (och till exempel ett annat nätverk vidarebefordras med routrar), så globalt nätverk måste ha betydande genomströmning. Om informationen endast är avsedd för en liten grupp enheter, verkar detta tillvägagångssätt irrationellt.
I multicast levereras datagram till en specifik grupp av enheter. Samtidigt (vilket är mycket viktigt när man arbetar i distribuerade nätverk) genereras ingen överskottstrafik. Multicast- och singeladressdatagram skiljer sig åt i adress. I huvudet på ett IP-datagram med multicast, istället för IP-adresser för klasserna A, B, C, finns det en klass D-adress, det vill säga en gruppadress.
En gruppadress tilldelas vissa mottagarenheter eller, med andra ord, till en grupp. Avsändaren skriver denna multicast-adress i rubriken på IP-datagrammet. Datagrammet kommer att levereras till alla medlemmar i gruppen. De första fyra bitarna i klass D-adressen är 1110. Resten av adressen (28 bitar) upptas av grupp-ID:t (Figur 6.27).
I prickade decimalformat sträcker sig gruppadresser från 224.0.0.0 till 239.255.255.255. I tabell. Figur 6.13 visar klass D-adressallokeringsschemat.
Tabell 6.13. Klass D-adresstilldelning
Som framgår av tabell. 6.13 är de första 256 adresserna reserverade. I synnerhet är detta intervall reserverat för routingprotokoll och andra lågnivåprotokoll. I tabell. 6.14 innehåller några reserverade klass D IP-adresser.
Ovanför detta intervall finns en stor grupp adresser dedikerade till applikationer som körs på Internet. Det översta adressintervallet (cirka 16 miljoner adresser) är för administrativa ändamål i lokala nätverk. Klass D gruppadresser hanteras centralt och registreras av en speciell organisation som heter IANA.
Multicast kan implementeras på två nivåer av OSI-modellen - kanal (Data-Link Layer) och nätverk (Network Layer). Länkskiktsöverföringsprotokoll, såsom Ethernet och FDDI, kan stödja singel-, broadcast- och multicast-adressering. Länklager multicast är särskilt effektivt om det stöds i hårdvara på nätverkskortet.
För att stödja IANA multicasting har ett block med multicast Ethernet-adresser tilldelats, med start från 01-00-5E (i hexadecimal notation). En multicast IP-adress kan översättas till en adress i detta block. Principen för översättning är ganska enkel: de nedre 23 bitarna av IP-gruppidentifieraren kopieras till de lägre 23 bitarna i Ethernet-adressen. Observera att detta schema associerar upp till 32 olika IP-grupper med samma Ethernet-adress, eftersom de nästa 5 bitarna av IP-grupp-ID:t ignoreras.
Tabell 6.14. Reserverade klass D-adresser
| Adress | Syfte |
| 224.0.0.1 | Alla enheter på subnätet |
| 224.0.0.2 | Alla routrar på subnätet |
| 224.0.0.4 | Alla DVMRP-routrar |
| 224.0.0.5 | Alla MOSPF-routrar |
| 224.0.0.9 | RIP IP version II |
| 224.0.1.7 | ljudnyheter |
| 224.0.1.11 | IEFT-ljud |
| 224.0.1.12 | IEFT video |
Om avsändare och mottagare tillhör densamma fysiskt nätverk, är processen att sända och ta emot multicast-ramar vid länkskiktet ganska enkel. Avsändaren anger IP-adressen för gruppen av mottagare, och NIC översätter denna adress till motsvarande grupp Ethernet-adress och skickar ramen.
Om sändaren och mottagaren finns på olika subnät anslutna med routrar är datagramleverans svårt. I det här fallet måste routrarna stödja ett av multicast-routningsprotokollen (DVMRP, MOSPF, PIM - se nedan). Enligt dessa protokoll kommer routern att bygga ett leveransträd och vidarebefordra multicast-trafiken korrekt. Dessutom måste varje router stödja Group Management Protocol (IGMP) för att fastställa närvaron av gruppmedlemmar på direktanslutna undernät (Figur 6.28).
Det huvudsakliga transportprotokollet för multimediaapplikationer har blivit realtidsprotokollet RTP (Real-Time Protocol), utformat för att organisera överföringen av paket med kodade talsignaler över ett IP-nätverk. Överföringen av RTP-paket utförs över UDP-protokollet, som i sin tur fungerar över IP (Fig. 1.5.).
Ris. 1.5.
Faktum är att nivån som RTP tillhör inte definieras så entydigt som visas i fig. 1.5 och som det brukar beskrivas i litteraturen. Å ena sidan fungerar protokollet verkligen ovanpå UDP, det är implementerat applikationsprogram och, av alla indikationer, är ett applikationsprotokoll. Men samtidigt, som nämnts i början av denna paragraf, tillhandahåller RTP transporttjänster oberoende av multimediaapplikationer och är ur denna synvinkel bara ett transportprotokoll. Bästa definition: RTP är ett transportprotokoll som implementeras i applikationslagret.
För att överföra rösttrafik (multimedia) använder RTP paket, vars struktur visas i fig. 1.6.
Ett RTP-paket består av minst 12 byte. De första två bitarna i RTP-huvudet (versionsbitfält, V) indikerar versionen av RTP-protokollet (för närvarande version 2).
Det är uppenbart att med denna rubrikstruktur är endast en RTP-version till som mest möjlig. Fältet efter dem innehåller två bitar: P-biten, som indikerar om utfyllnadstecken har lagts till i slutet av nyttolastfältet (de läggs vanligtvis till om transportprotokollet eller kodningsalgoritmen kräver användning av block med fast storlek), och X-biten, som indikerar om en utökad rubrik används.
Ris. 1.6.
Om det används innehåller det första ordet i den utökade rubriken den totala längden på tillägget. Vidare bestämmer de fyra CC-bitarna antalet CSRC-fält i slutet av RTP-huvudet, dvs. antalet källor som bildar flödet. Markörbiten M låter dig markera vad standarden definierar som betydande händelser, till exempel början av en videoram, början av ett ord i en ljudkanal, och så vidare. Det följs av ett PT-datatypfält (7 bitar), som indikerar nyttolasttypkoden som bestämmer innehållet i nyttolastfältet - applikationsdata (Application Data), till exempel okomprimerat 8-bitars MP3-ljud, etc. Från den här koden kan applikationen lära sig vad den ska göra för att avkoda data. Resten av rubriken med fast längd består av ett sekvensnummerfält, ett tidsstämpelfält för att registrera när det första ordet i paketet skapades, och ett SSRC-tidskällfält som identifierar denna källa. Det sista fältet kan vara en enda enhet med endast en nätverksadress, flera källor som kan representera olika media (ljud, video, etc.), eller olika strömmar av samma media. Eftersom källorna kan vara olika enheter, väljs SSRC-identifieraren slumpmässigt så att chansen att ta emot data från två källor samtidigt under en RTP-session är minimal. Men en mekanism för att lösa konflikter om de uppstår definieras också. Den fasta delen av RTP-huvudet kan följas av upp till 15 separata 32-bitars CSRC-fält som identifierar datakällor.
RTP stöds av RTCP (Real-Time Transport Control Protocol), som genererar ytterligare rapporter som innehåller information om RTP-sessioner. Kom ihåg att varken UDP eller RTP är engagerade i att tillhandahålla QoS (Quality of Service). RTCP-protokollet tillhandahåller respons med avsändare, och för strömmottagare ger det vissa QoS-förbättringar, paketinformation (förlust, fördröjning, jitter) och användare (applikation, ström). För flödeskontroll finns det två typer av rapporter - genererade av avsändare och genererade av mottagare. Till exempel kan information om procentandelen förlorade paket och det absoluta antalet förluster göra det möjligt för avsändaren, när den tar emot en rapport, att upptäcka att kanalöverbelastning kan orsaka att mottagare inte tar emot paketströmmar som de förväntade sig. I det här fallet har avsändaren möjlighet att sänka kodningshastigheten för att minska trängseln och förbättra mottagningen. Avsändarrapporten innehåller information om när det senaste RTP-paketet genererades (den inkluderar både en intern tidsstämpel och realtid). Denna information gör det möjligt för mottagaren att koordinera och synkronisera flera strömmar som video och ljud. Om strömmen riktas till flera mottagare, organiseras strömmar av RTCP-paket från var och en av dem. Detta kommer att vidta åtgärder för att begränsa bandbredden - omvänt proportionell mot hastigheten med vilken RTCP-rapporter genereras och antalet mottagare.
Det bör noteras att även om RTCP fungerar separat från RTP, leder RTP/UDP/IP-kedjan i sig till betydande overhead (i form av deras rubriker). G.729-codec genererar paket på 10 byte (80 bitar var 10:e ms). En RTP-header, 12 byte stor, är större än hela detta paket. Dessutom måste en 8-byte UDP-header och en 20-byte IP-header (i IPv4) läggas till, vilket skapar en header som är fyra gånger så stor som den överförda datan.
