Rtp-protokollportar. Användningen av Internetprotokoll i IP-telefoni

Det här avsnittet diskuterar några aspekter av transport av RTP-paket med nätverk och transportprotokoll. Om inte annat anges i andra protokollspecifikationer, gäller följande allmänna regler vid överföring av paket.

RTP förlitar sig på underliggande protokoll för att ge separation mellan 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 en högre.

RTP-informationspaket innehåller inte något längdfält, därför förlitar sig RTP på ett underliggande protokoll för att ge en indikation på längden. Den maximala längden på RTP-paket begränsas endast av de underliggande protokollen.

Flera RTP-paket kan bäras i en enda lägre lagerprotokolldataenhet, såsom ett UDP-paket. Detta minskar redundansen av rubriker och kan förenkla synkronisering mellan olika strömmar.

9. Lista över protokollkonstanter

Det här avsnittet innehåller en lista över konstanter som definieras i RTP-protokollspecifikationen.

RTP-trafiktypkonstanter (PT - nyttolasttyp) definieras i profiler. RTP-header-oktetten, som innehåller markörbiten/-erna och trafiktypfältet, FÅR dock inte innehålla de 200 och 201 (decimal) reserverade värdena för att skilja RTP-paket från RTCP SR- och RR-paket. För ett standardformat med en token-bit och ett sju-bitars trafiktypfält innebär denna begränsning att trafiktyperna 72 och 73 inte ska användas.

Värdena för RTCP-pakettyper (se tabell 1) väljs i intervallet från 200 till 204 för bättre kontroll korrektheten av rubriken för RTCP-paket 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 vanligtvis inte är fallet i datapaket) och den mest signifikanta biten i standardtrafiktypfältet lika med ett (medan statiskt specificerade trafiktyper vanligtvis har värden på PT med en nolla i den mest signifikanta siffran). Detta intervall har också valts för att ytterligare distansera det från värdena 0 och 255, eftersom fält som är helt nollor eller ettor mestadels är dataspecifika.

Andra RTCP-pakettyper definieras av IANA-gemenskapen. Utvecklare har möjlighet att registrera de värden de behöver för att utföra experimentell forskning och sedan avbryta registreringen eftersom behovet av dessa värden försvinner.

De tillåtna typerna av objekt i SDES-paketet presenteras i tabellen. 2. Andra typer av SDES-klausuler är utsedda av IANA-gemenskapen. Utvecklare har möjlighet att registrera de värden de behöver när de utför experimentell forskning och sedan avregistrera dem när dessa värden inte längre behövs.

10. Beskrivning av trafikprofilen och formatet

Som noterats ovan (se avsnitt 2), för full beskrivning RTP-protokoll för en specifik applikation kräver ytterligare dokument av två typer: en beskrivning av profilen och formatet för trafiken.

RTP kan användas för många klasser av applikationer med mycket olika krav. Flexibiliteten att anpassa sig till dessa krav tillhandahålls genom användningen av 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 ytterligare dokument av den andra typen, Traffic Format Specification, definierar hur en speciell typ av trafik (t.ex. video kodad enligt H.261) ska sändas i enlighet med RTP. Samma trafikformat kan användas för flera profiler och kan därför definieras oberoende av profilen. Profildokument är endast ansvariga för att överensstämma med detta format och PT-värde .

Följande poster kan definieras i profilbeskrivningen, men denna lista är inte uttömmande.

RTP-datapakethuvud. Oktetten i huvudet på ett RTP-datapaket, som innehåller en tokenbit och ett trafiktypfält, kan omdefinieras enligt profilen för att uppfylla olika krav, till exempel att tillhandahålla fler eller färre tokenbitar (avsnitt 3.3).

Trafiktyper. En profil definierar vanligtvis en mängd olika trafikformat (t.ex. mediakodningsalgoritmer) och en standard statisk mappning av dessa format och PT-värden. Vissa av trafikformaten kan identifieras med hänvisning till enskilda trafikformatsbeskrivningar. För varje specifik 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. Ytterligare fält kan läggas till i RTP-datapaketets fasta rubrik om ytterligare funktionalitet krävs inom profilens applikationsklass, oavsett typ av trafik. .

RTP-datapakethuvudförlängningar. Innehållet i de första 16 bitarna i RTP-datapakethuvudförlängningsstrukturen ska specificeras om användningen av denna mekanism tillåts av profilen. .

RTCP-pakettyper. Nya applikationsklassspecifika RTCP-pakettyper kan definieras (och registreras av IANA).

RTCP-rapporteringsintervall. Profilen bör definiera de värden som ska användas för att beräkna RTCP-rapporteringsintervallet: andelen av RTCP-sessionens bandbredd, minsta rapporteringsintervall och fördelningen av bandbredden mellan sändare och mottagare.

Förlängning av SR / RR-paketet. Om det finns ytterligare käll- eller destinationsinformation som behöver sändas regelbundet, kan en förlängningssektion specificeras för RTCP SR- och RR-paket.

Använder SDES. Profilen kan definiera relativa prioriteringar för RTCP SDES-objekt som ska skickas vidare eller tas bort (se avsnitt 4.2.2); alternativ syntax eller semantik för CNAME-sats (avsnitt 4.4.1); LOC-objektformat (avsnitt 4.4.5); semantik och användning av NOTE-klausul (avsnitt 4.4.7) och nya SDES-klausuler som ska registreras hos IANA.

Säkerhet. Profilen kan definiera vilka säkerhetstjänster och algoritmer som applikationer behöver använda, och kan styra deras användning (klausul 7).

Matchning av lösenord till nyckel. Profilen kan avgöra hur ett användarinmatat lösenord konverteras till en krypteringsnyckel.

Protokoll för lägre lager. RTP-paket kan kräva användning av ett specifikt underliggande nätverk eller transportlagerprotokoll.

Transportöverensstämmelse. KAN definieras på annat sätt än de vanliga RTP- och RTCP-överensstämmelserna som specificeras i paragraf 8 för att transportera lageradresser, såsom UDP-portar.

Inkapsling. RTP-paketformning kan definieras för att tillåta överföring av flera informationspaket RTP i en lägre 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 en klass av applikationer, snarare än att skapa en ny. Detta kommer att göra det lättare för applikationer att interagera, eftersom var och en vanligtvis körs under endast en profil. Enkla tillägg, som att definiera ytterligare PT-värden eller RTCP-pakettyper, kan åstadkommas genom att registrera dem hos IANA och publicera deras beskrivningar i en profilspecifikation eller i en trafikformatspecifikation.

11. RTP-profil för ljud- och videokonferenser med minimal kontroll

RFC 1890 beskriver en profil för att använda realtidstransportprotokollet RTP version 2 och dess tillhörande kontrollprotokoll RTCP i en gruppljud- eller videokonferens, den så kallade RTP-profilen för ljud- och videokonferenser med minimal kontroll (RTP Profile for Audio och Videokonferenser med minimal kontroll). Den här profilen definierar aspekter av RTP som inte specificeras i RTP version 2 Protocol Specification (RFC 1889). Miniminivån av kontroll innebär att inget stöd för förhandling av parametrar eller kontroll av ägande krävs (till exempel vid användning av statiska mappningar av trafiktyper och indikationer på ägande som tillhandahålls av RTCP). Låt oss överväga de viktigaste bestämmelserna i denna profil.

11.1. RTP- och RTCP-paketformat och protokollparametrar

Det här avsnittet innehåller en beskrivning av ett antal objekt som kan definieras eller ändras i en profil.

RTP-informationspakethuvud. Standardformatet för den fasta RTP-informationspakethuvudet (en tokenbit) används.

Trafiktyper. Trafiktypernas statiska värden definieras i avsnitt 11.3 och 11.4.

RTP-informationspakethuvudtillägg. Inga ytterligare fasta fält läggs till i RTP-informationspakethuvuden.

RTP-informationspakethuvudtillägg. Inga RTP-informationspakethuvudtillägg är definierade, men applikationer som använder denna profil KAN använda sådana tillägg. Det vill säga, det bör inte antas i applikationer att X-biten i RTP-huvudet alltid är noll. Applikationer måste vara förberedda för att ignorera rubriktillägget. Om en rubriktillägg specificeras i framtiden måste innehållet i de första 16 bitarna specificeras så att många olika tillägg kan identifieras.

RTCP-pakettyper. Inga ytterligare RTCP-pakettyper är definierade i denna profilspecifikation.

RTCP-rapporteringsintervall. Konstanterna som föreslås i RFC 1889 MÅSTE användas vid beräkning av RTCP-rapporteringsintervallet.

SR / RR paketförlängningar. Inga tillägg är definierade för RTCP SR- och RR-paket.

Använder SDES. Applikationer kan använda vilken som helst av SDES-klausulerna som beskrivs. Medan den kanoniska namninformationen (CNAME) skickas i varje rapporteringsintervall, bör andra objekt endast skickas vart femte rapporteringsintervall.

Säkerhet. Standard-RTP-säkerhetstjänsterna definieras också som standard av denna profil.

Matchning av lösenord till nyckel. Lösenordet som angetts av användaren omvandlas med hjälp av MD5-algoritmen till ett sammandrag på 16 oktetter. En N-bitars nyckel erhålls från en sammandragning genom att använda dess första N bitar. Det antas att lösenordet endast kan innehålla ASCII-bokstäver, siffror, bindestreck och mellanslag för att minska sannolikheten för förvrängning vid överföring av lösenord via telefon, fax, telex eller e-post. Lösenordet kan föregås av en specifikation av krypteringsalgoritmen. Alla tecken upp till det första snedstrecket framåt (ASCII-kod 0x2f) tolkas som namnet på krypteringsalgoritmen. Om det inte finns något snedstreck är standard DES-CBC-kryptering.

Innan den avslutande algoritmen tillämpas, konverteras lösenordet som användaren har angett till kanonisk form. För att göra detta konverteras lösenordet till ISO 10646-teckenuppsättningen med UTF-8-kodning enligt definition i Appendix P till ISO / IEC 10646-1: 1993 (ASCII-tecken kräver ingen konvertering); blanksteg i början och slutet av lösenordet tas bort; två eller flera mellanslag ersätts med ett mellanslag (ASCII eller UTF-8 0x20); alla bokstäver konverteras till små bokstäver

Underliggande protokoll. Profilen definierar användningen av RTP över UDP i tvåvägs- och multicast-läge.

Transportöverensstämmelse. En standardöverensstämmelse mellan RTP- och RTCP-transportlageradresser används.

Inkapsling. RTP-paketinkapsling är odefinierad.

11.2. Registrering av trafikslag

Den här profilen definierar standardkodningstyperna som används med RTP. Andra typer av kodning måste registreras hos IANA före användning. Vid registrering av en ny typ av kodning ska följande information lämnas:

• kodnamnet för kodningstypen och klockfrekvensen för RTP-tidsstämpeln (kodnamnet bör vara tre eller fyra tecken långt för att ge en kompakt representation, om nödvändigt);
• en indikation på vem som har rätt att ändra typ av kodning (till exempel ISO, CCITT / ITU, andra internationella standardiseringsorgan, konsortium, specifikt företag eller företagsgrupp);
• alla driftsparametrar;
• länkar till tillgängliga beskrivningar av kodningsalgoritmen, såsom (i prioritetsordning) RFC, publicerad artikel, patentansökan, teknisk rapport, codec-källa eller referens;
• för privata kodningstyper, kontaktinformation (postadress och e-postadress);
• värde för att indikera typen av trafik för denna profil, om nödvändigt (se nedan).
• Observera att inte alla kodningstyper som ska användas med RTP behöver vara statiskt tilldelade. Icke-RTP-medel, som inte täcks av den här artikeln, kan användas för att dynamiskt mappa mellan ett trafiktypsvärde (PT) i intervallet 96 till 127 och en kodningstyp.
• Det tillgängliga värdeutrymmet för trafiktyper är ganska litet. Nya trafiktyper tilldelas statiskt (permanent) endast om följande villkor är uppfyllda:
• kodning är av stort intresse för samhället Internetnätverk;
• det erbjuder fördelar som är jämförbara med befintliga kodningar och/eller krävs för interoperabilitet med befintliga, allmänt använda konferens- eller multimediasystem;
• beskrivningen är tillräcklig för att skapa en avkodare.

11.3. Ljudkodning

För applikationer som inte skickar paket under pauser, kännetecknas det första aktivt talpaketet (det första paketet efter pausen) av en token-bit satt till ett i rubriken på RTP-bärarpaketet. Icke-tystade applikationer sätter denna bit till noll.

RTP-klockan som används för att generera RTP-tidsstämpeln är oberoende av antalet kanaler och typen av kodning; det är lika med antalet samplingsperioder per sekund. För N-kanalskodning (stereo, quad, etc.), genererar varje samplingsperiod (säg 1/8000 av en sekund) N sampel. Det totala antalet sampel som genereras per sekund är lika med samplingshastigheten gånger 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änd nästa system beteckningar:

• l - vänster;
• r - höger;
• c - central;
• S - perifer;
• F - frontal;
• R - tillbaka.

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

Samplar av alla kanaler som hör till samma samplingstid måste finnas i samma paket. Interfolieringen av sampel från olika kanaler beror på typen av kodning.

Samplingsfrekvensen måste väljas från en mängd olika: 8000, 11025, 16000, 22050, 24000, 32000, 44100 och 48000 Hz (Apple Macintosh-datorer har sina egna samplingsfrekvenser på 22254,127 och 5 kan konverteras till 2254,127 och 2254,127 och 22254,127. acceptabel kvalitet genom att hoppa över fyra eller två prover i en 20 ms ram). De flesta ljudkodningsalgoritmer är dock definierade för en mer begränsad uppsättning samplingshastigheter. Mottagarna måste vara beredda att ta emot flerkanaligt ljud, men kan också välja mono.

För paketering av en ljudsignal ska standardpaketeringsintervallet vara 20 ms, om inte annat anges i kodningsbeskrivningen. Paketiseringsintervallet definierar den lägsta fördröjningen från slut till ände. Längre paket har relativt färre byte för headern, men de orsakar mer fördröjning och gör paketförlusten mer betydande. För icke-interaktiva applikationer, såsom föreläsningar, eller kanaler med betydande bandbreddsbegränsningar, kan högre paketeringsfördröjning vara acceptabel. Mottagaren bör ta emot paket med en ljudsignal med en fördröjning på 0 till 200 ms. Denna begränsning ger 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 ett ljudpaket bestäms av antalet sampel i paketet.

För sampelbaserade kodningstyper som producerar en eller flera oktetter för varje sampel, packas sampel från olika kanaler som samplades samtidigt i intilliggande oktetter. Till exempel, för att koda stereoljud, är oktettsekvensen: vänster kanal, första sampel; höger kanal, första räkning; vänster kanal, andra räkning; höger kanal, andra räkning osv. Vid multioktettkodning sänds den mest signifikanta oktetten först. Packningen av sampelbaserade kodningar som producerar mindre än en oktett för varje sampel bestäms av kodningsalgoritmen.

En rambaserad kodningsalgoritm 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 meddelande.

För rambaserade codecs är kanalordningen specifik 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 de ramorienterade kodekarna ä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.

Tabell 3 visar värdena för trafiktyperna (PT) som definieras av denna profil för ljudsignaler, deras legend och det huvudsakliga specifikationer kodningsalgoritmer.

11.4. Videokodning

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 inställda 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 trafiktyp 96 för en given session betecknar dubbelkanals PCMU-kodning vid 8000 Hz. Området för trafiktypsvärden markerade som "reserverade" används inte så att RTCP- och RTP-paket kan särskiljas på ett tillförlitligt sätt .

En RTP-källa matar vid en given tidpunkt endast ut en typ av trafik; trafikinterleaving olika typer i en session är RTP inte tillåtet. 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 tillåtet att definiera kombinerade trafiktyper som kombinerar till exempel ljud och bild, med lämplig separation i trafikformatet.

Ljudapplikationer som använder denna profil måste som minimum kunna skicka och ta emot trafiktyperna 0 (PCMU) och 5 (DVI4). Detta möjliggör interoperabilitet utan formatförhandling.

11.5. Hamnuppdrag

Som definierats i RTP-protokollbeskrivningen måste RTP-data skickas över en jämn UDP-port och motsvarande RTCP-paket måste skickas över en udda port.

Applikationer som använder den här profilen kan använda vilket UDP-portpar som helst. Till exempel kan ett par portar tilldelas slumpmässigt av sessionshanteringsprogrammet. Ett enstaka 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 en indikator för den profilen. Men applikationer kan också kräva att ett portpar anges explicit.

12. Lista över använda termer och förkortningar

• ASCII (American Standard Code for Information Interchange) är den amerikanska standardkoden för informationsutbyte. 7-bitars presentationskod textinformation används med vissa modifieringar i de flesta datorsystem
• CBC (chiffer block chaining) - krypterad blockkedja, DES datakryptering standardläge
• CELP (code-excited linear prediction) är en typ av ljudkodning som använder kodexciterad linjär prediktion
• CNAME (kanoniskt namn) - kanoniskt namn
• CSRC (bidragande källa) - inkluderad källa. Källan till RTP-paketströmmen som bidrog till den kombinerade strömmen som producerades av RTP-mixern. Mixern infogar i RTP-pakethuvudet en lista med SSRC-identifierare för de källor som deltog i bildandet av detta paket. Denna lista kallas CSRC-listan. Exempel: Mixern sänder ID:n för de telefonkonferensdeltagare som för närvarande talar vars röster har mixats och använts för att skapa det utgående paketet, och pekar mottagaren på den aktuella meddelandekällan, även om alla ljudpaket innehåller samma SSRC-ID (som mixern)
• DES (Data Encryption Standard) - datakrypteringsstandard
• IANA (Internet Assigned Numbers Authority) - Internet Assigned Numbers Community
• IMA (Interactive Multimedia Association) - Interactive Multimedia Association
• IP (Internet Protocol) - mellan nätverksprotokoll, nätverkslagerprotokoll, datagramprotokoll. Tillåter paket att korsa flera nätverk på väg till sin destination
• IPM (IP Multicast) - multicast som använder IP-protokollet
• LD-CELP (low-delay code excited linear prediction) - en talkodningsalgoritm som använder kodexciterad linjär prediktion med låg fördröjning
• LPC (linear predictive encoding) - linjär prediktiv kodning
• NTP (Network Time Protocol) är en nedräkning av tiden 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 fall används en mer kompakt representation, där endast de mellersta 32 bitarna tas från fullformatet: de nedre 16 bitarna av heltalsdelen och de övre 16 bitarna av bråkdelen.
• RPE / LTP (residual pulse excitation / long term prediction) - en talkodningsalgoritm med differentiell impulsexcitering och långtidsprediktion
• RTCP (Real-Time Control Protocol) - kontrollprotokoll för dataöverföring i realtid
• RTP (Real-Time Transport Protocol) - transportprotokoll i realtid
• SSRC (synkroniseringskälla) - synkroniseringskälla. Källan till RTP-paketströmmen, identifierad av den 32-bitars numeriska SSRC-identifieraren som finns i RTP-huvudet, oavsett nätverksadressen. Alla paket med samma synkkälla använder samma timing och sekvensnummerutrymme, så mottagaren grupperar paketen för uppspelning med synkkällan. Exempel på synkroniseringskälla: avsändare av en ström av paket som tagits emot från en signalkälla mikrofontyp, videokamera eller RTP-mixer. Synkroniseringskällan kan ändra dataformatet med tiden, t.ex. ljudkodning... SSRC-identifierare är ett slumpmässigt valt värde som anses vara globalt unikt inom en viss RTP-session. Telekonferensdeltagaren behöver inte använda samma SSRC för alla RTP-sessioner i en multimediakommunikationssession; SSRC-identitetsaggregering tillhandahålls genom RTCP. Om en deltagare genererar flera strömmar i en RTP-session, till exempel från flera videokameror, måste varje ström identifieras av en separat SSRC
• TCP (Transmission Control Protocol) är ett transportlagerprotokoll som används i samband med IP
• UDP (User Datagram Protocol) är ett anslutningslöst transportlagerprotokoll. UDP tillåter endast att ett paket skickas till en eller flera stationer i nätverket. Validering och säkerställande av integriteten (garanterad leverans) av dataöverföring utförs på en högre nivå
• ADPCM - Adaptiv differentiell pulskodmodulering
• jitter - jitter, fas eller frekvensavvikelser hos signalen; i förhållande till IP-telefoni - oegentligheter i fördröjningen av datagram i nätverket
• ZPD - dataöverföringslänk (andra nivån i referensmodellen för interaktion öppna system)
• IVS - information och datornätverk
• mixer - ett mellansystem som tar emot RTP-paket från en eller flera källor, eventuellt ändrar dataformatet, kombinerar paketen till nytt paket RTP och sänder den sedan. Eftersom många signalkällor i allmänhet inte är synkroniserade, justerar mixern timingen för komponentströmmarna och genererar sin egen timing för den kombinerade strömmen. Sålunda identifieras alla informationspaket som genereras av mixern som har mixern som sin synkkälla.
• monitor (monitor) - en applikation som tar emot RTCP-paket skickade av deltagare i en RTP-session, i synnerhet mottagningsrapporter, och utvärderar den aktuella tjänstens kvalitet för att kontrollera distributionen, upptäcka fel och långsiktig statistik. Vanligtvis ligger monitorns funktioner med applikationerna som används i sessionen, men monitorn kan också vara en separat applikation som inte annars används, inte skickar eller tar emot RTP-datapaket. Sådana applikationer kallas tredjepartsmonitorer.
• ITU-T - International Telecommunication Union Telecommunication Standardization Sector
• slutsystem - en applikation som genererar innehåll som överförs i RTP-paket och/eller som förbrukar innehållet i mottagna RTP-paket. Slutsystemet kan fungera som en eller flera (men vanligtvis bara en) klockkällor i varje RTP-session
• RTCP-paket - Ett kontrollpaket som består av en fast del av huvudet, liknande RTP-informationspaketen, följt av strukturella element som varierar beroende på typen av RTCP-paket. Vanligtvis skickas flera RTCP-paket tillsammans som ett sammansatt RTCP-paket i ett enda underliggande protokollpaket; detta tillhandahålls av längdfältet i den fasta rubriken för varje RTCP-paket
• RTP-paket är en protokolldataenhet som består av ett fast RTP-huvud, möjligen en tom lista med inkluderade källor, tillägg och trafik. Vanligtvis innehåller ett lägre lagerprotokollpaket ett RTP-paket, men det kan finnas flera
• port är en abstraktion som används av protokoll på transportnivå för att skilja mellan flera destinationer inom en enda värddator. Porten identifieras med sitt nummer. Således är portnumret ett nummer som identifierar den specifika applikation för vilken data som skickas är avsedd. Detta nummer, tillsammans med information om vilket protokoll (t.ex. TCP eller UDP) som används på det högre lagret, finns bland annan tjänstinformation i datagram som skickas över Internet. Transportväljare (TSEL) som används av transporten OSI lager, motsvarar portar
• profil (profil) - en uppsättning parametrar för RTP- och RTCP-protokollen för en klass av applikationer, som bestämmer funktionerna i deras funktion. Profilen definierar användningen av tokenbitar och trafiktypfält i RTP-datapakethuvudet, trafiktyper, tillägg av RTP-datapakethuvud, första 16 bitar av RTP-datapakethuvudförlängning, RTCP-pakettyper, RTCP-rapporteringsintervall, SR/RR-paket förlängning, användning av SDES-paket, tjänster och algoritmer för att säkerställa kommunikationssäkerhet och specifikationer för att använda det lägre lagerprotokollet
• RTP-session (RTP-session) - kommunikation mellan många deltagare som interagerar via RTP-protokollet. För varje deltagare bestäms sessionen av ett specifikt par destinationstransportadresser (en nätverksadress plus ett par portar för RTP och RTCP). Ett par transportdestinationsadresser kan vara gemensamma för alla deltagare (som i fallet med IPM) eller kan vara olika för var och en (enskild nätverksadress och ett gemensamt par av portar, som vid dubbelriktad kommunikation). I en multimediasession skickas varje typ av trafik i en separat RTP-session med sina egna RTCP-paket. Multicast RTP-sessioner kännetecknas av olika portparnummer och/eller olika multicast-adresser
• icke-RTP-medel — Protokoll och mekanismer som kan behövas utöver RTP för att tillhandahålla en acceptabel tjänst. Särskilt för multimediakonferenser kan tilldela multicast-adresser och krypteringsnycklar, förhandla fram krypteringsalgoritmen som ska användas och bestämma dynamiska mappningar mellan RTP-trafiktypvärdena och trafikformaten de representerar (format som inte har en fördefinierat värde. trafiktyp). För enkla applikationer kan också användas E-post eller konferensdatabas
• translator - ett mellansystem som vidarebefordrar RTP-paket utan att ändra synkroniseringskällidentifieraren. Exempel på översättare: enheter som utför omkodning utan blandning, flervägs- eller dubbelriktade replikatorer, applikationslagerapplikationer i brandväggar
• transportadress - En kombination av nätverksadress och portnummer som identifierar transportlagrets slutpunkt, såsom en IP-adress och UDP-portnummer. Paket vidarebefordras från källtransportadressen till destinationstransportadressen
• RTP-trafik - multimediadata som överförs i ett RTP-paket, såsom ljudprover eller komprimerad videodata
• PSTN - publika telefonnät

Det mest akuta problemet blir alltmer bristen på adressutrymme, vilket kräver en förändring av formatet på adressen.

Ett annat problem är bristen på skalbarhet för routing, grunden för IP-nätverk. Nätverkets snabba tillväxt orsakar trängsel på routrar, som redan idag måste upprätthålla routingtabeller med tiotals eller hundratusentals poster, samt lösa problemet med paketfragmentering. Det är möjligt att göra driften av routrar enklare, särskilt genom att uppgradera IP-protokollet.

Tillsammans med införandet av nya funktioner direkt i IP-protokollet, är det tillrådligt att säkerställa dess närmare interaktion med nya protokoll genom att introducera nya fält i pakethuvudet.

Som ett resultat beslutades det att uppgradera IP-protokollet, med följande huvudmål:

• skapande av ett nytt utökat adresseringssystem;
• förbättra nätverkets skalbarhet genom att minska funktionerna hos stamnätsroutrar;
• säkerställa dataskydd.

Utökar adressutrymmet... IP-protokollet löser det potentiella problemet med adressbrist genom att utöka adressbredden till 128. En så betydande ökning av adressens längd gjordes dock till stor del inte för att ta bort problemet med adressbrist, utan för att förbättra effektiviteten hos nätverk baserade på detta protokoll. Huvudmålet var att strukturellt förändra adresseringssystemet, utöka dess funktionalitet.

Istället för de befintliga två nivåerna i adresshierarkin (nätverksnummer och nodnummer) föreslår IPv6 att fyra nivåer ska användas, vilket innebär nätverksidentifiering på tre nivåer och en nivå för nodidentifiering.

Nu skrivs adressen i hexadecimal form, med var fjärde siffra separerad från varandra med ett kolon, till exempel:

FEDC: 0A96: 0: 0: 0: 0: 7733: 567A.

För nätverk som stöder båda versionerna av IPv4 och IPv6 är det möjligt att använda traditionell decimalnotation för de nedre 4 byten och hexadecimal för de övre:

0: 0: 0: 0: FFFF 194.135.75.104.

Inom IPv6-adresseringssystemet finns även ett dedikerat adressutrymme för lokalt bruk, det vill säga för nätverk utanför Internet. Det finns två typer lokala adresser: för icke-undernätade platta nätverk (Link-Local) och för subnätverk (Site-Local), som skiljer sig i prefixvärdet.

Ändra formatet på pakethuvuden. Detta kan åstadkommas genom ett nytt organisationsschema för "kapslade rubriker", som tillhandahåller uppdelningen av rubriken i den huvudsakliga, som innehåller det nödvändiga minimum av information, och ytterligare sådana, som kan saknas. Detta tillvägagångssätt öppnar rika möjligheter för att utöka protokollet genom att definiera nya valfria rubriker, vilket gör protokollet öppet.

Den grundläggande 40-byte IPv6-datagramhuvudet har följande format (Figur 2.4).

Fält Trafikklassär likvärdig i syfte med området Typ av service och fältet Hoppgräns- fält Tid att leva IPv4-protokoll.

Fält Flödesetikett låter dig isolera och specifikt bearbeta individuella dataströmmar utan att behöva analysera innehållet i paketen. Detta är mycket viktigt när det gäller att minska belastningen på routrarna.

Fält Nästa rubrikär analog med IPv4-protokollfältet och definierar typen av rubrik som följer efter huvudhuvudet. Varje efterföljande extra rubrik innehåller också ett nästa rubrikfält.

2.3.3. TCP-protokoll

Kontrollprotokollöverföring av information (Transmission Control Protocol - TCP) utvecklades för att stödja interaktiv kommunikation mellan datorer. TCP-protokollet säkerställer tillförlitligheten och tillförlitligheten för datautbyte mellan processer på datorer som ingår i ett gemensamt nätverk.

Tyvärr kan TCP inte överföra multimediainformation... Den främsta orsaken är närvaron av kontroll över leveransen. Övervakning tar för lång tid att överföra mer fördröjningskänslig information. Dessutom tillhandahåller TCP mekanismer för att kontrollera överföringshastigheten för att undvika överbelastning i nätverket. Ljud- och videodata kräver dock strikt definierade bithastigheter som inte kan ändras godtyckligt.

Å ena sidan interagerar TCP med applikationsprotokollet för användarapplikationen, och å andra sidan med protokollet som tillhandahåller "lågnivå" paketdirigerings- och adresseringsfunktioner, som vanligtvis utförs av IP.

Den logiska strukturen för nätverksprogramvara som implementerar protokollen för TCP / IP-familjen i varje nod på Internet visas i fig. 2.5.

Rektanglarna representerar modulerna som bearbetar data, och linjerna som förbinder rektanglarna representerar dataöverföringsvägarna. Den horisontella linjen längst ner i figuren betecknar ett Ethernet-nätverk, som används som ett exempel på ett fysiskt medium.

Ris. 2.5.

Att upprätta en koppling mellan två processer på olika datorer nätverk, behöver du inte bara känna till datorernas internetadresser, utan också numren på de TCP-portar (sockets) som processer använder på dessa datorer. Varje TCP-anslutning på Internet identifieras unikt av två IP-adresser och två TCP-portnummer.

TCP kan hantera skadade, förlorade, duplicerade eller ur funktion. Detta uppnås genom en mekanism för att tilldela ett sekvensnummer till varje överfört paket och en mekanism för att kontrollera mottagandet av paket.

När TCP sänder ett datasegment, placeras en kopia av denna data i en återsändningskö och en timer startas för att vänta på en bekräftelse.

2.3.4. UDP-protokoll

User Datagram Protocol (UDP) används för att utbyta datagram mellan processer för datorer som finns i ett enhetligt system av datornätverk.

UDP är baserat på IP och tillhandahåller ansökningsprocesser med transporttjänster som inte skiljer sig mycket från IP. UDP-protokollet tillhandahåller icke-garanterad dataleverans, det vill säga det kräver ingen bekräftelse på mottagandet; dessutom kräver detta protokoll inte upprättandet av en anslutning mellan källan och mottagaren av information, det vill säga mellan UDP-moduler.

2.3.5. RTP- och RTCP-protokoll

Grundläggande koncept

Realtidstransportprotokoll RTP tillhandahåller realtidsänd-till-ände-överföring av multimediadata som interaktivt ljud och video. Detta protokoll implementerar trafiktypigenkänning, paketsekvensnumrering, tidsstämpling och överföringskontroll.

RTP-protokollets åtgärd reduceras till att tilldela tidsstämplar till varje utgående paket. På mottagningssidan anger paketens tidsstämplar i vilken sekvens och med vilka fördröjningar de ska spelas upp. RTP- och RTCP-stöd tillåter den mottagande noden att ordna mottagna paket i rätt ordning, minska effekten av paketfördröjningsjitter på signalkvaliteten och återställa synkronisering mellan ljud och video så att inkommande information kan lyssnas på och ses korrekt av användare.

Observera att RTP själv inte har någon mekanism för att garantera snabb överföring av data och service kvalitet men använder de underliggande tjänsterna för att tillhandahålla detta. Det förhindrar inte att paketen inte fungerar, men det betyder inte att ryggraden är helt tillförlitlig och skickar paket i rätt ordning. Sekvensnumren som ingår i RTP tillåter mottagaren att rekonstruera sekvensen av avsändarens paket.

RTP 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 av enskilda applikationer och är i de flesta fall integrerad i applikationens drift.

Även om RTP anses vara ett transportlagerprotokoll körs 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 kan användas med andra lämpliga transportprotokoll.

Protokolldatablock RTP / RTCP kallas paket. Paket som genereras i enlighet med RTP-protokollet och används för att överföra multimediadata kallas 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 telefonkonferenser kallas kontrollpaket. Ett RTP-paket innehåller en fast rubrik, en valfri variabel rubrikförlängning 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 göra RTP-protokollet mer flexibelt och kan användas för olika applikationer, görs några av dess parametrar medvetet odefinierade, men det tillhandahåller konceptet med en profil. En profil är en uppsättning parametrar för RTP- och RTCP-protokollen för en specifik klass av applikationer, som bestämmer funktionerna i deras funktion. Profilen definierar: användningen av individuella pakethuvudfält, trafiktyper, rubriktillägg och rubriktillägg, pakettyper, tjänster och kommunikationssäkerhetsalgoritmer, specifikationer för att använda protokollet för det lägre skiktet, etc. Varje applikation fungerar vanligtvis med endast en profil, och profiltypen ställs in genom att välja lämplig applikation. Det finns ingen explicit indikation på profiltypen genom portnummer, protokollidentifierare, etc.

Således bör en fullständig applikationsspecifik RTP-specifikation innehålla ytterligare dokument som inkluderar en profilbeskrivning samt en trafikformatbeskrivning som definierar hur trafik av en viss typ, såsom ljud eller video, kommer att hanteras i RTP.

Gruppljudkonferenser

Multicast-ljudkonferenser kräver en multi-användar multicast-adress och två portar. I det här fallet krävs en port för utbyte av ljuddata, och den andra används för RTCP-kontrollpaket. Multicast-adress och portinformation förs vidare till potentiella deltagare telefonkonferenser... Om sekretess krävs kan information och kontrollpaket krypteras, i så fall måste de också genereras och distribuerad nyckel kryptering.

Ljudkonferensapplikationen som används av varje konferensdeltagare skickar ljuddata i små bitar, till exempel 20 ms. Varje del av ljuddata föregås av ett RTP-huvud; RTP-huvudet och data bildas omväxlande (inkapslade) i ett UDP-paket. RTP-huvudet anger vilken typ av ljudkodning (till exempel PCM, ADPCM eller LPC) som användes för att bilda data i paketet. Detta gör det möjligt att ändra typ av kodning under konferensen, till exempel när en ny deltagare dyker upp som använder en kommunikationslinje med låg bandbredd, eller när nätet är överbelastat.

På Internet, liksom i andra paketkopplade datanätverk, går paket ibland förlorade och ordnas om, och försenas även under olika tider. För att motverka dessa händelser innehåller RTP-huvudet en tidsstämpel och ett sekvensnummer som gör att mottagarna kan synkronisera om till sitt ursprungliga tillstånd så att till exempel delar av ljudsignalen spelas upp av högtalaren kontinuerligt var 20:e ms. Denna synkroniseringsrekonstruktion utförs separat och oberoende för varje källa för RTP-paket i telefonkonferenser... Sekvensnumret kan också användas av mottagaren för att uppskatta antalet förlorade paket.

Sedan deltagarna telefonkonferenser kan gå in och lämna den under konferensen, är det användbart att veta vem som deltar i den för tillfället och hur väl konferensdeltagarna tar emot ljuddata. För detta ändamål utfärdar varje instans av ljudapplikationen under konferensen periodiskt meddelanden på kontrollporten (RTCP-port) för applikationer från alla andra deltagare om att ta emot paket med indikation av 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.

Videokonferenser

Om i telefonkonferenser både ljud- och videosignaler används, de sänds separat. För överföring av varje typ av trafik, oberoende av den andra, introducerar protokollspecifikationen konceptet med en RTP-session. En session identifieras 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-anslutning mellan ljud- och videokommunikationssessioner, förutom att användaren 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 endast ska få ta emot en typ av trafik om de så önskar. Trots separationen kan synkron reproduktion av källmedier (ljud och video) uppnås med hjälp av tidsinformation som bärs i RTCP-paket för båda sessionerna.

Förstå mixers och översättare

Alla webbplatser kan inte alltid ta emot multimediadata i samma format. Överväg ett fall där deltagare från samma plats är anslutna via en låghastighetslinje till de flesta av de andra deltagarna i konferensen som har bredbandsaccess till nätet. Istället för att tvinga alla att använda en smalare bandbredd och ljudkodning av lägre kvalitet, kan en kommunikationsfunktion för RTP-lager som kallas en mixer placeras i ett område med smal bandbredd. Denna mixer synkroniserar om inkommande ljudpaket för att återställa de ursprungliga 20 ms-intervallen, blandar dessa rekonstruerade ljudströmmar till en enda ström, kodar ljudsignalen för en smal 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. Så att korrekt indikation kan tillhandahållas vid de mottagande ändpunkterna källa till meddelanden RTP-huvudet inkluderar ett sätt att identifiera källorna som är involverade i det blandade paketet för blandare.

Vissa av ljudkonferensdeltagarna kan vara anslutna via bredbandslinjer, men kanske inte kan nås via IP-multicast (IPM)-konferenser. Till exempel kan de ligga 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 blandare, utan andra typer av kommunikation på RTP-nivå, så kallade översättare. Av de två översättarna är den ena installerad utanför brandväggen och från utsidan vidarebefordrar alla multicast-paket som tas emot över den säkra anslutningen till den andra översättaren bakom brandväggen. Översättaren bakom brandväggen sänder dem igen som multicast-paket till fleranvändargruppen som är begränsad till webbplatsens interna nätverk.

Blandare och översättare kan utformas för ett antal ändamål. Exempel: En videomixer som skalar videobilder av individer till oberoende videoströmmar och sammansätter dem till en enda videoström, som simulerar en gruppscen.

RTCP kontrollprotokoll

Alla fält av RTP / RTCP-paket sänds över nätverket med 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.

Kontrollprotokoll RTCP (RTCP - Real-Time Control Protocol) är baserat på periodisk paketöverföring förvaltning till alla deltagare i en kommunikationssession med samma distributionsmekanism som RTP. Protokollet med lägre skikt måste tillhandahålla multiplexering av information och kontrollpaket, t.ex olika nummer UDP-portar. RTCP har fyra huvudfunktioner.

1. Huvudfunktionen är att ge feedback för att bedöma kvaliteten på datadistributionen. Det är en inneboende funktion av RTCP som ett transportprotokoll och är associerat med flödeskontroll och öför andra transportprotokoll. Respons kan vara direkt användbar för att hantera adaptiv kodning, men experiment med IP multicasting har visat att mottagarens feedback också är viktig för att diagnostisera spridningsdefekter. Genom att skicka feedbackrapporter om dataintag till alla deltagare kan man observera problem för att utvärdera om de är lokala eller globala. Med IPM-distributionsmekanismen för enheter som leverantörer av nätverkstjänster är det också möjligt att ta emot återkopplingsinformation och fungera som en tredjepartsövervakare för att diagnostisera nätverksproblem. Denna återkopplingsfunktion tillhandahålls av RTCP-sändar- och mottagarrapporter.
2. RTCP upprätthåller en beständig RTP-datakälla-identifierare vid transportskiktet som kallas ett "kanoniskt namn" (CNAME). Eftersom SSRC ID kan ändras om en konflikt upptäcks eller programmet startas om, behöver mottagarna det kanoniska CNAME för att spåra varje bidragsgivare. Mottagare kräver också CNAME för kartlägga uppsättningen information flödar från en given deltagare till flera associerade RTP-sessioner, till exempel vid synkronisering av ljud- och videosignaler.
3. De två första funktionerna kräver att alla peers skickar RTCP-paket, så RTP måste vara hastighetsbegränsande för att möjliggöra peer-to-peer-skalbarhet. När det skickas av varje deltagare telefonkonferenser kontrollpaket till alla andra deltagare, var och en kan självständigt uppskatta det totala antalet deltagare.
4. En fjärde, valfri RTCP-funktion måste tillhandahålla sessionskontrollinformation (t.ex. deltagaridentifiering) som kommer att återspeglas i användargränssnittet. Detta är mest troligt användbart i "löst kontrollerade" sessioner där medlemmar går med och lämnar en grupp utan ägarkontroll eller förhandling.

Funktionerna ett till tre krävs när RTP används i IP multicast och rekommenderas i alla andra fall. RTP-applikationsutvecklare uppmuntras att undvika dubbelriktade mekanismer som inte skalas för att rymma användare.

RTCP-pakethastighet

RTP tillåter en applikation att automatiskt skala representativiteten för en kommunikationssession från ett fåtal deltagare till flera tusen. Till exempel vid ljudkonferenser är datatrafiken i huvudsak självbegränsande eftersom endast en eller två personer kan prata åt gången, och vid gruppdistribution förblir datahastigheten på vilken länk som helst relativt konstant, oavsett antalet deltagare. Ledningstrafiken är dock inte självbegränsande. Om mottagningsrapporterna från varje deltagare skickas i konstant takt, kommer ledningstrafiken att växa linjärt med ökningen av antalet deltagare. Därför måste en speciell mekanism tillhandahållas för att minska överföringsfrekvensen för kontrollpaket.

För varje session antas det att datatrafiken uppfyller en aggregerad gräns, kallad sessionens bandbredd, som delas av alla deltagare. Denna bandbredd kan reserveras och begränsas av nätverket. Sessionsbandbredden är oberoende av mediakodningstypen, men valet av kodningstyp kan begränsas av kommunikationssessionens bandbredd. Sessionsbandbreddsparametern förväntas tillhandahållas av sessionshanteringsapplikationen när den anropar mediaapplikationen, men mediaapplikationerna kan också ställa in en standard baserat på ensändarens databandbredd för den kodningstyp som valts för sessionen.

Bandbreddsberäkningar för kontroll och datatrafik baseras på de underliggande transport- och nätverkslagerprotokollen (som UDP och IP). Data Link Layer (DLC)-rubriker tas inte med i beräkningarna, eftersom ett paket kan vara inkapslat med olika RPC-nivåhuvuden när det sänds.

Kontrolltrafiken bör begränsas till en liten och känd del av sessionens bandbredd: tillräckligt liten så att transportprotokollets huvudfunktion - dataöverföring - inte påverkas; känd så att hanteringstrafik kan inkluderas i bandbreddsspecifikationen som ges till protokollet resursreservation, och så att varje deltagare självständigt kan beräkna sin andel. Det antas att den del av sessionsbandbredden som allokeras till RTCP bör sättas till 5 %. Alla sessionsdeltagare MÅSTE använda samma mängd RTCP-bandbredd så att det beräknade kontrollpaketintervallet är detsamma. Därför måste dessa konstanter ställas in för varje profil.

Algoritmen för att beräkna intervallet mellan att skicka sammansatta RTCP-paket för att dela bandbredden som allokerats för kontrolltrafik mellan deltagarna har följande huvudegenskaper:

• avsändare delar minst 1/4 av bandbredden för kontrolltrafik som i sessioner med stor mängd mottagare, men med ett litet antal avsändare; så snart anslutningen upprättats, mottar deltagarna CNAME för de sändande platserna inom en kort tidsperiod;
• Det krävs att det uppskattade intervallet mellan RTCP-paket är minst 5 sekunder för att undvika skurar av RTCP-paket som överskrider den tillåtna bandbredden när antalet deltagare är litet och trafiken inte utjämnas enligt lagen om stora siffror;
• intervallet mellan RTCP-paket varierar slumpmässigt mellan ett halvt och ett och ett halvt beräknade intervall för att undvika oavsiktlig synkronisering av alla deltagare. Det första RTCP-paketet som skickas efter att ha gått med i en session försenas också slumpmässigt (upp till hälften av det minsta RTCP-intervallet) om en applikation startas på flera platser samtidigt, till exempel när man tillkännager starten av en session;
• för att automatiskt anpassa sig till förändringar i mängden sänd styrinformation, beräknas en dynamisk uppskattning av medelstorleken för det sammansatta RTCP-paketet med användning av alla mottagna och skickade paket;
• denna algoritm kan användas för sessioner där paketöverföring är giltig för alla deltagare. I det här fallet är sessionsbandbreddsparametern produkten av den individuella avsändarens bandbredd med antalet deltagare, och RTP-bandbredden förlitar sig på det underliggande protokollet för att ge en indikation på längden. Den maximala längden på RTP-paket begränsas endast av de underliggande protokollen.

  Flera RTP-paket kan bäras i en enda lägre lagerprotokolldataenhet, såsom ett UDP-paket. Detta minskar redundansen för rubriker och förenklar synkroniseringen mellan olika strömmar.

Internets snabba tillväxt ställer nya krav på dataöverföringens hastighet och volym. Att enbart öka nätverkskapaciteten är inte tillräckligt för att tillgodose alla dessa krav, det krävs smarta och effektiva metoder för hantering av trafik och trafikstockningar.

I realtidsapplikationer genererar avsändaren en dataström med konstant hastighet, och mottagaren (eller mottagarna) måste tillhandahålla denna data till applikationen i samma takt. Sådana applikationer inkluderar till exempel ljud- och videokonferenser, livevideo, fjärrdiagnostik inom medicin, datortelefoni, distribuerad interaktiv simulering, spel, realtidsövervakning etc.

Det mest använda transportprotokollet är TCP. Även om TCP kan stödja en mängd olika distribuerade applikationer, är det inte lämpligt för realtidsapplikationer.

Det nya transportprotokollet i realtid är utformat för att lösa detta problem - RTP(Real-Time Transport Protocol), som garanterar leverans av data till en eller flera destinationer med en fördröjning inom specificerade gränser, det vill säga att data kan spelas upp i realtid.

Principer för att bygga RTP-protokollet

RTP stöder inte någon form av paketleverans, överföringsfidelitet eller anslutningssäkerhetsmekanismer. Alla dessa funktioner är tilldelade transportprotokollet. RTP körs ovanpå UDP och kan stödja dataöverföring i realtid mellan flera deltagare i en RTP-session.

Notera

För varje RTP-deltagare bestäms en session av ett par pa(en nätverksadress - IP och ett par portar: RTP och RTCP).

RTP-paket innehåller följande fält: avsändaridentifierare som anger vem av deltagarna som genererar data, tidsstämplar när paketet genererades så att data kan spelas upp av den mottagande sidan med korrekta intervall, information om överföringsordningen samt information om typen av paketinnehåll, till exempel om typ av videokodning (MPEG, Indeo, etc.). Närvaron av sådan information gör det möjligt att uppskatta värdet av den initiala fördröjningen och storleken på överföringsbufferten.

Notera

I en typisk realtidsmiljö genererar avsändaren paket med en konstant hastighet. De skickas med jämna mellanrum, passerar nätverket och tas emot av mottagaren, som spelar upp data i realtid vid mottagandet. På grund av förändringar i fördröjningen av överföringen av paket över nätverket kan de emellertid komma fram med oregelbundna intervall. För att kompensera för denna effekt buffras inkommande paket, hålls vid ett tag och tillhandahålls sedan med en konstant hastighet. programvara genererar output. För att realtidsprotokollet ska fungera måste därför varje paket innehålla en tidsstämpel så att mottagaren kan reproducera inkommande data i samma takt som avsändaren.

Eftersom RTP definierar (och reglerar) formatet för nyttolasten för de överförda data, är begreppet synkronisering direkt relaterat till detta, för vilket RTP-översättningsmotorn är delvis ansvarig - mixern. Mixern tar emot strömmar av RTP-paket från en eller flera källor och kombinerar dem och skickar en ny ström av RTP-paket till en eller flera mottagare. Mixern kan enkelt kombinera data samt ändra dess format, till exempel när du kombinerar flera ljudkällor. Anta att det nya systemet vill delta i sessionen, men dess kanal till nätverket inte har tillräcklig kapacitet för att stödja alla RTP-strömmar, då tar mixern emot alla dessa strömmar, kombinerar dem till en och överför den sista till den nya medlemmen av sessionen. När du tar emot flera strömmar lägger mixern helt enkelt till PCM-värdena. RTP-huvudet som genereras av mixern inkluderar identifieraren för avsändaren vars data finns i paketet.

En enklare enhet, en översättare, skapar ett utgående RTP-paket för varje inkommande RTP-paket. Denna mekanism kan ändra formatet på data i paketet eller använda en annan uppsättning lågnivåprotokoll för att överföra data från en domän till en annan. Till exempel kanske en potentiell mottagare inte kan bearbeta höghastighetsvideo som används av andra deltagare i sessionen. Översättaren konverterar videon till ett format av lägre kvalitet som kräver en lägre bithastighet.

Arbetskontrollmetoder

RTP används endast för att överföra användardata – vanligtvis multicast – till alla deltagare i sessionen. Tillsammans med RTP fungerar RTCP-protokollet (Real-time Transport Control Protocol) vars huvuduppgift är att ge kontroll över RTP-överföringen. RTCP använder samma underliggande transportprotokoll som RTP (vanligtvis UDP), men ett annat portnummer.

RTCP har flera funktioner:

1. Tillhandahålla och övervaka kvaliteten på tjänsterna och feedback vid överbelastning. Eftersom RTCP-paket är multicast-paket kan alla deltagare i sessionen uppskatta hur bra de andra deltagarna presterar och tar emot. Avsändarmeddelanden låter mottagarna mäta datahastighet och överföringskvalitet. Mottagarnas meddelanden innehåller information om problem de stöter på, inklusive paketförlust och överdrivet jitter. Feedback från mottagarna är också viktigt för att diagnostisera distributionsfel. Genom att analysera meddelanden från alla deltagare i sessionen kan nätverksadministratören avgöra om ett givet problem berör en deltagare eller är av allmän karaktär. Om den sändande applikationen drar slutsatsen att problemet är karakteristiskt för systemet som helhet, till exempel på grund av ett fel i en av kommunikationskanalerna, kan det öka datakomprimeringsförhållandet genom att minska kvaliteten eller till och med vägra att överföra video - detta gör att data kan överföras över anslutningen med låg kapacitet.
2. Avsändaridentifikation. RTCP-paket innehåller en standardtextbeskrivning av avsändaren. De ger mer information om upphovsmannen till datapaket än ett slumpmässigt valt synkkälla-ID. Dessutom hjälper de användaren att identifiera strömmar från olika sessioner.
3. Uppskattning av sessionsstorlek och skalning. För att säkerställa kvaliteten på tjänsten och feedback för att hantera trafikstockningar, samt för att identifiera avsändaren, skickar alla deltagare med jämna mellanrum RTCP-paket. Sändningsfrekvensen för dessa paket minskar när antalet deltagare ökar. Med ett litet antal deltagare skickas ett RTCP-paket som mest var 5:e sekund. RFC-1889 beskriver en algoritm där deltagare begränsar frekvensen av RTCP-paket baserat på det totala antalet deltagare. Målet är att RTCP-trafiken inte ska överstiga 5 % av den totala sessionstrafiken.

RTP-huvudformat

RTP är ett strömorienterat protokoll. RTP-pakethuvudet skapades med behoven av realtidsöverföring i åtanke. Den innehåller information om paketens ordningsföljd så att dataströmmen är korrekt sammansatt i den mottagande änden, och en tidsstämpel för korrekt frame interleaving under uppspelning och för synkronisering av flera dataströmmar, såsom video och ljud.

Varje RTP-paket har en huvudrubrik samt eventuellt ytterligare applikationsspecifika fält.

Att använda TCP som transportprotokoll för dessa applikationer är inte möjligt av flera anledningar:

1. Detta protokoll tillåter endast en anslutning mellan två slutpunkter, därför är det inte lämpligt för multicast-överföring.
2. TCP möjliggör återsändning av förlorade segment som anländer när realtidsapplikationen inte längre väntar på dem.
3. TCP har ingen bekväm mekanism för att binda tidsinformation till segment – ​​ett ytterligare krav för realtidsapplikationer.

Ett annat allmänt använt transportlagerprotokoll, LJDP, har inte några av begränsningarna för TCP, men det ger inte heller kritisk tidsinformation.

Även om varje realtidsapplikation kan ha sina egna mekanismer för att stödja realtidsöverföring, har de många likheter, vilket gör det mycket önskvärt att definiera ett enda protokoll.

Denna uppgift är avsedd att lösa det nya realtidstransportprotokollet - RTP (Real-time Transport Protocol), som garanterar leverans av data till en eller flera mottagare med en fördröjning inom specificerade gränser, dvs. data kan spelas upp i realtid.

I fig. 1 visar en fast RTP-rubrik som innehåller ett antal fält som identifierar element såsom paketformat, sekvensnummer, källor, gränser och nyttolasttyp. Den fasta rubriken kan följas av andra fält som innehåller ytterligare information om data.

0

2

3

4

8

16

31

Synkroniseringskälla (SSRC) Identifierare
Identifierare för bidragande källa (CSRC).

Ris. 1. Fast RTP-huvud.

V(2 bitar). Versionsfält. Den nuvarande versionen är den andra.
R(1 bit). Fyll i fältet. Detta fält signalerar närvaron av utfyllnadsoktetter i slutet av nyttolasten. Utfyllnad används när applikationen kräver att nyttolasten är en multipel av till exempel 32 bitar. I det här fallet indikerar den sista oktetten antalet utfyllnadsoktetter.
NS(1 bit). Rubrikförlängningsfält. När detta fält är specificerat följer en annan valfri rubrik huvudrubriken som används i experimentella RTP-tillägg.
SS(4 bitar). Fält för antal avsändare. Detta fält innehåller antalet identifierare för de avsändare vars data finns i paketet, med själva identifierarna efter huvudhuvudet.
M(1 bit). Markeringsfält. Betydelsen av markörbiten beror på typen av nyttolast. Markörbiten används vanligtvis för att indikera gränserna för dataströmmen. När det gäller video anger den slutet på bilden. När det gäller en röst, anger den början av talet efter en period av tystnad.
RT(7 bitar). Fält för nyttolasttyp. Det här fältet identifierar nyttolasttypen och dataformatet, inklusive komprimering och kryptering. I ett stabilt tillstånd använder avsändaren endast en nyttolasttyp per session, men den kan ändra den som svar på ändrade förhållanden om det signaleras av Real-Time Transport Control Protocol.
Sekvensnummer(16 bitar). Fält för sekvensnummer. Varje källa börjar numrera paket med ett slumpmässigt nummer, och sedan ökas med ett för varje skickat RTP-datapaket. Detta gör att du kan upptäcka paketförlust och bestämma ordningen på paket med samma tidsstämpel. Flera på varandra följande paket kan ha samma tidsstämpel om de genereras logiskt i samma ögonblick, såsom paket som hör till samma videobildruta.
Tidsstämpel(32 bitar). Tidsstämpelfält. Detta fält innehåller den tidpunkt då den första oktetten av nyttolastdata genererades. De enheter som tiden anges i detta fält beror på typen av nyttolast. Värdet bestäms av avsändarens lokala klocka.
Synkroniseringskälla (SSRC) Identifierare(32 bitar). Synkroniseringskällidentifieringsfält: Ett slumpmässigt genererat nummer som unikt identifierar källan under sessionen och är oberoende av nätverksadressen. Detta nummer spelar en viktig roll i behandlingen av den inkommande delen av data från en källa.
Identifierare för bidragande källa (CSRC).(32 bitar). Lista över källidentifieringsfält, "blandade" i huvudströmmen, till exempel med hjälp av en mixer. Mixern infogar en hel lista med SSRC-käll-ID:n som var involverade i konstruktionen av detta RTP-paket. Denna lista kallas CSRC. Antalet objekt i listan: från 0 till 15. Om antalet deltagare är fler än 15 väljs de första 15. Ett exempel är en ljudkonferens, där RTP-paket samlas in tal från alla deltagare, var och en med sina egen SSRC - de bildar CSRC-listan. Dessutom har hela konferensen en gemensam SSRC.

RTCP-protokollet är, precis som vilket kontrollprotokoll som helst, mycket mer komplext både i struktur och i de funktioner det utför (jämför t.ex. IP och TCP). Även om RTCP är baserat på RTP, innehåller det många ytterligare fält som den använder för att implementera sina funktioner.

Resursreservationsprotokoll - OSA

Resource Reservation Protocol (RSVP), som för närvarande övervägs av Internet Engineering Task Force (IETF), tar upp den prioriterade frågan för latenskänslig data, i motsats till traditionell data där latens är mindre kritisk. RSVP tillåter slutsystem att reservera nätverksresurser för att erhålla den erforderliga kvaliteten på tjänsten, särskilt resurser för realtidstrafik via RTP. RSVP handlar främst om routrar, även om applikationer vid ändpunkterna också behöver veta hur man använder RSVP för att reservera den nödvändiga bandbredden för en given klass av tjänst eller prioritetsnivå.

RTP, tillsammans med andra beskrivna standarder, tillåter dig att framgångsrikt överföra video och ljud över konventionella IP-nätverk. RTP / RTCP / RSVP är en standardiserad lösning för datanätverk i realtid. Dess enda nackdel är att den endast är avsedd för IP-nätverk. Denna begränsning är dock tillfällig: nätverk kommer på något sätt att utvecklas i denna riktning. Denna lösning lovar att lösa problemet med att överföra fördröjningskänsliga data över Internet.

Litteratur

En beskrivning av RTP-protokollet finns i RFC-1889.

RTP och RTCP i VoIP

RTP är det huvudsakliga transportprotokollet i IP-telefoninätverk. RTP (Real Time Protocol) är ett realtidsprotokoll som skapades för överföring av multimedia (ljud, video), kodad och packad i paket, information över IP-nätverk i strikta tidsramar. RTP-segment sänds över UDP respektive IP på olika nivåer av OSI-modellen. Användningen av UDP, som inte garanterar leverans, är förknippad med den strikta timingen av mediaöverföring i realtid och TCP:s oförmåga att fungera i realtid. Därför, trots förlusten av en del av datan, är leveranstiden viktigare i detta fall.
V allmän syn fördelningen av protokollet över lagren i OSI-modellen är som följer:
Transportlager: RTP över UDP
Nätverk: IP
Kanal: Ethernet
Fysiskt: Ethernet
Vid överföring av multimediainformation med RTP-protokollet används följande inkapsling:

Minsta RTP-segmentstorlek är 12 byte. De två första bitarna definierar protokollversionen. Idag används RTPv.2. Nästa P-fält är också 2 bitar långt och indikerar närvaron av utfyllnadstecken i datafältet när segment av samma längd används. X-fältet avgör om den utökade rubriken används. 4-bitars CC-fältet definierar sedan antalet CSRC-fält i slutet av RTP-huvudet, dvs antalet källor som bildar strömmen. Sedan kommer M-fältet - en markörbit som används för att markera viktig data. Nästa PT-fält är 7 bitar långt. Designad för att bestämma typen av nyttolast - de data som krävs för applikationen. Med den angivna koden bestämmer applikationen typen av multimediainformation och avkodningsmetoden.
Resten av rubriken består av ett SequenceNumber-fält - segmentets sekvensnummer, som håller reda på paketens ordning och deras förlust; Tidstämpelfält - synkroniseringskod som indikerar tiden för det första kodade provet i nyttolasten, detta märke används av synkroniseringsåterställningsbuffertarna för att eliminera kvalitetsförluster orsakade av fördröjningsvariationer; SSRC-synkroniseringskällfält är ett godtyckligt nummer som särskiljer en RTP-session från en annan för att skapa multiplexeringsmöjligheter. Efter den permanenta fasta delen av RTP-huvudet kan upp till 15 trettiotvåbitars CSRC-fält läggas till som identifierar datakällorna.
Låt oss beskriva proceduren för att upprätta en RTP-session. Protokollet fastställde den trafiken olika typer sänds i separata kommunikationssessioner. För att upprätta en session är det nödvändigt att definiera ett par destinationstransportadresser, dvs. en nätverksadress och två portar för RTP och RTCP. Så för en videokonferens är det nödvändigt att överföra ljud och video i olika sessioner med motsvarande olika destinationsportar. Att överföra olika typer av trafik med interleaving i samma session kan orsaka följande problem:
- när du ändrar en av trafiktyperna är det omöjligt att avgöra vilken parameter i sessionen som behöver ersättas med ett nytt värde;
- endast ett tidsintervall används för att upprätta en session, och vid överföring av heterogen trafik kommer varje typ att ha sitt eget intervall, och de kommer att vara olika;
- RTP-mixer kan inte kombinera interfolierade strömmar av olika trafiktyper till en ström;
- överföring av flera typer av trafik i en RTP-session är omöjlig av följande skäl: användning av olika nätverksvägar eller distribution av nätverksresurser; ta emot en delmängd av multimediadata när så krävs, till exempel endast ljud om videosignalen har överskridit den tillgängliga bandbredden; mottagarimplementationer som använder separata processer för olika typer av trafik, medan användning av separata RTP-sessioner möjliggör enstaka eller flera processimplementeringar.

RTP (Real-time Transport Protocol) och UDP (User Datagram Protocol) garanterar dock inte kvalitet, det vill säga de fungerar inte med QoS (Quality of Service). Därför stöds RTP av RTCP (Real-Time Transport Control Protocol), som ger ytterligare information om tillståndet för en RTP-session.
RTCP har fyra huvudfunktioner:
I. Huvudsyftet med RTCP-protokollet är att ge feedback för att säkerställa kvaliteten på dataöverföringen. Feedback kan vara direkt användbar i applikationer för adaptiv kodningsöverföring. När du använder IP-multicast är det också extremt viktigt för mottagare att diagnostisera fel i överföringen av meddelanden (paket). Genom att skicka meddelanden med mottagningsrapporter kan den sändande parten fastställa orsaken till den misslyckade meddelandeöverföringen, om någon.
II. RTCP innehåller en oföränderlig transportlageridentifierare för käll-RTP, som kallas kanoniskt namn eller kanoniskt namn. Eftersom SSRC-identifieraren kan ändras i händelse av kollisioner (kollisioner), behöver mottagaren Cname-värdet för att spåra var och en av deltagarna. Mottagaren använder också Cname för att matcha många dataströmmar från en deltagare vid upprättande av flera sessioner samtidigt, till exempel för att synkronisera ljud- och videokanaler vid överföring av video med ljud.
III. Ovanstående två funktioner förutsätter att alla sessionsdeltagare skickar RTCP-paket, så överföringshastigheten måste kontrolleras för att RTP ska kunna etablera sessioner med ett stort antal användare. När varje deltagare skickar sina kontrollpaket till alla andra kan vilken partner som helst självständigt bestämma det totala antalet deltagare i sessionen. Detta är nödvändigt för att beräkna överföringshastigheten för RTCP-meddelanden.
IV. Denna funktion tjänar till att förmedla minsta nödvändiga kontrollinformation, såsom deltagar-ID, som används av det grafiska användargränssnittet. Den här funktionen används för löst kontrollerade sessioner där användare går in och ut utan ordentlig förhandling av parametrar och egenskaper. RTCP fungerar som en bekväm kanal för kontakt med alla deltagare, men den stöder inte nödvändigtvis alla kommunikationskrav för en applikation.
I IP-nätverk som använder multicast är funktion ett, två och tre obligatoriska vid användning av RTP-sessioner. Det rekommenderas också att använda dem vid överföring i andra nätverk och miljöer. Idag rekommenderas det att utvecklare av RTP-applikationer använder verktyg som tillåter att arbeta i ett multicast-läge, och inte bara i ett unikt.
Låt oss ta en titt på RTCP-paketformatet.
Protokollstandarden definierar flera typer av RTCP-paket. RTCP är designat för att överföra tjänstinformation:
sr: Avsändarrapport. Det är nödvändigt för statistik över mottagning och överföring av sessionsdeltagare som är direkt aktiva avsändare;
rr: Mottagarrapport. Krävs för statistik från deltagare som inte är mottagare;
sdes: Beskriver källan, inkluderar Cname;
hejdå: tjänar till att indikera slutet (avslutet) av sessionen;
app: Applikationsspecifika funktioner;
Varje RTCP-paket består av en konstant del, som för RTP-protokollet, som används av RTP-paket, följt av fält som kan variera i längd beroende på typ av paket, men multiplar på 32 bitar. Justeringskraven och längdfältet i den fasta delen av rubriken introduceras för att göra RTCP-paket sammanlänkade. Flera RTCP-paket kan sammanfogas med varandra utan att införa några separatorer för att erhålla ett sammansatt RTCP-paket som skickas över ett låglagers transportprotokoll såsom UDP. Det finns ingen specifik räknare för individuella RTCP-paket, eftersom låglagerprotokollet kommer att ställa in den totala längden och bestämma slutet av det sammansatta paketet.


Formatet för RTCP-paketet för avsändarmeddelandet är som följer, som visas i figuren ovan.

RTCP-paket är föremål för följande valideringskontroller.
- RTP-versionsfältet måste vara lika med 2.
- Datatypfältet för det första RTCP-paketet i ett sammansatt paket ska vara SR eller RR.
- Fyllnadsbiten (P) måste vara noll för det första paketet i ett sammansatt RTCP-paket, eftersom fyllmedlet endast kan finnas i det sista.
- Längden på de individuella RTCP-paketfälten måste läggas till den totala längden på det sammansatta paketet.

Om du en dag snabbt måste ta reda på vad VoIP (voice over IP) är och vad alla dessa vilda förkortningar betyder, hoppas jag att denna handledning kommer att hjälpa. Jag noterar direkt att frågorna om att konfigurera ytterligare typer av telefonitjänster (såsom samtalsöverföring, röstbrevlåda, konferenssamtal etc.) inte beaktas här.

Så, vad vi kommer att ta itu med under skärningen:

1. Grundläggande koncept telefoni: typer av enheter, anslutningsdiagram
2. SIP / SDP / RTP-protokollpaket: hur det fungerar
3. Hur information om nedtryckta knappar överförs
4. Hur röst och fax sänds
5. Digital signalbehandling och ljudkvalitetssäkring inom IP-telefoni

1. Grundläggande begrepp för telefoni

I allmänhet är schemat för att ansluta en lokal abonnent till en telefonleverantör via en vanlig telefonlinje som följer:

En telefonmodul med en FXS-port (Foreign eXchange Subscriber) är installerad på leverantörens sida (PBX). Hemma eller på kontoret installeras en telefon eller fax med en FXO-port (Foreign eXchange Office) och en uppringningsmodul.

Förbi utseende FXS- och FXO-portarna skiljer sig inte åt på något sätt, dessa är vanliga 6-poliga RJ11-kontakter. Men med hjälp av en voltmeter är det väldigt lätt att skilja dem åt - det kommer alltid att finnas någon spänning på FXS-porten: 48/60 V när luren är på eller 6-15 V under ett samtal. På FXO, om den inte är ansluten till linje, är spänningen alltid 0.

För att överföra data över en telefonlinje på leverantörssidan behövs ytterligare logik, som kan implementeras på SLIC-modulen (subscriber line interface circuit) och på abonnentsidan - med hjälp av DAA-modulen (Direct Access Arrangement).

Nuförtiden är trådlösa DECT-telefoner (Digital European Cordless Telecommunications) ganska populära. Designmässigt liknar de vanliga telefoner: de har också en FXO-port och en uppringningsmodul, men en modul har också lagts till trådlös stationer och telefoner på 1,9 GHz.

Abonnenter är anslutna till PSTN-nätet (Public Switched Telephone Network) - ett publikt telefonnät, även känt som PSTN, PSTN. PSTN-nätverket kan organiseras med hjälp av olika tekniker: ISDN, optik, POTS, Ethernet. Ett specialfall av PSTN, när du använder en vanlig analog / kopparlinje - POTS (Plain Old Telephone Service) - ett enkelt gammalt telefonsystem.

Med utvecklingen av Internet telefonkommunikation bytte till ny nivå... Fasta telefoner används allt mindre, främst för affärsbehov. DECT-telefoner är lite bekvämare, men begränsas av husets omkrets. GSM-telefoner är ännu bekvämare, men de är begränsade inom landet (roaming är dyrt). Men för IP-telefoner är de också softphones (SoftPhone), det finns inga begränsningar, förutom tillgången till Internet.

Skype är det mest kända exemplet på en softphone. Det kan göra många saker, men det har två viktiga nackdelar: sluten arkitektur och avlyssning är känt av vilka myndigheter. På grund av den första finns det inget sätt att skapa ditt eget telefonmikronätverk. Och på grund av det andra är det inte särskilt trevligt att bli spionerad på, särskilt under personliga och kommersiella samtal.

Som tur är finns det öppna protokoll för att skapa egna kommunikationsnätverk med godsaker – det är SIP och H.323. Det finns något fler softphones baserade på SIP-protokoll än på H.323, vilket kan förklaras av dess relativa enkelhet och flexibilitet. Men ibland kan denna flexibilitet passa stora pinnar i hjulen. Både SIP och H.323 använder RTP-protokollet för att överföra media.

Låt oss överväga de grundläggande principerna för SIP-protokollet för att förstå hur två abonnenter är anslutna.

2. Beskrivning av ett paket med SIP/SDP/RTP-protokoll

SIP (Session Initiation Protocol) är ett protokoll för att upprätta en session (inte bara en telefon) Det är ett textbaserat protokoll över UDP. Det är också möjligt att använda SIP över TCP, men det är sällsynta fall.

SDP (Session Description Protocol) är ett protokoll för att förhandla om typen av överförd data (för ljud och video är dessa codecs och deras format, för fax - överföringshastighet och felkorrigering) och deras destinationsadresser (IP och port). Det är också ett textbaserat protokoll. SDP-parametrar sänds i kroppen av SIP-paket.

RTP (Real-time Transport Protocol) är ett dataöverföringsprotokoll för ljud/video. Det är ett binärt protokoll över UDP.

Allmän struktur för SIP-paket:

• Start-Line: ett fält som indikerar SIP-metoden (kommando) när den efterfrågas eller resultatet av exekvering av en SIP-metod när du svarar.
• Rubriker: ytterligare information till startlinjen, formaterad som rader som innehåller ATTRIBUTE: VALUE-par.
• Bröd: binär eller textdata. Används vanligtvis för att överföra SDP-parametrar eller meddelanden.

Här är ett exempel på två SIP-paket för en vanlig procedur - samtalsinställningar:

Till vänster är innehållet i SIP INVITE-paketet, till höger - svaret på det - SIP 200 OK.

Huvudfälten är markerade med ramar:

• Metod / Request-URI innehåller SIP-metod och URI. I exemplet upprättas en session - INVITE-metoden, ett samtal till abonnenten [e-postskyddad]
• Status-Code - svarskod till föregående SIP-kommando. I det här exemplet slutfördes kommandot framgångsrikt - kod 200, dvs. abonnent 555 lyfte telefonen.
• Via - adressen där abonnenten 777 väntar på svar. För ett 200 OK-meddelande kopieras detta fält från BJUDANDE-meddelandet.
• Från / Till - Visningsnamnet och adressen till avsändaren och mottagaren av meddelandet. För ett 200 OK-meddelande kopieras detta fält från BJUDANDE-meddelandet.
• Cseq innehåller kommandots sekvensnummer och namnet på metoden som det tillhör det här meddelandet... För ett 200 OK-meddelande kopieras detta fält från BJUDANDE-meddelandet.
• Content-Type är den typ av data som överförs i Body-blocket, i detta fall SDP-data.
• Anslutningsinformation - IP-adress till vilken den andra abonnenten behöver skicka RTP-paket (eller UDPTL-paket vid faxöverföring över T.38).
• Mediabeskrivning - porten till vilken den andra abonnenten ska överföra de angivna uppgifterna. I det här fallet är detta ljud (ljud RTP / AVP) och en lista över datatyper som stöds - PCMU, PCMA, GSM-codecs och DTMF-signaler.

Ett SDP-meddelande består av rader som innehåller FIELD = VALUE-par. Av huvudfälten kan du notera:

• o- Ursprung, namnet på sessionsarrangören och sessions-ID.
• med- Anslutningsinformation, fält som beskrivits tidigare.
• m- Mediebeskrivning, fält som beskrivits tidigare.
• a- Medieattribut, ange formatet för de överförda data. Ange till exempel ljudets riktning - mottagning eller sändning (sendrecv), för codecs ange samplingshastigheten och referensnumret (rtpmap).

RTP-paket innehåller ljud-/videodata kodade i ett specifikt format. Detta format anges i fältet PT (nyttolasttyp). Värdekorrespondenstabell av detta fält specifikt format, se https: // wikipedia org wiki RTP-ljudvideoprofil.

RTP-paket innehåller också en unik SSRC-identifierare (definierar källan till RTP-strömmen) och en tidsstämpel (tidsstämpel, används för enhetlig uppspelning av ljud eller video).

Ett exempel på interaktion mellan två SIP-abonnenter via en SIP-server (Asterisk):

Så snart SIP-telefonen startar, skickar det första som den registrerar på fjärrservern (SIP Registar), ett SIP REGISTER-meddelande.

När en abonnent anropas skickas ett SIP INVITE-meddelande, vars brödtext innehåller ett SDP-meddelande, som anger parametrarna för audio/videoöverföring (vilka codecs som stöds, till vilken IP och port som ljud ska skickas, etc.).

När fjärrabonnenten lyfter luren får vi ett SIP 200 OK meddelande också med SDP-parametrar, endast fjärrabonnenten. Med hjälp av de skickade och mottagna SDP-parametrarna kan du upprätta en RTP-ljud-/videoöverföringssession eller en T.38-faxöverföringssession.

Om de mottagna SDP-parametrarna inte passade oss, eller den mellanliggande SIP-servern beslutade att inte skicka RTP-trafik genom sig själv, så utförs SDP-omförhandlingsproceduren, den så kallade REINVITE. Förresten, det är just på grund av denna procedur som gratis SIP-proxyservrar har en nackdel - om båda abonnenterna är i samma lokala nätverk och proxyservern ligger bakom NAT, kommer ingen av abonnenterna att höra efter omdirigering av RTP-trafik annan.

Efter avslutat samtal skickar abonnenten som lägger på luren ett SIP BYE-meddelande.

3. Överföring av information om nedtryckta knappar

Ibland efter att ha upprättat en session, under en konversation, behöver du tillgång till ytterligare typer av tjänster (ADO) - parkera samtal, överföring, röstbrevlåda, etc. - som reagerar på vissa kombinationer av nedtryckta knappar.

Så på en vanlig telefonlinje finns det två sätt att slå ett nummer:

• Pulse - historiskt sett den första, användes främst i telefoner med roterande uppringare. Uppringning sker på grund av sekventiell stängning och öppning av telefonlinjen enligt den slagna siffran.
• Ton - ringa ett nummer med DTMF-koder (Dual-Tone Multi-Frequency) - varje telefonknapp har sin egen kombination av två sinusformade signaler (toner). Genom att exekvera Goertzels algoritm är det ganska enkelt att avgöra vilken knapp som är nedtryckt.

Under ett samtal är pulsmetoden obekväm för att sända den nedtryckta knappen. Så det tar ungefär 1 sekund att sända "0" (10 pulser på 100 ms: 60 ms - linjebrytning, 40 ms - linjestängning) plus 200 ms för en paus mellan siffrorna. Dessutom kommer karakteristiska klick ofta att höras under pulsuppringning. Därför används i vanlig telefoni endast tonläget för åtkomst till VAS.

I VoIP-telefoni kan information om nedtryckta knappar överföras på tre sätt:

1. DTMF Inband - generering av en ljudton och dess överföring inom ljuddata (aktuell RTP-kanal) - detta är en normal tonuppringning.
2. RFC2833 - en speciell RTP-pakettelefonhändelse genereras, som innehåller information om nedtryckt tangent, volym och varaktighet. Numret på RTP-formatet i vilket DTMF RFC2833-paket kommer att sändas anges i huvuddelen av SDP-meddelandet. Till exempel: a = rtpmap: 98 telefonhändelse / 8000.
3. SIP INFO - ett SIP INFO-paket bildas med information om nedtryckt tangent, volym och varaktighet.

DTMF-överföring inom ljuddata (Inband) har flera nackdelar - dessa är overheadresurser vid generering/inbäddning av toner och under deras upptäckt, begränsningar av vissa codecs som kan förvränga DTMF-koder och dålig tillförlitlighet under överföring (om några av paketen går förlorade, då kan detektering ske vid dubbeltryckning av samma tangent).

Huvudskillnaden mellan DTMF RFC2833 och SIP INFO: om SIP-proxyservern möjliggör RTP-överföring direkt mellan abonnenter som går förbi själva servern (till exempel canreinvite = ja i asterisk), så kommer servern inte att märka RFC2833-paket, som ett resultat av vilket de blir otillgängliga tjänster FEB. SIP-paket överförs alltid via SIP-proxyservrar, så VAS kommer alltid att fungera.

4. Röst- och faxöverföring

Som redan nämnts används RTP-protokollet för att överföra mediadata. RTP-paket anger alltid formatet för den överförda datan (codec).

Det finns många olika codecs för röstöverföring, med olika bithastighet/kvalitet/komplexitetsförhållanden, det finns öppna och stängda. Alla mjukvarutelefoner har definitivt stöd för G.711 alaw / ulaw codecs, deras implementering är mycket enkel, ljudkvaliteten är inte dålig, men de kräver en bandbredd på 64 kbps. Till exempel kräver G.729 codec bara 8 kbps, men den är väldigt processorkrävande, och dessutom är den inte gratis.

För faxöverföring används vanligtvis antingen G.711-codec eller T.38-protokollet. G.711 faxöverföring är samma som T.30 faxöverföring, som om faxet skickades över en vanlig telefonlinje, men samtidigt analog signal från raden är digitaliserad enligt alaw / ulaw-lagen. Detta kallas även Inband T.30 faxöverföring.

T.30-fax förhandlar om sina parametrar: överföringshastighet, datagramstorlek, felkorrigeringstyp. T.38-protokollet är baserat på T.30-protokollet, men till skillnad från Inband-överföring analyseras de genererade och mottagna T.30-kommandona. På detta sätt överförs inte rådata, utan igenkända faxkontrollkommandon.

För att överföra T.38-kommandon används UDPTL-protokollet, det är ett UDP-baserat protokoll, det används endast för T.38. För att överföra T.38-kommandon kan du fortfarande använda TCP- och RTP-protokollen, men de används mycket mindre ofta.

De främsta fördelarna med T.38 är minskad nätverksbelastning och större tillförlitlighet jämfört med Inband faxöverföring.

Proceduren för att skicka ett fax i T.38-läge är som följer:

1. En vanlig röstanslutning upprättas med valfri codec.
2. När papper har laddats i det sändande faxet sänder det med jämna mellanrum en T.30 CNG (Calling Tone)-signal för att indikera att det är redo att skicka faxet.
3. På mottagningssidan genereras en T.30 CED-signal (Called Terminal Identification) - detta är beredskapen att ta emot ett fax. Denna signal skickas antingen efter att du trycker på knappen "Ta emot fax", eller så gör faxet det automatiskt.
4. På sändningssidan detekteras CED-signalen och SIP REINVITE-proceduren inträffar, och T.38-typen indikeras i SDP-meddelandet: m = bild 39164 udptl t38.

Det är önskvärt att sända fax över Internet i T.38. Om faxet behöver sändas inom kontoret eller mellan objekt med stabil anslutning, kan Inband T.30 faxöverföring användas. I det här fallet, innan du skickar ett fax, måste ekosläckningsproceduren inaktiveras för att inte införa ytterligare förvrängningar.

Boken Fax, Modem, and Text for IP Telephony, av David Hanes och Gonzalo Salgueiro, är mycket detaljerad om faxöverföring.

5. Digital signalbehandling (DSP). Säkerställande av ljudkvalitet i IP-telefoni, testexempel

Vi kom på protokollen för att upprätta en konversationssession (SIP / SDP) och metoden för att överföra ljud över RTP-kanalen. Det finns en viktig fråga kvar - ljudkvaliteten. Å ena sidan bestäms ljudkvaliteten av den valda codec. Men å andra sidan behövs fortfarande ytterligare DSP-procedurer (DSP - digital signalbehandling). Dessa procedurer tar hänsyn till särdragen hos VoIP-telefoni: ett högkvalitativt headset används inte alltid, det finns paketdroppar på Internet, ibland anländer paket ojämnt, nätverkets bandbredd är inte heller gummi.

Grundläggande procedurer för att förbättra ljudkvaliteten:

VAD(Röstaktivitetsdetektor) - en procedur för att upptäcka ramar som innehåller röst (aktiv röstram) eller tystnad (inaktiv röstram). Denna separation kan avsevärt minska belastningen på nätverket, eftersom överföringen av information om tystnaden kräver mycket mindre data (det räcker bara att överföra brusnivån eller inte överföra någonting alls).

Vissa codecs innehåller redan VAD-procedurer (GSM, G.729), för andra (G.711, G.722, G.726) måste de implementeras.

Om VAD är konfigurerat för att överföra brusnivåinformation, så sänds speciella SID-paket (Silence Insertion Descriptor) i 13 m RTP CN (Comfort Noise) format.

Det är värt att notera att SID-paket kan släppas av SIP-proxyservrar, därför är det, för verifiering, lämpligt att konfigurera överföringen av RTP-trafik förbi SIP-servrar.

CNG(komfortbrusgenerering) - en procedur för att generera bekvämt brus baserat på information från SID-paket. Således fungerar VAD och CNG tillsammans, men CNG-proceduren är mycket mindre efterfrågad, eftersom det inte alltid är möjligt att märka driften av CNG, särskilt vid låg volym.

PLC(döljande av paketförlust) - proceduren för att återställa en ljudström vid paketförlust. Även med 50 % paketförlust uppnår en bra PLC-algoritm acceptabel talkvalitet. Det blir förstås förvrängningar, men orden går att urskilja.

Det enklaste sättet att emulera paketförlust (på Linux) är att använda tc-verktyget från iproute-paketet med netem-modulen. Det formar bara utgående trafik.

Ett exempel på att starta en nätverksemulering med 50 % paketförlust:

Tc qdisc change dev eth1 root nettoförlust 50 %

Inaktivera emulering:

Tc qdisc del dev eth1 root

Jitter buffert- en procedur för att bli av med jittereffekten, då intervallet mellan mottagna paket varierar mycket, och som i värsta fall leder till en felaktig ordning på mottagna paket. Denna effekt leder också till avbrott i talet. För att eliminera jittereffekten är det nödvändigt att implementera en paketbuffert på den mottagande sidan med en storlek som är tillräcklig för att återställa den ursprungliga ordningen för att skicka paket med ett givet intervall.

Du kan också emulera jittereffekten med hjälp av tc-verktyget (intervallet mellan det förväntade ögonblicket för paketets ankomst och det faktiska ögonblicket kan vara upp till 500 ms):

tc qdisc add dev eth1 root netem fördröjning 500ms beställ 99%

LEC(Line Echo Canceller) - Lokal ekosläckningsprocedur när den bortre platsen börjar höra hans egen röst. Dess kärna är att subtrahera den mottagna signalen från den överförda signalen med en viss koefficient.

Ekon kan uppstå av flera anledningar:

• akustiskt eko på grund av ljudväg av dålig kvalitet (ljud från högtalaren kommer in i mikrofonen);
• elektriskt eko på grund av impedansmissanpassning mellan telefonapparat och SLIC-modulen. För det mesta sker detta i en 4-tråds till 2-tråds telefonlinje.

Det är inte svårt att ta reda på orsaken (akustiskt eller elektriskt eko): abonnenten på vars sida ekot genereras måste stänga av mikrofonen. Om ekot ändå dyker upp så är det elektriskt.

För mer information om VoIP- och DSP-procedurer, se boken VoIP Voice and Fax Signal Processing. En förhandsvisning är tillgänglig på Google Böcker.

På denna ytliga teori VoIP översikt avslutad. Om du är intresserad kan ett exempel på praktisk implementering av en mini-PBX på en riktig hårdvaruplattform övervägas i nästa artikel.

[!?] Frågor och kommentarer är välkomna. De kommer att besvaras av författaren till artikeln Dmitry Valento, mjukvaruingenjör vid Promwads elektronikdesigncenter.

Taggar:

• för nybörjare
• för nybörjare

Lägg till taggar