Itifaki ya uhamishaji data ya wakati halisi. Itifaki za RTP na RTCP katika VoIP

2. Dhana za msingi

3. Itifaki ya uhamisho wa data ya RTP

Kanuni za kuunda itifaki ya RTP

Mbinu za udhibiti wa kazi

Umbizo la Kichwa cha Itifaki ya RTP

Itifaki ya Kuhifadhi Rasilimali - RSVP

Fasihi

2.1. Mkutano wa sauti wa kikundi

2.2. Mkutano wa video

2.3. Dhana ya wachanganyaji na watafsiri

2.4. Mpangilio wa Byte, upatanishi, na umbizo la muhuri wa muda

3.1. Sehemu za Kichwa Zisizohamishika za RTP

3.2. Vikao vya mawasiliano vya RTP

3.3. Mabadiliko ya kichwa cha RTP yaliyofafanuliwa wasifu

3.4. Ugani wa kichwa cha RTP

2.3.3. Itifaki ya TCP

2.3.4. Itifaki ya UDP

2.3.5. Itifaki za RTP na RTCP

itifaki za RTP na RSVP,

Dhana za Msingi

Mkutano wa sauti wa kikundi

Mkutano wa video

Dhana ya wachanganyaji na watafsiri

Itifaki ya udhibiti wa RTCP

Kiwango cha Usambazaji wa Pakiti ya RTCP

http://www.isuct.ru/~ivt/books/NETWORKING/NET10/269/pa.html

Tatizo kubwa zaidi ni ukosefu wa nafasi ya anwani, ambayo inahitaji kubadilisha muundo wa anwani.

Tatizo jingine ni ukosefu wa scalability ya utaratibu wa uelekezaji - msingi wa mitandao ya IP. Ukuaji wa haraka wa mtandao hupakia ruta, ambazo tayari zinalazimika kudumisha meza za uelekezaji na makumi na mamia ya maelfu ya maingizo, na pia kushughulikia shida za kugawanyika kwa pakiti. Unaweza kufanya kazi ya routers rahisi, hasa, kwa kuboresha itifaki ya IP.

Pamoja na kuanzisha vitendaji vipya moja kwa moja kwenye itifaki ya IP, inashauriwa kuhakikisha mwingiliano wa karibu na itifaki mpya kwa kuanzisha sehemu mpya kwenye kichwa cha pakiti.

Kama matokeo, iliamuliwa kurekebisha itifaki ya IP ya kisasa, kufuata malengo makuu yafuatayo:

kuunda mpango mpya wa kushughulikia anwani;
kuboresha uboreshaji wa mtandao kwa kupunguza kazi za ruta za uti wa mgongo;
kuhakikisha ulinzi wa data.

Shughulikia upanuzi wa nafasi. Itifaki ya IP hutatua tatizo linalowezekana la uhaba wa anwani kwa kupanua urefu wa anwani hadi 128. Hata hivyo, ongezeko hili kubwa la urefu wa anwani lilifanywa kwa kiasi kikubwa si kupunguza tatizo la uhaba wa anwani, lakini kuboresha ufanisi wa mitandao kulingana na itifaki hii. Lengo kuu lilikuwa kubadili kimuundo mfumo wa kushughulikia na kupanua utendaji wake.

Badala ya viwango viwili vilivyopo vya uongozi wa anwani (nambari ya mtandao na nambari ya nodi), IPv6 inapendekeza kutumia viwango vinne, ambayo ina maana ya utambulisho wa ngazi tatu wa mitandao na ngazi moja ya kutambua nodi.

Anwani sasa imeandikwa kwa hexadecimal, na kila tarakimu nne zikitenganishwa na koloni, kwa mfano:

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

Kwa mitandao inayotumia matoleo yote mawili ya itifaki za IPv4 na IPv6, inawezekana kutumia nukuu ya jadi ya desimali kwa baiti 4 za chini, na nukuu ya heksadesimali kwa baiti za juu zaidi:

0:0:0:0:FFFF 194.135.75.104.

Ndani ya mfumo wa anwani wa IPv6, pia kuna nafasi maalum ya anwani kwa matumizi ya ndani, yaani, kwa mitandao isiyo kwenye Mtandao. Kuna aina mbili anwani za mitaa: kwa mitandao "gorofa" isiyogawanywa katika subnets (Link-Local), na kwa mitandao iliyogawanywa katika subnets (Site-Local), ambayo hutofautiana katika thamani ya kiambishi awali.

Kubadilisha muundo wa vichwa vya pakiti. Hii inaweza kutekelezwa kwa kutumia mpango mpya wa kuandaa "vichwa vya kiota", ambayo inahakikisha kwamba kichwa kinagawanywa katika moja kuu, ambayo ina kiwango cha chini cha habari kinachohitajika, na zile za ziada, ambazo zinaweza kukosa. Mbinu hii inafungua uwezekano mkubwa wa kupanua itifaki kwa kufafanua vichwa vipya vya hiari, na kufanya itifaki kufunguka.

Kichwa kikuu cha datagram ya IPv6, urefu wa byte 40, ina muundo wafuatayo (Mchoro 2.4).

Shamba Darasa la Trafiki sawa katika kusudi kwa shamba Aina ya Huduma, na shamba Kikomo cha Hop- shamba Muda Wa Kuishi Itifaki ya IPv4.

Shamba Lebo ya Mtiririko hukuruhusu kutenga na kuchakata haswa mitiririko ya data ya kibinafsi bila kulazimika kuchanganua yaliyomo kwenye pakiti. Hii ni muhimu sana kutoka kwa mtazamo wa kupunguza mzigo kwenye routers.

Shamba Kichwa Kinachofuata ni sawa na uga wa Itifaki ya IPv4 na huamua aina ya kichwa kinachofuata kile kikuu. Kila kichwa cha ziada kinachofuata pia kina sehemu ya Kijajuu Kinachofuata.

Itifaki ya kudhibiti Itifaki ya Kudhibiti Usambazaji (TCP) iliundwa ili kusaidia mawasiliano shirikishi kati ya kompyuta. Itifaki ya TCP inahakikisha uaminifu na uaminifu wa kubadilishana data kati ya michakato kwenye kompyuta ambayo ni sehemu ya mtandao wa kawaida.

Kwa bahati mbaya, itifaki ya TCP haifai kwa kusambaza habari za media titika. Sababu kuu ni upatikanaji wa udhibiti wa utoaji. Ufuatiliaji huchukua muda mwingi kusambaza taarifa nyeti zaidi za kusubiri. Kwa kuongeza, TCP hutoa taratibu za udhibiti wa viwango ili kuepuka msongamano wa mtandao. Data ya sauti na video, hata hivyo, inahitaji viwango vilivyobainishwa vya usambaaji, ambavyo haviwezi kubadilishwa kiholela.

Kwa upande mmoja, itifaki ya TCP inaingiliana na itifaki ya maombi ya mtumiaji, na kwa upande mwingine, na itifaki ambayo hutoa uelekezaji wa "kiwango cha chini" na kazi za kushughulikia pakiti ambazo IP hufanya kawaida.

Muundo wa kimantiki wa programu ya mtandao unaotumia itifaki za familia za TCP/IP katika kila nodi ya Mtandao umeonyeshwa kwenye Mtini. 2.5.

Mistatili inawakilisha moduli zinazochakata data, na mistari inayounganisha mistatili inawakilisha njia za uhamishaji data. Mstari wa usawa chini ya takwimu unawakilisha mtandao wa Ethernet, ambao hutumiwa kama mfano wa kati ya kimwili.

Mchele. 2.5.

Ili kuanzisha uhusiano kati ya michakato miwili kwenye kompyuta tofauti kwenye mtandao, unahitaji kujua sio tu anwani za mtandao za kompyuta, lakini pia namba za bandari za TCP (soketi) ambazo taratibu hutumia kwenye kompyuta hizi. Muunganisho wowote wa TCP kwenye Mtandao unatambuliwa kwa njia ya kipekee na anwani mbili za IP na nambari mbili za bandari za TCP.

Itifaki ya TCP inaweza kushughulikia pakiti zilizoharibika, zilizopotea, zilizorudufiwa au zisizo za mpangilio. Hii inafanikiwa kupitia utaratibu wa kugawa nambari ya mlolongo kwa kila pakiti iliyopitishwa na utaratibu wa kuthibitisha upokeaji wa pakiti.

TCP inapotuma sehemu ya data, nakala ya data hiyo huwekwa kwenye foleni ya utumaji upya na kipima muda cha kukiri kinaanza.

Itifaki ya Datagram ya Mtumiaji (UDP) imekusudiwa kwa ubadilishanaji wa datagramu kati ya michakato ya kompyuta iliyo katika mfumo jumuishi wa mitandao ya kompyuta.

Itifaki ya UDP inategemea itifaki ya IP na hutoa huduma za usafiri kwa michakato ya maombi ambayo si tofauti sana na ile ya itifaki ya IP. Itifaki ya UDP hutoa utoaji wa data usio na uhakika, yaani hauhitaji uthibitisho wa kupokea kwake; Kwa kuongeza, itifaki hii haihitaji kuanzisha uhusiano kati ya chanzo na mpokeaji wa habari, yaani, kati ya modules za UDP.

Itifaki ya usafiri wa wakati halisi ya RTP hutoa uwasilishaji wa wakati halisi hadi wa mwisho wa data ya medianuwai kama vile sauti shirikishi na video. Itifaki hii hutekeleza utambuzi wa aina ya trafiki, nambari za mlolongo wa pakiti, udhibiti wa stempu za wakati, na udhibiti wa upokezaji.

Itifaki ya RTP hufanya kazi kwa kukabidhi mihuri ya muda kwa kila pakiti inayotoka. Kwenye upande wa kupokea, alama za nyakati za pakiti zinaonyesha katika mlolongo gani na kwa ucheleweshaji gani zinahitaji kuchezwa. Usaidizi wa RTP na RTCP huruhusu mpangishi anayepokea kupanga pakiti zilizopokewa kwa mpangilio ufaao, kupunguza athari za tofauti za muda wa mtandao kwenye ubora wa mawimbi, na kurejesha usawazishaji kati ya sauti na video ili taarifa zinazoingia ziweze kusikika na kutazamwa ipasavyo na watumiaji.

Kumbuka kuwa RTP yenyewe haina utaratibu wowote wa kuhakikisha uhamishaji wa data kwa wakati na ubora wa huduma, lakini hutumia huduma za msingi kutoa hii. Haizuii pakiti za nje, lakini haifikiri kwamba mtandao wa msingi ni wa kuaminika kabisa na hupeleka pakiti katika mlolongo sahihi. Nambari za mfuatano zilizojumuishwa katika RTP huruhusu mpokeaji kuunda upya mlolongo wa pakiti za mtumaji.

Itifaki ya RTP inaauni mawasiliano ya njia mbili na uhamishaji data kwa kikundi cha marudio ikiwa utangazaji anuwai utaauniwa na mtandao msingi. RTP imeundwa ili kutoa taarifa zinazohitajika na maombi ya mtu binafsi, na katika hali nyingi ni kuunganishwa katika uendeshaji wa maombi.

Ingawa RTP inachukuliwa kuwa itifaki ya safu ya usafiri, kwa kawaida hufanya kazi juu ya itifaki nyingine ya safu ya usafiri, UDP (Itifaki ya Data ya Mtumiaji). Itifaki zote mbili huchangia sehemu yao ya utendakazi wa safu ya usafirishaji. Ikumbukwe kwamba RTP na RTCP hazitegemei safu za msingi za usafirishaji na mtandao, kwa hivyo RTP/RTCP inaweza kutumika pamoja na itifaki zingine zinazofaa za usafirishaji.

Data ya itifaki huzuia RTP/RTCP huitwa pakiti. Pakiti zinazozalishwa kwa mujibu wa itifaki ya RTP na kutumika kusambaza data ya multimedia huitwa pakiti za habari au pakiti za data, na pakiti zinazozalishwa kwa mujibu wa itifaki ya RTCP na kutumika kusambaza habari za huduma zinazohitajika kwa uendeshaji wa kuaminika. mikutano ya simu, huitwa pakiti za kudhibiti au pakiti za kudhibiti. Pakiti ya RTP inajumuisha kichwa kisichobadilika, kiendelezi cha hiari cha kichwa cha kutofautiana, na sehemu ya data. Pakiti ya RTCP huanza na sehemu ya kudumu (sawa na sehemu ya kudumu ya pakiti za habari za RTP), ikifuatiwa na vipengele vya kimuundo ambavyo vina urefu wa kutofautiana.

Ili itifaki ya RTP iwe rahisi zaidi na inaweza kutumika kwa matumizi mbalimbali, baadhi ya vigezo vyake vinafanywa kuwa wazi kwa makusudi, lakini inajumuisha dhana ya wasifu. Profaili ni seti ya vigezo vya itifaki za RTP na RTCP kwa darasa maalum la programu, ambayo huamua sifa za utendaji wao. Wasifu unafafanua: utumiaji wa sehemu za vichwa vya pakiti mahususi, aina za trafiki, pedi za vichwa na viendelezi vya vichwa, aina za pakiti, huduma za usalama za mawasiliano na algoriti, matumizi ya msingi ya itifaki, n.k. Kila programu hufanya kazi na wasifu mmoja tu, na Aina ya wasifu ni maalum kwa kuchagua programu inayofaa. Hakuna dalili ya wazi ya aina ya wasifu kwa nambari ya mlango, kitambulisho cha itifaki, n.k.

Kwa hivyo, vipimo kamili vya RTP kwa programu mahususi lazima vijumuishe hati za ziada, zinazojumuisha maelezo ya wasifu, pamoja na maelezo ya umbizo la trafiki inayofafanua jinsi aina fulani ya trafiki, kama vile sauti au video, itakavyochakatwa katika RTP.

Mkutano wa sauti wa kikundi unahitaji anwani ya kikundi cha watumiaji wengi na milango miwili. Katika kesi hii, bandari moja inahitajika kwa kubadilishana data ya sauti, na nyingine hutumiwa kwa pakiti za udhibiti wa itifaki ya RTCP. Anwani ya kikundi na maelezo ya bandari hutumwa kwa washiriki waliokusudiwa mikutano ya simu. Ikiwa usiri unahitajika, basi pakiti za habari na udhibiti zinaweza kusimbwa, katika hali ambayo ufunguo kusambazwa usimbaji fiche.

Programu ya mikutano ya sauti inayotumiwa na kila mshiriki wa mkutano hutuma data ya sauti katika sehemu ndogo, kama vile 20 ms. Kila kipande cha data ya sauti kinatanguliwa na kichwa cha RTP; Kichwa cha RTP na data huundwa kwa njia mbadala (imeambatanishwa) kuwa pakiti ya UDP. Kijajuu cha RTP kinaonyesha ni aina gani ya usimbaji wa sauti (kama vile PCM, ADPCM, au LPC) ilitumika kutoa data kwenye pakiti. Hii inafanya uwezekano wa kubadilisha aina ya usimbaji wakati wa mkutano, kwa mfano, wakati mshiriki mpya anaonekana ambaye anatumia kiungo cha chini cha bandwidth, au wakati kuna msongamano wa mtandao.

Kwenye Mtandao, kama ilivyo kwa mitandao mingine ya data iliyobadilishwa kwa pakiti, pakiti wakati mwingine hupotea na kupangwa upya, na hucheleweshwa kwa viwango tofauti vya muda. Ili kukabiliana na matukio haya, kichwa cha RTP kina muhuri wa muda na nambari ya mfuatano ambayo inaruhusu wapokeaji kuweka upya muda ili, kwa mfano, sehemu za mawimbi ya sauti zichezwe kila mara na spika kila baada ya milisekunde 20. Urekebishaji huu wa muda unafanywa kando na kwa kujitegemea kwa kila chanzo cha pakiti za RTP ndani mikutano ya simu. Nambari ya mfuatano inaweza pia kutumiwa na mpokeaji kukadiria idadi ya pakiti zilizopotea.

Tangu washiriki mikutano ya simu wanaweza kujiunga na kuondoka wakati mkutano unaendelea, ni muhimu kujua ni nani anayeshiriki kwa sasa na jinsi washiriki wa mkutano huo wanapokea data ya sauti. Kwa madhumuni haya, kila tukio la programu ya sauti wakati wa kongamano mara kwa mara hutoa ujumbe kwa lango dhibiti (bandari ya RTCP) kwa ajili ya maombi ya washiriki wengine wote kuhusu upokeaji wa pakiti zinazoonyesha jina la mtumiaji wake. Ujumbe wa kupokea unaonyesha jinsi spika ya sasa inavyosikika vizuri na inaweza kutumika kudhibiti visimbaji vinavyobadilika. Kando na jina la mtumiaji, maelezo mengine ya kitambulisho kwa udhibiti wa kipimo data yanaweza pia kujumuishwa. Wakati wa kuondoka kwenye mkutano, tovuti hutuma pakiti ya RTCP BYE.

Ikiwa ndani mikutano ya simu Ikiwa ishara zote za sauti na video zinatumiwa, hupitishwa kando. Ili kusambaza kila aina ya trafiki bila ya nyingine, vipimo vya itifaki huanzisha dhana ya kipindi cha mawasiliano cha RTP. Kipindi hufafanuliwa na jozi mahususi ya anwani za usafiri lengwa (anwani moja ya mtandao pamoja na jozi ya bandari za RTP na RTCP). Pakiti za kila aina ya trafiki hutumwa kwa kutumia jozi mbili tofauti za bandari za UDP na/au anwani za upeperushaji anuwai. Hakuna muunganisho wa moja kwa moja wa RTP kati ya vipindi vya sauti na video, isipokuwa tu kwamba mtumiaji anayeshiriki katika vipindi vyote viwili lazima atumie jina moja la kisheria katika pakiti za RTCP za vipindi vyote viwili ili vipindi hivyo vihusishwe.

Sababu moja ya utengano huu ni kwamba baadhi ya washiriki wa mkutano lazima waruhusiwe kupokea aina moja tu ya trafiki ikiwa wanataka kufanya hivyo. Licha ya utenganisho, uchezaji kisawazishaji wa media chanzo (sauti na video) unaweza kupatikana kwa kutumia maelezo ya saa ambayo hubebwa katika pakiti za RTCP kwa vipindi vyote viwili.

Sio tovuti zote zinaweza kupokea data ya media titika katika umbizo sawa. Fikiria kisa ambapo washiriki kutoka eneo moja wameunganishwa kupitia kiungo cha kasi ya chini kwa wengi wa washiriki wengine wa mkutano ambao wana ufikiaji wa mtandao kwa njia pana. Badala ya kulazimisha kila mtu kutumia kipimo data cha chini na usimbaji wa sauti wa ubora wa chini, kituo cha mawasiliano cha safu ya RTP kinachoitwa kichanganyaji kinaweza kuwekwa katika eneo la kipimo cha chini. Kichanganyaji hiki husawazisha upya pakiti za sauti zinazoingia ili kurejesha vipindi asili vya 20-ms, huchanganya mitiririko hii ya sauti iliyoundwa upya hadi mtiririko mmoja, husimba mawimbi ya sauti kwa kipimo data finyu, na husambaza mtiririko wa pakiti kwenye kiungo cha kasi ya chini. Katika kesi hii, pakiti zinaweza kushughulikiwa kwa mpokeaji mmoja au kikundi cha wapokeaji wenye anwani tofauti. Ili kuhakikisha dalili sahihi wakati wa kupokea miisho chanzo cha ujumbe, kichwa cha RTP kinajumuisha njia za wachanganyaji kutambua vyanzo vilivyoshiriki katika uundaji wa pakiti iliyochanganywa.

Baadhi ya washiriki katika mkutano wa sauti wanaweza kuunganishwa kwa viungo vya broadband, lakini huenda wasipatikane kupitia mikutano ya kikundi kwa kutumia itifaki ya IP (IPM - IP multicast). Kwa mfano, zinaweza kuwa nyuma ya ngome ya safu ya programu ambayo haitaruhusu pakiti zozote za IP kupitishwa. Kwa matukio hayo, huhitaji mixers, lakini aina nyingine ya vifaa vya mawasiliano ya kiwango cha RTP, kinachoitwa watafsiri. Kati ya relay mbili, moja imewekwa nje ya ngome na inapeleka mbele pakiti zote za utangazaji anuwai zilizopokelewa kwa muunganisho salama kwa upeanaji mwingine uliowekwa nyuma ya ngome. Relay nyuma ya ngome huzisambaza tena kama pakiti za upeperushaji anuwai kwa kikundi cha watumiaji wengi kilichozuiliwa kwa mtandao wa ndani wa tovuti.

Maeneo yote ya pakiti za RTP/RTCP hupitishwa kwenye mtandao kwa ka (octets); baiti muhimu zaidi hupitishwa kwanza. Data zote za sehemu ya kichwa hupangwa kulingana na urefu wake. Oktet zilizoteuliwa kuwa za hiari zina thamani ya sifuri.

Itifaki ya kudhibiti RTCP (RTCP - Itifaki ya Udhibiti wa Wakati Halisi) inategemea usambazaji wa pakiti za mara kwa mara usimamizi kwa washiriki wote katika kipindi cha mawasiliano kwa kutumia utaratibu wa usambazaji sawa na itifaki ya RTP. Itifaki ya msingi lazima itoe kuzidisha pakiti za maelezo na udhibiti, kwa mfano, kwa kutumia nambari tofauti za mlango wa UDP. Itifaki ya RTCP hufanya kazi kuu nne.

Kazi kuu ni kutoa maoni ili kutathmini ubora wa usambazaji wa data. Hili ni kazi muhimu ya RTCP kama itifaki ya usafiri na inahusiana na udhibiti wa mtiririko na kazi za msongamano wa itifaki nyingine za usafiri. Maoni yanaweza kuwa muhimu moja kwa moja katika kudhibiti usimbaji unaobadilika, lakini majaribio ya utumaji mwingi wa IP yameonyesha kuwa maoni kwa wapokeaji pia ni muhimu kwa kutambua kasoro katika usambazaji wa taarifa. Kutuma ripoti za maoni kuhusu mapokezi ya data kwa washiriki wote hukuruhusu kutathmini kama matatizo ni ya ndani au ya kimataifa unapotazama matatizo. Kwa utaratibu wa usambazaji wa IPM, huluki kama vile watoa huduma za mtandao zinaweza pia kupokea maelezo ya maoni na kufanya kama mfuatiliaji wa watu wengine wakati wa kuchunguza matatizo ya mtandao. Kitendaji hiki cha maoni hutolewa na ripoti za mtumaji na mpokeaji wa RTCP.
RTCP hudumisha safu ya uchukuzi ya kitambulishi cha chanzo cha data cha RTP kinachoitwa jina la kisheria (CNAME). Kwa sababu Kitambulisho cha SSRC kinaweza kubadilika ikiwa mgogoro utatambuliwa au programu imeanzishwa upya, wapokeaji wanahitaji CNAME ya kisheria ili kufuatilia kila mshiriki. Wapokeaji pia wanahitaji CNAME ya weka onyesho mtiririko wa taarifa kutoka kwa mshiriki fulani hadi vipindi vingi vinavyohusiana vya RTP, kwa mfano wakati wa kusawazisha mawimbi ya sauti na video.
Kazi mbili za kwanza zinahitaji washiriki wote kutuma pakiti za RTCP, kwa hiyo, ili kuruhusu kuongeza idadi ya washiriki, RTP lazima idhibiti mzunguko wa maambukizi ya pakiti hizo. Inapotumwa na kila mshiriki mikutano ya simu kudhibiti vifurushi kwa washiriki wengine wote, kila mmoja anaweza kukadiria kwa uhuru jumla ya idadi ya washiriki.
Kitendo cha nne, cha hiari cha RTCP lazima kitoe maelezo ya udhibiti wa kipindi (kwa mfano, kitambulisho cha mshiriki) ambacho kitaonyeshwa kwenye kiolesura cha mtumiaji. Hii ina uwezekano mkubwa wa kuwa na manufaa katika vipindi vya "kudhibitiwa kwa urahisi", ambapo washiriki hujiunga na kuondoka kwenye kikundi bila kudhibiti uanachama au kukubaliana juu ya vigezo.

Chaguo za kukokotoa moja hadi tatu zinahitajika wakati RTP inatumiwa katika utangazaji anuwai wa IP na kupendekezwa katika visa vingine vyote. Wasanidi programu wa RTP wanahimizwa kuepuka mbinu zinazofanya kazi kwa njia mbili pekee na hazibadiliki ili kuongeza idadi ya watumiaji.

Itifaki ya RTP inaruhusu programu kuongeza kiotomatiki uwakilishi wa kipindi cha mawasiliano, kuanzia washiriki wachache hadi elfu kadhaa. Kwa mfano, katika mkutano wa sauti, trafiki ya data kimsingi inajizuia kwa sababu ni mtu mmoja au wawili tu wanaweza kuzungumza kwa wakati mmoja, na kwa usambazaji wa kikundi, kiwango cha data kwenye kiungo chochote kinasalia kwa kiasi, bila kujali idadi ya washiriki. Walakini, udhibiti wa trafiki haujiwekei kikomo. Iwapo ripoti za kupokea kutoka kwa kila mshiriki zitatumwa kwa kasi isiyobadilika, basi trafiki ya udhibiti itaongezeka kwa mstari kadiri idadi ya washiriki inavyoongezeka. Kwa hiyo, utaratibu maalum unapaswa kutolewa ili kupunguza mzunguko wa maambukizi ya pakiti za udhibiti.

Kwa kila kipindi, trafiki ya data inachukuliwa kufikia kikomo cha jumla kinachoitwa kipimo data cha kipindi, ambacho kinashirikiwa na washiriki wote. Bandwidth hii inaweza kuhifadhiwa na kikomo chake kinawekwa na mtandao. Bandwidth ya kipindi haitegemei aina ya usimbaji wa midia, lakini chaguo la aina ya usimbaji inaweza kuzuiwa na kipimo data cha kipindi. Mpangilio wa kipimo data cha kipindi unatarajiwa kutolewa na programu ya usimamizi wa kipindi inapoita programu ya maudhui, lakini programu za maudhui zinaweza pia kuweka thamani chaguomsingi kulingana na kipimo data cha mtumaji mmoja kwa aina ya usimbaji iliyochaguliwa kwa kipindi fulani.

Mahesabu ya Bandwidth kwa udhibiti na trafiki ya data hufanywa kwa kuzingatia itifaki za msingi za usafiri na safu ya mtandao (kwa mfano, UDP na IP). Vijajuu vya safu ya kiungo cha data (DLC) hazizingatiwi katika hesabu kwa sababu pakiti inaweza kuwekewa vichwa tofauti vya safu ya DLC inapopitishwa.

Udhibiti wa trafiki unapaswa kuwa mdogo kwa sehemu ndogo na inayojulikana ya bandwidth ya kikao: ndogo ya kutosha kwamba kazi ya msingi ya itifaki ya usafiri - maambukizi ya data - haiathiriwa; inajulikana ili trafiki ya udhibiti iweze kujumuishwa katika vipimo vya kipimo data vilivyopewa itifaki uhifadhi wa rasilimali, na ili kila mshiriki aweze kujitegemea kuhesabu sehemu yake. Inachukuliwa kuwa sehemu ya kipimo data cha kipindi kilichogawiwa RTCP inapaswa kuwekwa kuwa 5%. Washiriki wote wa kipindi lazima watumie kiasi sawa cha kipimo data cha RTCP ili viwango vya muda vilivyokokotolewa vya pakiti ya upitishaji vifanane. Kwa hivyo viunga hivi lazima viwekwe kwa kila wasifu.

Algorithm ya kuhesabu muda kati ya kutuma pakiti za RTCP za mchanganyiko ili kugawa kipimo data kilichotengwa kwa udhibiti wa trafiki kati ya washiriki ina sifa kuu zifuatazo:

watumaji kwa pamoja hutumia angalau 1/4 ya kipimo data cha trafiki kama katika vikao na wapokeaji wengi lakini watumaji wachache; Kwa kuwa hawajaanzisha muunganisho, washiriki wanapokea CNAME ya tovuti zinazotuma ndani ya muda mfupi;
Inahitajika kuwa muda uliohesabiwa kati ya pakiti za RTCP uwe angalau zaidi ya sekunde 5 ili kuepuka kupasuka kwa pakiti za RTCP kuzidi kipimo kinachoruhusiwa wakati idadi ya washiriki ni ndogo na trafiki haijafanywa kwa mujibu wa sheria ya idadi kubwa;
Muda kati ya pakiti za RTCP hubadilishwa nasibu ndani ya nusu moja hadi moja na nusu ya vipindi vilivyokokotolewa ili kuepuka kusawazisha washiriki wote bila kukusudia. Pakiti ya kwanza ya RTCP iliyotumwa baada ya kuingia kwenye kipindi pia hucheleweshwa nasibu (hadi nusu ya muda wa chini wa RTCP) ikiwa programu itaanzishwa katika tovuti nyingi kwa wakati mmoja, kama vile wakati wa kutangaza kuanza kwa kipindi;
ili kukabiliana kiotomatiki na mabadiliko katika kiasi cha taarifa za udhibiti zinazopitishwa, makadirio ya nguvu ya ukubwa wa wastani wa pakiti ya RTCP yenye mchanganyiko huhesabiwa kwa kutumia pakiti zote zilizopokelewa na kutumwa;
algorithm hii inaweza kutumika kwa vipindi ambavyo upitishaji wa pakiti unakubalika kwa washiriki wote. Katika hali hii, kigezo cha kipimo data cha kipindi ni kipimo data cha mtumaji binafsi kilichozidishwa na idadi ya washiriki, na kipimo data cha RTP kinategemea itifaki ya msingi kutoa kiashiria cha urefu. Urefu wa juu wa pakiti za RTP ni mdogo tu na itifaki za msingi.
Pakiti kadhaa za itifaki za RTP zinaweza kubebwa katika kizuizi cha data cha itifaki ya safu ya chini, kama vile pakiti ya UDP. Hii inapunguza upungufu wa vichwa na kurahisisha ulandanishi kati ya nyuzi tofauti.

Ukuaji wa haraka wa Mtandao unaweka mahitaji mapya kwa kasi na kiasi cha uhamishaji data. Na ili kukidhi mahitaji haya yote, kuongeza tu uwezo wa mtandao haitoshi; mbinu zinazofaa na zinazofaa za kudhibiti msongamano wa trafiki na njia za upitishaji zinahitajika.

Katika programu za wakati halisi, mtumaji hutoa mtiririko wa data kwa kasi isiyobadilika, na mpokeaji (au wapokeaji) lazima atoe data hiyo kwa programu kwa kiwango sawa. Programu kama hizo ni pamoja na, kwa mfano, mikutano ya sauti na video, video ya moja kwa moja, uchunguzi wa mbali katika dawa, simu ya kompyuta, uigaji mwingiliano uliosambazwa, michezo, ufuatiliaji wa wakati halisi, n.k.

Itifaki ya safu ya usafiri inayotumiwa sana ni TCP. Ingawa TCP inaweza kusaidia aina mbalimbali za programu zilizosambazwa, haifai kwa programu za wakati halisi.

Itifaki mpya ya usafiri wa wakati halisi imeundwa kutatua tatizo hili - RTP(Itifaki ya Usafiri wa Wakati Halisi), ambayo huhakikisha uwasilishaji wa data kwa mpokeaji mmoja au zaidi kwa kuchelewa ndani ya mipaka maalum, yaani, data inaweza kutolewa tena kwa wakati halisi.

RTP haitumii mbinu zozote za uwasilishaji wa pakiti, uadilifu wa utumaji, au kutegemewa kwa muunganisho. Kazi hizi zote zimepewa itifaki ya usafiri. RTP hufanya kazi juu ya UDP na inaweza kusaidia uhamishaji wa data kwa wakati halisi kati ya washiriki wengi katika kipindi cha RTP.

Kumbuka

Kwa kila mshiriki wa RTP, kipindi huamuliwa na jozi ya anwani za usafirishaji za pakiti (anwani moja ya mtandao - IP na jozi ya bandari: RTP na RTCP).

Pakiti za RTP zina sehemu zifuatazo: kitambulisho cha mtumaji kinachoonyesha ni chama kipi kinazalisha data, mihuri ya saa wakati pakiti ilitolewa ili data iweze kuchezwa tena kwa vipindi sahihi na mpokeaji, taarifa kuhusu mpangilio wa uwasilishaji, na. habari kuhusu asili ya yaliyomo kwenye pakiti, k.m. aina ya usimbaji wa data ya video (MPEG, Indeo, n.k.). Uwepo wa maelezo kama haya huturuhusu kukadiria thamani ya ucheleweshaji wa awali na saizi ya bafa ya upitishaji.

Kumbuka

Katika mazingira ya kawaida ya muda halisi, mtumaji huzalisha pakiti kwa kiwango cha mara kwa mara. Hutumwa kwa vipindi vya kawaida, husafiri kupitia mtandao na hupokelewa na mpokeaji, ambaye hurejesha data kwa wakati halisi inapopokelewa. Hata hivyo, kutokana na mabadiliko ya muda wa kusubiri pakiti zinaposafiri kwenye mtandao, zinaweza kufika kwa vipindi visivyo kawaida. Ili kulipa fidia kwa athari hii, pakiti zinazoingia zimehifadhiwa, zimehifadhiwa kwa muda, na kisha hutolewa kwa kiwango cha mara kwa mara kwa programu inayozalisha pato. Kwa hivyo, ili itifaki ya wakati halisi ifanye kazi, ni muhimu kwamba kila pakiti iwe na muhuri wa muda ili mpokeaji aweze kutoa data inayoingia kwa kasi sawa na ya mtumaji.

Kwa kuwa RTP inafafanua (na inasimamia) muundo wa upakiaji wa data iliyopitishwa, inayohusiana moja kwa moja na hii ni dhana ya maingiliano, ambayo inawajibika kwa utaratibu wa tafsiri ya RTP - mchanganyiko. Kwa kupokea mitiririko ya pakiti za RTP kutoka kwa chanzo kimoja au zaidi, kichanganyaji huzichanganya na kutuma mtiririko mpya wa pakiti za RTP kwa mpokeaji mmoja au zaidi. Mchanganyiko unaweza tu kuchanganya data na pia kubadilisha muundo wake, kwa mfano, wakati wa kuchanganya vyanzo vingi vya sauti. Tuseme mfumo mpya unataka kushiriki katika kipindi, lakini kiunga chake kwenye mtandao hakina uwezo wa kutosha kuunga mkono mitiririko yote ya RTP, kisha kichanganyaji hupokea mitiririko hii yote, inachanganya kuwa moja, na kupitisha mwisho kwa mpya. mjumbe wa kikao. Wakati wa kupokea mitiririko mingi, kichanganyaji huongeza tu maadili ya urekebishaji wa msimbo wa mapigo. Kichwa cha RTP kinachozalishwa na kichanganyaji kinajumuisha utambulisho wa mtumaji ambaye data yake iko kwenye pakiti.

Kifaa rahisi zaidi, kitafsiri, huunda pakiti moja ya RTP inayotoka kwa kila pakiti ya RTP inayoingia. Utaratibu huu unaweza kubadilisha muundo wa data katika pakiti au kutumia seti tofauti ya itifaki za kiwango cha chini kuhamisha data kutoka kikoa kimoja hadi kingine. Kwa mfano, mpokeaji anayetarajiwa asiweze kuchakata mawimbi ya video ya kasi ya juu inayotumiwa na washiriki wengine kwenye kipindi. Mtafsiri hubadilisha video hadi umbizo la ubora wa chini ambalo halihitaji kiwango cha juu cha uhamishaji data.

Itifaki ya RTP inatumika tu kusambaza data ya mtumiaji - kwa kawaida matangazo mengi - kwa washiriki wote kwenye kipindi. Itifaki ya RTCP (Itifaki ya Udhibiti wa Usafiri wa Wakati Halisi) inafanya kazi pamoja na RTP, kazi kuu ambayo ni kutoa udhibiti wa upitishaji wa RTP. RTCP hutumia itifaki ya msingi ya usafiri kama RTP (kawaida UDP), lakini nambari ya bandari tofauti.

RTCP hufanya kazi kadhaa:

Kuhakikisha na kufuatilia ubora wa huduma na maoni katika kesi ya upakiaji kupita kiasi. Kwa sababu pakiti za RTCP ni za utangazaji anuwai, washiriki wote katika kipindi wanaweza kutathmini jinsi washiriki wengine wanavyofanya na kupokea vizuri. Ujumbe wa mtumaji huruhusu wapokeaji kutathmini kasi ya data na ubora wa utumaji. Barua pepe za wapokeaji zina maelezo kuhusu matatizo wanayokumbana nayo, ikiwa ni pamoja na kupoteza pakiti na mshtuko mwingi. Maoni kutoka kwa wapokeaji pia ni muhimu kwa kutambua makosa katika usambazaji. Kwa kuchanganua ujumbe kutoka kwa washiriki wote katika kipindi, msimamizi wa mtandao anaweza kubaini kama tatizo fulani linahusu mshiriki mmoja au ni la kawaida. Ikiwa programu ya kutuma inahitimisha kuwa shida ni tabia ya mfumo kwa ujumla, kwa mfano, kwa sababu ya kutofaulu kwa moja ya njia za mawasiliano, basi inaweza kuongeza kiwango cha ukandamizaji wa data kwa gharama ya kupunguza ubora au kukataa. sambaza video kabisa - hii inaruhusu data kusambazwa juu ya uwezo wa chini wa muunganisho.
Kitambulisho cha mtumaji. Pakiti za RTCP zina maelezo ya kawaida ya maandishi ya mtumaji. Hutoa maelezo zaidi kuhusu mtumaji wa pakiti za data kuliko kitambulisho cha chanzo cha kusawazisha kilichochaguliwa kwa nasibu. Pia husaidia mtumiaji kutambua nyuzi za vipindi tofauti.
Ukadiriaji wa ukubwa wa kikao na kuongeza. Ili kuhakikisha ubora wa huduma na maoni kwa madhumuni ya kudhibiti msongamano, na pia kwa madhumuni ya kutambua mtumaji, washiriki wote hutuma pakiti za RTCP mara kwa mara. Mzunguko wa maambukizi ya pakiti hizi hupungua kadri idadi ya washiriki inavyoongezeka. Kwa idadi ndogo ya washiriki, pakiti moja ya RTCP hutumwa kwa zaidi ya kila sekunde 5. RFC-1889 inafafanua algoriti ambapo washiriki hupunguza kiwango cha pakiti za RTCP kulingana na jumla ya idadi ya washiriki. Lengo ni kuweka trafiki ya RTCP isizidi 5% ya jumla ya trafiki ya kipindi.

RTP ni itifaki inayolenga mkondo. Kichwa cha pakiti cha RTP kiliundwa kwa kuzingatia mahitaji ya maambukizi ya wakati halisi. Ina maelezo kuhusu mpangilio wa pakiti ili mtiririko wa data ukutanishwe ipasavyo kwenye sehemu ya kupokea, na muhuri wa muda wa mlolongo sahihi wa fremu wakati wa uchezaji na wa kusawazisha mitiririko mingi ya data, kama vile video na sauti.

Kila pakiti ya RTP ina kichwa kikuu, na ikiwezekana sehemu za ziada za programu mahususi.

Kutumia TCP kama itifaki ya usafiri kwa programu hizi hakuwezekani kwa sababu kadhaa:

Itifaki hii inaruhusu tu muunganisho kuanzishwa kati ya ncha mbili, kwa hivyo haifai kwa upitishaji wa utangazaji anuwai.
TCP inaruhusu utumaji upya wa sehemu zilizopotea ambazo hufika wakati programu ya wakati halisi haizisubiri tena.
TCP haina utaratibu unaofaa wa kuhusisha maelezo ya saa na sehemu, hitaji la ziada kwa programu za wakati halisi.

Itifaki nyingine ya safu ya usafiri inayotumika sana, LJDP haina baadhi ya vikwazo vya TCP, lakini haitoi taarifa muhimu za wakati.

Ingawa kila programu ya wakati halisi inaweza kuwa na njia zake za kuauni utumaji wa wakati halisi, zina mfanano mwingi unaofanya kufafanua itifaki moja kuhitajika sana.

Tatizo hili ndilo ambalo itifaki mpya ya usafiri wa wakati halisi imeundwa kutatua - RTP (Itifaki ya Usafiri ya Wakati Halisi), ambayo inahakikisha uwasilishaji wa data kwa mpokeaji mmoja au zaidi kwa kucheleweshwa ndani ya mipaka maalum, yaani, data inaweza kutolewa tena katika Muda halisi.

Katika Mtini. 1 huonyesha kichwa kisichobadilika cha RTP ambacho kina idadi ya sehemu zinazotambulisha vipengele kama vile umbizo la pakiti, nambari ya mfuatano, vyanzo, mipaka na aina ya upakiaji. Kijajuu kisichobadilika kinaweza kufuatiwa na sehemu zingine zilizo na maelezo ya ziada kuhusu data.

Mchele. 1. Kichwa kisichohamishika cha RTP.

V(Biti 2). Sehemu ya toleo. Toleo la sasa ni la pili.
R(kidogo 1). Jaza uga. Sehemu hii inaashiria uwepo wa pweza za padding mwishoni mwa mzigo. Padding hutumiwa wakati programu inahitaji saizi ya mzigo kuwa mgawo wa, kwa mfano, biti 32. Katika kesi hii, octet ya mwisho inaonyesha idadi ya pweza.
X(kidogo 1). Sehemu ya upanuzi wa kichwa. Sehemu hii inapowekwa, kichwa kikuu hufuatwa na kichwa cha ziada kinachotumika katika viendelezi vya majaribio ya RTP.
SS(Biti 4). Idadi ya uga wa watumaji. Sehemu hii ina idadi ya vitambulisho vya mtumaji ambavyo data yake iko kwenye pakiti, huku vitambulisho vyenyewe vikifuata kichwa kikuu.
M(kidogo 1). Sehemu ya alama. Maana ya alama kidogo inategemea aina ya malipo. Alama kidogo hutumiwa kuonyesha mipaka ya mtiririko wa data. Kwa upande wa video, inabainisha mwisho wa fremu. Katika kesi ya sauti, inabainisha mwanzo wa hotuba baada ya muda wa kimya.
RT(Biti 7). Sehemu ya aina ya malipo. Sehemu hii inabainisha aina ya upakiaji na umbizo la data, ikiwa ni pamoja na mbano na usimbaji fiche. Katika hali ya utulivu, mtumaji hutumia aina moja tu ya upakiaji wakati wa kipindi, lakini anaweza kuibadilisha kulingana na mabadiliko ya hali ikiwa imeainishwa na Itifaki ya Udhibiti wa Usafiri wa Wakati Halisi.
Nambari ya Mlolongo(Biti 16). Sehemu ya nambari ya mlolongo. Kila chanzo huanza kuhesabu pakiti kwa nambari isiyo ya kawaida, ambayo huongezeka kwa moja kwa kila pakiti ya data ya RTP iliyotumwa. Hii hukuruhusu kugundua upotezaji wa pakiti na kuamua mpangilio wa pakiti zilizo na muhuri wa wakati sawa. Pakiti nyingi zinazofuatana zinaweza kuwa na muhuri wa muda sawa ikiwa zilitoka kimantiki kwa wakati mmoja, kama vile pakiti za fremu moja ya video.
Muhuri wa saa(Biti 32). Uga wa muhuri wa wakati. Sehemu hii ina wakati ambapo oktet ya data ya upakiaji wa kwanza iliundwa. Vipimo ambavyo muda unaripotiwa katika sehemu hii hutegemea aina ya upakiaji. Thamani inabainishwa na saa ya ndani ya mtumaji.
Chanzo cha Usawazishaji (SSRC) Kitambulisho(Biti 32). Sawazisha sehemu ya Kitambulisho cha Chanzo: Nambari inayozalishwa bila mpangilio ambayo hutambulisha chanzo mahususi wakati wa kipindi, isiyotegemea anwani ya mtandao. Nambari hii ina jukumu muhimu wakati wa kuchakata kipande cha data kinachoingia kutoka kwa chanzo kimoja.
Kitambulishi Chanzo Cha Kuchangia (CSRC).(Biti 32). Orodha ya sehemu za vitambulisho vya chanzo "zilizochanganywa" kwenye mkondo mkuu, kwa mfano, kwa kutumia mchanganyiko. Kichanganyaji huingiza orodha nzima ya vitambulishi vya vyanzo vya SSRC vilivyoshiriki katika ujenzi wa pakiti hii ya RTP. Orodha hii inaitwa CSRC. Idadi ya vipengele katika orodha: kutoka 0 hadi 15. Ikiwa idadi ya washiriki ni zaidi ya 15, 15 wa kwanza huchaguliwa. Mfano utakuwa mkutano wa sauti, pakiti za RTP ambazo zina hotuba za washiriki wote, kila moja ikiwa na SSRC yao wenyewe - wanaunda orodha ya CSRC. Aidha, mkutano mzima una SSRC ya pamoja.

Itifaki ya RTCP, kama itifaki yoyote ya udhibiti, ni ngumu zaidi katika muundo na kazi zinazofanywa (linganisha, kwa mfano, itifaki za IP na TCP). Ingawa itifaki ya RTCP inategemea RTP, ina sehemu nyingi za ziada ambazo hutekeleza kazi zake.

Itifaki ya Kuhifadhi Rasilimali, RSVP, ambayo kwa sasa inakaguliwa na Kikosi Kazi cha Uhandisi wa Mtandao (IETF), imeundwa kutatua tatizo la kutanguliza data nyeti kwa muda badala ya data ya jadi, ambayo ucheleweshaji sio muhimu sana. RSVP inaruhusu mifumo ya mwisho kuhifadhi rasilimali za mtandao ili kupata ubora unaohitajika wa huduma, hasa rasilimali za ratiba ya wakati halisi juu ya itifaki ya RTP. RSVP inahusika hasa na vipanga njia, ingawa programu kwenye nodi za mwisho lazima pia zijue jinsi ya kutumia RSVP kuhifadhi kipimo data kinachohitajika kwa darasa fulani la huduma au kiwango cha kipaumbele.

RTP, pamoja na viwango vingine vilivyoelezewa, hukuruhusu kusambaza video na sauti kwa mafanikio kupitia mitandao ya kawaida ya IP. RTP/RTCP/RSVP - suluhu sanifu kwa mitandao yenye utumaji data wa wakati halisi. Upungufu wake pekee ni kwamba imekusudiwa tu kwa mitandao ya IP. Hata hivyo, kizuizi hiki ni cha muda: mitandao itaendeleza katika mwelekeo huu kwa njia moja au nyingine. Suluhisho hili linaahidi kutatua tatizo la kusambaza data nyeti ya kuchelewa kwenye mtandao.

Maelezo ya itifaki ya RTP yanaweza kupatikana katika RFC-1889.

2. Katika relativism, "mwanga" ni jambo la kizushi yenyewe, na sio wimbi la kimwili, ambalo ni usumbufu wa kati fulani ya kimwili. "Nuru" ya uhusiano ni msisimko wa kitu chochote. Haina kati ya mtoa huduma kwa mitetemo.

3. Katika relativism, kudanganywa na wakati (kupungua) kunawezekana, kwa hiyo kanuni za causality na kanuni ya mantiki kali, ya msingi kwa sayansi yoyote, inakiukwa. Katika relativism, kwa kasi ya mwanga, wakati huacha (kwa hiyo, ni ujinga kuzungumza juu ya mzunguko wa photon). Katika uhusiano, vurugu kama hiyo dhidi ya akili inawezekana, kama vile taarifa kuhusu kuzidisha kwa umri wa mapacha wanaotembea kwa kasi ndogo, na dhihaka zingine za mantiki zinazopatikana katika dini yoyote.

Itifaki za RTP na RTCP katika VoIP

RTP ndiyo itifaki kuu ya usafiri katika mitandao ya simu ya IP. RTP (Itifaki ya Wakati Halisi) ni itifaki ya wakati halisi ambayo iliundwa kwa ajili ya kusambaza medianuwai (sauti, video), maelezo yaliyosimbwa na yaliyofungwa kwenye mitandao ya IP ndani ya muda uliowekwa. Usambazaji wa sehemu za RTP hutokea juu ya itifaki za UDP na IP, kwa mtiririko huo, katika viwango tofauti vya mfano wa OSI. Utumiaji wa UDP, ambao hauhakikishi uwasilishaji, unatokana na muda madhubuti wa utangazaji wa media ya wakati halisi, pamoja na kutokuwa na uwezo wa TCP kufanya kazi kwa wakati halisi. Kwa hiyo, licha ya kupoteza data fulani, utoaji wa wakati ni muhimu zaidi katika kesi hii.
Kwa ujumla, usambazaji wa itifaki katika tabaka za muundo wa OSI ni kama ifuatavyo.
Safu ya usafiri: RTP juu ya UDP
Mtandao: IP
Kituo: Ethaneti
Kimwili: Ethernet
Wakati wa kusambaza habari za media titika kwa kutumia itifaki ya RTP, encapsulation ifuatayo hutumiwa:

Ukubwa wa chini wa sehemu ya RTP ni baiti 12. Biti mbili za kwanza huamua toleo la itifaki. Leo RTPv.2 inatumika. Sehemu inayofuata ya P pia ina urefu wa biti 2 na inaonyesha uwepo wa herufi za pedi kwenye uwanja wa data wakati wa kutumia sehemu za urefu sawa. Sehemu ya X huamua ikiwa kichwa kirefu kinatumika. Sehemu ya 4-bit CC kisha inafafanua idadi ya sehemu za CSRC mwishoni mwa kichwa cha RTP, yaani, idadi ya vyanzo vinavyounda mtiririko. Inayofuata inakuja uga wa M, alama kidogo inayotumiwa kuangazia data muhimu. Sehemu inayofuata ya PT ina ukubwa wa bits 7. Iliyoundwa ili kuamua aina ya malipo - data inayohitajika kwa programu. Kwa kutumia nambari iliyoainishwa, programu huamua aina ya habari ya media titika na njia ya kusimbua.
Sehemu iliyobaki ya kichwa ina sehemu ya SequenceNumber - nambari ya mlolongo ya sehemu, ambayo inafuatilia mpangilio wa pakiti na upotezaji wao; Sehemu za Stempu ya Muda - msimbo wa ulandanishi unaoonyesha muda wa sampuli ya kwanza iliyosimbwa katika upakiaji, stempu hii inatumiwa na vibafa vya urejeshaji wa maingiliano ili kuondoa upotevu wa ubora unaosababishwa na utofauti wa kuchelewa; sehemu chanzo cha ulandanishi SSRC - nambari ya kiholela ambayo hutofautisha kipindi kimoja cha RTP kutoka kingine, ili kuunda uwezo wa kuzidisha. Baada ya sehemu isiyobadilika ya kichwa cha RTP, hadi sehemu 15 thelathini na mbili za CSRC zinaweza kuongezwa zinazotambua vyanzo vya data.
Hebu tueleze utaratibu wa kuanzisha kikao cha RTP. Itifaki huanzisha kwamba trafiki ya aina tofauti hupitishwa katika vikao tofauti vya mawasiliano. Kuanzisha kikao, ni muhimu kuamua jozi ya anwani za usafiri wa marudio i.e. anwani moja ya mtandao na bandari mbili za RTP na RTCP. Kwa hivyo, kwa mkutano wa video, ni muhimu kusambaza sauti na video katika vikao tofauti na bandari tofauti za lengwa. Usafirishaji wa aina tofauti za trafiki kwa kutumia kuingilia katika kikao kimoja kunaweza kusababisha matatizo yafuatayo:
- wakati wa kubadilisha moja ya aina za trafiki, haiwezekani kuamua ni parameter gani katika kikao inahitaji kubadilishwa na thamani mpya;
- kuanzisha kikao, muda mmoja tu wa wakati hutumiwa, na wakati wa kusambaza trafiki tofauti, kila aina itakuwa na muda wake, na zitatofautiana;
- Kichanganyaji cha RTP hakiwezi kuchanganya mitiririko iliyoingiliana ya aina tofauti za trafiki kwenye mkondo mmoja;
- maambukizi ya aina kadhaa za trafiki katika kikao kimoja cha RTP haiwezekani kwa sababu zifuatazo: matumizi ya njia tofauti za mtandao au usambazaji wa rasilimali za mtandao; kupokea kikundi kidogo cha data ya media titika inapohitajika, kwa mfano, sauti tu ikiwa ishara ya video inazidi kipimo data kinachopatikana; utekelezaji wa wasikilizaji ambao hutumia michakato tofauti kwa aina tofauti za trafiki, wakati utumiaji wa vipindi tofauti vya RTP huruhusu utekelezaji wa michakato moja na mingi.

Hata hivyo, RTP (Itifaki ya Usafiri wa Wakati Halisi) na UDP (Itifaki ya Datagram ya Mtumiaji) haihakikishi ubora, yaani, haifanyi kazi na QoS (Ubora wa Huduma). Kwa hiyo, itifaki ya RTP inasaidiwa na Itifaki ya Udhibiti wa Usafiri wa Wakati Halisi (RTCP), ambayo hutoa maelezo ya ziada kuhusu hali ya kikao cha mawasiliano cha RTP.
Itifaki ya RTCP hufanya kazi kuu nne:
I. Kazi kuu ya itifaki ya RTCP ni kutoa maoni ili kuhakikisha ubora wa utumaji data. Maoni yanaweza kuwa muhimu moja kwa moja yanapotumiwa kwa uwasilishaji wa usimbaji unaobadilika. Pia, unapotumia utangazaji mwingi wa IP, ni muhimu sana kwa wapokeaji kugundua makosa wakati wa kutuma ujumbe (pakiti). Utumaji ujumbe wenye ripoti za mapokezi huruhusu upande wa utumaji kubainisha sababu ya kutofaulu kwa utumaji ujumbe, kama hiyo itatokea.
II. RTCP ina kitambulisho cha safu ya usafiri kisichobadilika cha chanzo cha RTP, kinachoitwa "jina la kisheria" au "Jina". Kwa kuwa kitambulishi cha SSRC kinaweza kubadilika ikiwa migongano itapatikana, mpokeaji anahitaji thamani ya Cname ili kufuatilia kila mshiriki. Wapokeaji pia hutumia Cname kupanga mitiririko mingi ya data kutoka kwa mshiriki mmoja wakati wa kuanzisha vipindi vingi kwa wakati mmoja, kwa mfano, kusawazisha chaneli za sauti na video wakati wa kusambaza video na sauti.
III. Kazi mbili zilizo hapo juu zinadhania kuwa washiriki wote katika vipindi wametuma pakiti za RTCP, kwa hivyo ni lazima kiwango cha utumaji kidhibitiwe ili RTP iweze kuanzisha vipindi na idadi kubwa ya watumiaji. Wakati kila mshiriki anasambaza pakiti zake za udhibiti kwa kila mtu mwingine, mshirika yeyote anaweza kuamua kwa kujitegemea jumla ya idadi ya washiriki katika kipindi. Hii ni muhimu kwa mahesabu ya viwango vya upitishaji ujumbe wa RTCP.
IV. Chaguo hili la kukokotoa hutumika kupitisha maelezo ya chini kabisa ya udhibiti yanayohitajika, kama vile kitambulisho cha mshiriki, ambacho kinatumiwa na GUI. Kipengele hiki kinatumika kwa vipindi vinavyodhibitiwa kwa urahisi ambapo watumiaji huingia na kutoka bila mazungumzo sahihi ya vigezo na sifa. RTCP hutumika kama njia rahisi ya kuwasiliana na washiriki wote, lakini haiauni mahitaji yote ya mawasiliano ya programu.
Katika mitandao ya IP inayotumia utangazaji anuwai, kazi moja, mbili na tatu ni za lazima wakati wa kutumia vipindi vya RTP. Matumizi yao pia yanapendekezwa kwa maambukizi katika mitandao na mazingira mengine. Leo, inashauriwa kuwa watengenezaji wa programu za RTP watumie zana zinazowawezesha kufanya kazi katika hali ya multicast, na si tu katika hali ya unicast.
Wacha tuzingatie muundo wa pakiti za RTCP.
Kiwango cha itifaki kinafafanua aina kadhaa za pakiti za RTCP. RTCP imeundwa kusambaza habari za huduma:
sr: Ripoti ya mtumaji. Muhimu kwa takwimu za mapokezi na uwasilishaji wa washiriki wa kikao ambao ni watumaji wanaofanya kazi moja kwa moja;
rr: Ripoti ya mpokeaji. Inahitajika kwa takwimu kutoka kwa washiriki ambao sio wapokeaji;
sdes: Inaelezea chanzo, inajumuisha Cname;
kwaheri: Hutumika kuonyesha mwisho (kutoka) wa kikao;
programu: Kazi maalum za maombi;
Kila pakiti ya RTCP ina sehemu ya mara kwa mara, kama kwa itifaki ya RTP, ambayo hutumiwa na pakiti za RTP, ikifuatiwa na sehemu ambazo zinaweza kutofautiana kwa urefu kulingana na aina ya pakiti, lakini ni nyingi ya biti 32. Mahitaji ya upangaji na sehemu ya urefu katika sehemu isiyobadilika ya kichwa huletwa ili kufanya pakiti za RTCP ziunganishwe. Pakiti nyingi za RTCP zinaweza kuunganishwa pamoja bila kutambulisha vitenganishi vyovyote ili kutoa pakiti ya mchanganyiko wa RTCP ambayo hutumwa kupitia itifaki ya usafiri wa kiwango cha chini kama vile UDP. Hakuna counter maalum kwa pakiti za RTCP binafsi, kwa kuwa itifaki ya kiwango cha chini itabainisha urefu wa jumla na kuamua mwisho wa pakiti ya composite.

Umbizo la pakiti ya ujumbe wa mtumaji wa RTCP ni kama ifuatavyo, kama inavyoonyeshwa kwenye kielelezo hapo juu.

Pakiti za RTCP zinakabiliwa na ukaguzi ufuatao wa usafi.
- Sehemu ya toleo la RTP lazima iwe sawa na 2.
- Sehemu ya aina ya data ya pakiti ya kwanza ya RTCP katika pakiti ya mchanganyiko lazima iwe SR au RR.
- Kibiti cha pedi (P) lazima kiwe sufuri kwa pakiti ya kwanza ya pakiti ya RTCP ya mchanganyiko, kwa kuwa pedi inaweza tu kuwepo katika ya mwisho.
- Urefu wa sehemu za pakiti za RTCP lazima ziongezwe hadi urefu wa jumla wa pakiti ya mchanganyiko.

Programu za kisasa haziwezi kumudu pakiti zao kuchelewa kufika. Itifaki mbili (RTP na PSVP) huhakikisha utoaji kwa wakati huku zikidumisha ubora wa huduma.

Ukuaji unaoendelea wa Mtandao na mitandao ya kibinafsi huweka mahitaji mapya kwenye bandwidth. Programu za seva ya mteja ni bora zaidi kuliko Telnet kulingana na kiasi cha data iliyohamishwa. Mtandao Wote wa Ulimwenguni umesababisha ongezeko kubwa la grafu ya habari ya picha. Leo, kwa kuongeza, maombi ya sauti na video huweka mahitaji yao maalum kwenye mitandao iliyojaa tayari.

Ili kukidhi mahitaji haya yote, kuongeza uwezo wa mtandao pekee haitoshi. Kinachohitajika sana ni usimamizi mzuri wa ratiba na udhibiti wa mzigo wa kazi.

Kihistoria, mitandao inayotegemea IP imetoa programu zote huduma rahisi tu ya kutoa data kila inapowezekana. Walakini, mahitaji yamebadilika kwa wakati. Mashirika ambayo yametumia mamilioni ya dola kusakinisha mtandao unaotegemea IP ili kusafirisha data kati ya LAN sasa yanapata kuwa usanidi kama huo hauwezi kuauni vyema programu mpya za utangazaji wa maudhui anuwai ya wakati halisi.

ATM ndiyo teknolojia pekee ya mtandao ambayo iliundwa awali ili kusaidia trafiki ya kawaida ya TCP na UDP pamoja na trafiki ya wakati halisi. Hata hivyo, kuzingatia ATM kunamaanisha ama kuunda miundombinu mpya ya mtandao kwa trafiki ya wakati halisi au kuchukua nafasi ya usanidi uliopo wa msingi wa IP, ambao wote watakuwa ghali kabisa.

Kwa hivyo, hitaji la kusaidia aina nyingi za trafiki na ubora tofauti wa mahitaji ya huduma ndani ya usanifu wa TCP/IP ni kubwa sana. Zana mbili muhimu zimeundwa kutatua tatizo hili: Itifaki ya Usafiri wa Wakati Halisi (RTP) na Itifaki ya Kuhifadhi Rasilimali (RSVP).

RTP huhakikisha uwasilishaji wa data kwa mpokeaji mmoja au zaidi kwa kuchelewa ndani ya mipaka maalum. Hii inamaanisha kuwa data inaweza kuchezwa kwa wakati halisi. RSVP inaruhusu mifumo ya mwisho kuhifadhi rasilimali za mtandao ili kupata ubora unaohitajika wa huduma, hasa rasilimali za trafiki ya wakati halisi kupitia itifaki ya RTP.

Itifaki ya safu ya usafiri inayotumiwa sana ni TCP. Ingawa TCP inaweza kusaidia aina mbalimbali za programu zilizosambazwa, haifai kwa programu za wakati halisi.

Katika programu za wakati halisi, mtumaji hutengeneza mtiririko wa data kwa kasi isiyobadilika, na mpokeaji(wa)pokeaji lazima atoe data hiyo kwa programu kwa kiwango sawa. Programu kama hizo ni pamoja na mikutano ya sauti na video, usambazaji wa video moja kwa moja (kwa uchezaji mara moja), nafasi za kazi zinazoshirikiwa, uchunguzi wa matibabu wa mbali, simu ya kompyuta, uigaji mwingiliano uliosambazwa, michezo ya kubahatisha na ufuatiliaji wa wakati halisi.

Kutumia TCP kama itifaki ya usafiri kwa programu hizi hakuwezekani kwa sababu kadhaa. Kwanza, itifaki hii inaruhusu tu muunganisho kuanzishwa kati ya ncha mbili na kwa hiyo haifai kwa uwasilishaji wa multicast. Inaruhusu utumaji upya wa sehemu zilizopotea ambazo hufika wakati programu ya wakati halisi haijazitarajia tena. Zaidi ya hayo, TCP haina utaratibu unaofaa wa kuhusisha maelezo ya saa na sehemu, ambayo pia ni hitaji la utumaji programu katika wakati halisi.

Itifaki nyingine ya safu ya usafiri inayotumiwa sana, UDP haina mbili za kwanza

mapungufu (viunganisho vya uhakika na uhamishaji wa sehemu zilizopotea), lakini haitoi habari muhimu ya maingiliano. Kwa hivyo, UDP yenyewe haina zana za madhumuni ya jumla ya programu za wakati halisi.

Ingawa kila programu ya wakati halisi inaweza kuwa na njia zake za kuauni utumaji wa wakati halisi, zina mfanano mwingi unaofanya kufafanua itifaki moja kuhitajika sana. Itifaki ya kawaida ya aina hii ni RTP, iliyofafanuliwa katika RFC 1889.

Katika mazingira ya kawaida ya muda halisi, mtumaji huzalisha pakiti kwa kiwango cha mara kwa mara. Wanatumwa kwao kwa vipindi vya kawaida, husafiri kupitia mtandao na hupokelewa na mpokeaji, ambaye huzalisha data kwa wakati halisi baada ya kupokea.

Hata hivyo, kutokana na tofauti ya muda wa kusubiri wakati pakiti zinasafiri kwenye mtandao, hufika kwa vipindi visivyo kawaida. Ili kulipa fidia kwa athari hii, pakiti zinazoingia zimehifadhiwa, zimehifadhiwa kwa muda, na kisha hutolewa kwa kiwango cha mara kwa mara kwa programu inayozalisha pato. Ili mpango huu ufanye kazi, kila pakiti imewekwa muhuri wa muda ili mpokeaji aweze kucheza tena data inayoingia kwa kasi sawa na ya mtumaji.

RTP inasaidia uhamishaji wa data kwa wakati halisi kati ya washiriki wengi wa kipindi. (Kipindi ni muunganisho wa kimantiki kati ya watumiaji wawili au zaidi wa RTP ambao hudumishwa kwa muda wa uhamishaji data. Mchakato wa kufungua kipindi uko nje ya mawanda ya RTP.)

Ingawa RTP inaweza kutumika kwa uwasilishaji wa wakati halisi wa unicast, nguvu yake iko katika usaidizi wake wa utumaji wa utangazaji anuwai. Ili kufanikisha hili, kila kizuizi cha data cha RTP kina kitambulisho cha mtumaji kinachoonyesha ni mshiriki gani anazalisha data. Vizuizi vya data vya RTP pia vina muhuri wa wakati ili data iweze kuchezwa tena kwa vipindi sahihi na mwisho wa kupokea.

Kwa kuongeza, RTP inafafanua muundo wa malipo ya data iliyopitishwa. Kuhusiana moja kwa moja na hii ni dhana ya maingiliano, ambayo mchanganyiko, utaratibu wa utangazaji wa RTP, unawajibika kwa sehemu. Kwa kupokea mitiririko ya pakiti za RTP kutoka kwa chanzo kimoja au zaidi, inazichanganya na kutuma mtiririko mpya wa pakiti za RTP kwa mpokeaji mmoja au zaidi. Mchanganyiko unaweza tu kuchanganya data na pia kubadilisha muundo wake.

Mfano wa maombi ya kichanganyaji ni kuchanganya vyanzo vingi vya sauti. Kwa mfano, tuseme kwamba sehemu ya mifumo katika kipindi fulani cha sauti kila moja itazalisha mtiririko wake wa RTP. Mara nyingi, ni chanzo kimoja tu kinachofanya kazi, ingawa wakati mwingine vyanzo kadhaa "huzungumza" kwa wakati mmoja.

Ikiwa mfumo mpya unataka kushiriki katika kipindi, lakini kiunga chake kwenye mtandao hakina uwezo sahihi wa kutosha wa kuunga mkono mitiririko yote ya RTP, basi kichanganyaji hupokea mitiririko hiyo yote, inaichanganya kuwa moja, na kupitisha mwisho kwa mjumbe mpya wa kikao. Wakati wa kupokea mitiririko mingi, kichanganyaji huongeza maadili ya urekebishaji wa msimbo wa mapigo. Kichwa cha RTP kinachozalishwa na kichanganyaji kinajumuisha vitambulisho vya mtumaji ambaye data yake iko kwenye pakiti.

Kifaa rahisi huzalisha pakiti moja ya RTP inayotoka kwa kila pakiti ya RTP inayoingia. Utaratibu huu, unaoitwa mfasiri, unaweza kubadilisha umbizo la data kwenye pakiti au kutumia seti tofauti ya itifaki za kiwango cha chini kuhamisha data kutoka kikoa kimoja hadi kingine. Kwa mfano, mpokeaji anayetarajiwa asiweze kuchakata mawimbi ya video ya kasi ya juu inayotumiwa na washiriki wengine kwenye kipindi. Kisha mfasiri hubadilisha video hadi umbizo la ubora wa chini ambalo halihitaji kiwango cha juu cha uhamishaji data.

Kila pakiti ya RTP ina kichwa kikuu, na ikiwezekana sehemu za ziada za programu mahususi. Mchele. 4 inaonyesha muundo wa kichwa kikuu. Oktet 12 za kwanza zinajumuisha nyanja zifuatazo:

shamba la toleo (2 bits): toleo la sasa - pili;
sehemu ya kuweka pedi (biti 1): Sehemu hii inaashiria uwepo wa pweza mwishoni mwa mzigo. (Padding hutumika wakati programu inahitaji saizi ya upakiaji kuwa mgawo wa, kwa mfano, biti 32.) Katika kesi hii, oktet ya mwisho inabainisha idadi ya pweza za pedi;
uga wa upanuzi wa kichwa (kidogo 1): uga huu unapowekwa, kichwa kikuu kinafuatwa na kichwa kimoja cha ziada kinachotumiwa katika viendelezi vya RTP vya majaribio;
idadi ya sehemu ya watumaji (biti 4): sehemu hii ina idadi ya vitambulishi vya mtumaji ambao data yao iko kwenye pakiti, na vitambulisho vyenyewe vikifuata kichwa kikuu;
sehemu ya alama (biti 1): Maana ya biti ya alama inategemea aina ya malipo. Alama kidogo hutumiwa kuonyesha mipaka ya mtiririko wa data. Kwa upande wa video, inabainisha mwisho wa fremu. Katika kesi ya sauti, inabainisha mwanzo wa hotuba baada ya muda wa kimya;
Sehemu ya Aina ya Upakiaji (biti 7): Sehemu hii inabainisha aina ya upakiaji na umbizo la data, ikiwa ni pamoja na mbano na usimbaji fiche. Katika hali ya utulivu, mtumaji hutumia aina moja tu ya upakiaji wakati wa kipindi, lakini anaweza kuibadilisha kulingana na mabadiliko ya hali ikiwa imeashiriwa na Itifaki ya Udhibiti wa Usafiri wa Wakati Halisi;
sehemu ya nambari ya mfuatano (biti 16): kila chanzo huanza kuhesabu pakiti kwa nambari nasibu, ambayo inaongezwa kwa moja kwa kila pakiti ya data ya RTP iliyotumwa. Hii hukuruhusu kugundua upotezaji wa pakiti na kuamua mpangilio wa pakiti zilizo na muhuri wa wakati sawa. Pakiti nyingi zinazofuatana zinaweza kuwa na muhuri wa muda sawa ikiwa kimantiki zilitoka kwa papo hapo (kwa mfano, pakiti za fremu sawa ya video);
sehemu ya muhuri wa wakati (biti 32): Hii hurekodi hatua kwa wakati ambapo oktet ya data ya upakiaji wa kwanza ilitolewa. Vipimo ambavyo muda umebainishwa katika sehemu hii hutegemea aina ya malipo. Thamani inabainishwa na saa ya ndani ya mtumaji;
Sehemu ya Kitambulisho cha Chanzo cha Sawazisha: Nambari inayozalishwa bila mpangilio maalum ambayo hutambulisha chanzo ndani ya kipindi.

Kichwa kikuu kinaweza kufuatiwa na sehemu moja au zaidi zinazowatambulisha watumaji ambao data yao iko kwenye mzigo wa malipo. Vitambulisho hivi huingizwa na kichanganyaji.

Itifaki ya RTP inatumika tu kusambaza data ya mtumiaji - kwa kawaida matangazo mengi - kwa washiriki wote kwenye kipindi. Itifaki tofauti ya Kudhibiti Usafiri wa Wakati Halisi (RTCP) hufanya kazi na maeneo mengi ili kutoa maoni kwa watumaji wa RTP na washiriki wengine wa kipindi.

RTCP hutumia itifaki ya msingi ya usafiri kama RTP (kawaida UDP), lakini nambari ya bandari tofauti. Kila mshiriki wa kipindi hutuma pakiti ya RTCP mara kwa mara kwa washiriki wengine wote wa kipindi. RFC 1889 inaeleza kazi tatu zinazofanywa na RTCP.

Kazi ya kwanza ni kutoa ubora wa huduma na maoni katika kesi ya overload. Kwa sababu pakiti za RTCP ni za utangazaji anuwai, washiriki wote katika kipindi wanaweza kutathmini jinsi washiriki wengine wanavyofanya na kupokea vizuri. Ujumbe wa mtumaji huruhusu wapokeaji kutathmini kasi ya data na ubora wa utumaji. Barua pepe za wapokeaji zina maelezo kuhusu matatizo wanayokumbana nayo, ikiwa ni pamoja na kupoteza pakiti na mshtuko mwingi. Kwa mfano, kasi ya biti ya programu ya sauti/video inaweza kupunguzwa ikiwa laini haitoi ubora unaohitajika wa huduma kwa kasi fulani ya biti.

Maoni kutoka kwa wapokeaji pia ni muhimu kwa kutambua makosa katika usambazaji.

Kwa kuchanganua ujumbe kutoka kwa washiriki wote katika kipindi, msimamizi wa mtandao anaweza kubaini kama tatizo fulani linahusu mshiriki mmoja au ni la kawaida.

Kazi kuu ya pili ya RTCP ni kitambulisho cha mtumaji. Pakiti za RTCP zina maelezo ya kawaida ya maandishi ya mtumaji. Hutoa maelezo zaidi kuhusu mtumaji wa pakiti za data kuliko kitambulisho cha chanzo cha kusawazisha kilichochaguliwa kwa nasibu. Pia husaidia mtumiaji kutambua nyuzi za vipindi tofauti. Kwa hivyo, huruhusu mtumiaji kuamua kuwa vipindi tofauti vya sauti na video vinafunguliwa kwa wakati mmoja.

Kazi ya tatu ni kukadiria ukubwa wa kikao na ukubwa. Ili kuhakikisha ubora wa huduma na maoni kwa madhumuni ya kudhibiti msongamano, na pia kwa madhumuni ya kutambua mtumaji, washiriki wote hutuma pakiti za RTCP mara kwa mara. Mzunguko wa maambukizi ya pakiti hizi hupungua kadri idadi ya washiriki inavyoongezeka.

Kwa idadi ndogo ya washiriki, pakiti moja ya RTCP hutumwa kwa zaidi ya kila sekunde tano. RFC 1889 inafafanua algoriti ambapo washiriki hupunguza kiwango cha pakiti za RTCP kulingana na jumla ya idadi ya washiriki. Lengo ni kuweka trafiki ya RTCP isizidi 5% ya jumla ya trafiki ya kipindi.

Madhumuni ya mtandao wowote ni kuwasilisha data kwa mpokeaji yenye ubora wa huduma iliyohakikishwa, ikiwa ni pamoja na matokeo, muda wa kusubiri na ustahimilivu wa mabadiliko ya muda. Kadiri idadi ya watumiaji na programu inavyoongezeka, inakuwa vigumu zaidi kuhakikisha huduma bora.

Kujibu tu juu ya upakiaji haitoshi tena. Kinachohitajika ni chombo ambacho kinaweza kusaidia kuzuia msongamano kabisa, yaani, kuwezesha programu kuhifadhi rasilimali za mtandao kulingana na ubora wa huduma unaohitajika.

Hatua za kuzuia ni muhimu kwa upitishaji wa unicast na upeperushaji anuwai. Katika unicast, maombi mawili yanajadili kiwango maalum cha ubora wa huduma kwa kipindi fulani. Ikiwa mtandao umejaa sana, huenda usiweze kutoa ubora unaohitajika wa huduma. Katika hali hii, maombi yatalazimika kuahirisha kikao hadi nyakati bora au kujaribu kupunguza ubora wa mahitaji ya huduma, ikiwezekana.

Suluhisho katika kesi hii ni kwa maombi ya unicast kuhifadhi rasilimali ili kutoa kiwango kinachohitajika cha huduma. Vipanga njia kwenye njia iliyokusudiwa kisha kutenga rasilimali (kwa mfano, nafasi ya foleni na baadhi ya uwezo wa kiungo kinachotoka). Ikiwa kipanga njia hakiwezi kutenga rasilimali kwa sababu ya ahadi za hapo awali, inaarifu programu. Katika hali hii, programu inaweza kujaribu kuanzisha kipindi kingine chenye ubora wa chini wa mahitaji ya huduma au kukipanga upya hadi tarehe ya baadaye.

Multicast inatoa changamoto ngumu zaidi za kuhifadhi rasilimali. Inaongoza kwa uzalishaji wa kiasi kikubwa cha grafu ya mtandao - katika kesi ya maombi kama vile video, kwa mfano, au wakati kuna kundi kubwa na kutawanywa la wapokeaji. Walakini, trafiki kutoka kwa chanzo cha utangazaji anuwai inaweza kimsingi kupunguzwa kwa kiasi kikubwa.

Kuna sababu mbili za hii. Kwanza, baadhi ya washiriki wa kikundi huenda wasihitaji data kuwasilishwa kutoka chanzo fulani katika muda fulani. Kwa hivyo, washiriki wa kikundi kimoja wanaweza kupokea habari wakati huo huo kupitia njia mbili (kutoka kwa vyanzo viwili), lakini mpokeaji anaweza kuwa na hamu ya kupokea chaneli moja tu.

Pili, baadhi ya wanakikundi wanaweza kuchakata sehemu tu ya habari inayotumwa na mtumaji. Kwa mfano, mtiririko wa video unaweza kuwa na vipengele viwili: kimoja chenye ubora wa chini wa picha na kingine chenye ubora wa juu wa picha. Umbizo hili lina idadi ya algoriti za ukandamizaji wa video: zinatoa kijenzi cha msingi na picha ya ubora wa chini na kipengee cha ziada kilicho na azimio la juu zaidi.

Baadhi ya vipokezi huenda visiwe na nguvu ya kutosha ya kuchakata vipengele vya msongo wa juu, au vinaweza kuunganishwa kwenye mtandao kupitia subnet au kiungo ambacho hakina uwezo wa kutosha wa kubeba mawimbi kamili.

Uhifadhi wa rasilimali huruhusu vipanga njia kubaini mapema kama vinaweza kuwasilisha trafiki ya upeperushaji anuwai kwa wapokeaji wote.

Katika majaribio ya awali ya kutekeleza uhifadhi wa rasilimali na katika relay ya sura na mbinu za ATM, rasilimali muhimu zinaombwa na chanzo cha mkondo wa data. Njia hii ni ya kutosha katika kesi ya maambukizi ya unicast kwa sababu maombi ya kutuma hupeleka data kwa kiwango fulani, na kiwango kinachohitajika cha ubora wa huduma kinajengwa katika muundo wa maambukizi.

Hata hivyo, mbinu hii haiwezi kutumika kwa multicast. Washiriki wa timu tofauti wanaweza kuwa na mahitaji tofauti ya rasilimali. Ikiwa mtiririko asili unaweza kugawanywa katika mipasho midogo, basi baadhi ya washiriki wa kikundi wanaweza kutaka kupokea moja tu kati yao. Hasa, baadhi ya wapokeaji wataweza tu kuchakata kijenzi cha video cha ubora wa chini. Au ikiwa watumaji kadhaa watatangaza kwa kikundi kimoja, basi mpokeaji anaweza kuchagua mtumaji mmoja tu au baadhi yao. Hatimaye, ubora wa mahitaji ya huduma ya wapokeaji tofauti unaweza kutofautiana kulingana na vifaa vya kutoa, nguvu ya kichakataji na kasi ya kiungo.

Kwa sababu hii, uhifadhi wa rasilimali na mpokeaji unaonekana kuwa bora. Watumaji wanaweza kupeana vipanga njia sifa za jumla za trafiki (kama vile kiwango cha data na tofauti), lakini wapokeaji lazima wabaini kiwango cha ubora wa huduma wanachohitaji. Vipanga njia basi hujumlisha maombi ya ugawaji wa rasilimali katika sehemu za kawaida za mti wa usambazaji.

RSVP inategemea dhana tatu zinazohusiana na mtiririko wa data: kipindi, vipimo vya mtiririko, na vipimo vya kichujio. Kipindi ni mtiririko wa data unaotambuliwa na lengwa lake. Kumbuka kuwa dhana hii ni tofauti na ile ya kipindi cha RTP, ingawa vipindi vya RSVP na RTP vinaweza kuwa na mawasiliano ya moja kwa moja. Mara tu kipanga njia huhifadhi rasilimali kwa lengwa mahususi, huchukulia hili kama mwanzo wa kipindi na kutenga rasilimali kwa muda wa kipindi hicho.

Ombi la kuhifadhi nafasi kutoka kwa mfumo wa mwisho wa kupokea, unaoitwa kielezi cha mtiririko, lina vipimo vya mtiririko na kichujio. Uainishaji wa mtiririko huamua ubora unaohitajika wa huduma na hutumiwa na nodi kuweka vigezo vya mpangilio wa pakiti. Kipanga njia hupeleka mbele pakiti zilizo na seti fulani ya mapendeleo kulingana na vipimo vya mtiririko wa sasa.

Vipimo vya Kichujio inafafanua seti ya vifurushi ambavyo rasilimali zinaombwa. Pamoja na kipindi, inafafanua seti ya pakiti (au mtiririko) ambayo ubora unaohitajika wa huduma lazima utolewe. Pakiti zingine zozote zinazotumwa mahali hapa huchakatwa kwa kiwango ambacho mtandao unaweza kufanya hivyo.

RSVP haifafanui maudhui ya vipimo vya mtiririko, inatuma ombi tu. Vipimo vya mtiririko kwa kawaida hujumuisha darasa la huduma, Rspec (R inawakilisha hifadhi) na Tspec (T inawakilisha trafiki). Vigezo vingine viwili ni seti ya nambari. Kigezo cha Rspec kinafafanua ubora unaohitajika wa huduma, na parameter ya Tspec inaelezea mtiririko wa data. Yaliyomo katika Rspec na Tspec ni wazi kwa RSVP.

Kimsingi, vipimo vya kichungi huelezea sehemu ndogo ya pakiti kutoka kwa kikao kimoja (yaani, pakiti hizo ambazo marudio yake yameamuliwa na kipindi hicho). Kwa mfano, vipimo vya kichujio vinaweza kutambua watumaji mahususi pekee, au vinaweza kutambua itifaki au pakiti ambazo sehemu zake za kichwa cha itifaki zinalingana na zile zilizobainishwa.

Mchele. 3 inaonyesha uhusiano kati ya kipindi, vipimo vya mtiririko, na vipimo vya kichujio. Kila pakiti inayoingia ni ya angalau kipindi kimoja na inazingatiwa kulingana na mtiririko wa kimantiki wa kipindi hicho. Ikiwa pakiti sio ya kikao chochote, basi inatolewa mradi tu kuna rasilimali za bure.

Ugumu kuu na RSVP ni multicast. Mfano wa usanidi wa multicast unaonyeshwa kwenye Mtini. 6. Mpangilio huu unajumuisha ruta nne. Kiungo kati ya vipanga njia viwili, vinavyowakilishwa na mstari, kinaweza kuwa kiungo cha moja kwa moja au subnet. Majeshi matatu - Gl, G2 na G3 - ni ya kundi moja na kupokea datagrams na anwani ya kikundi sambamba. Data kwa anwani hii inatumwa na wapangishi wawili - S1 na S2. Mstari mwekundu unalingana na mti wa kuelekeza kwa S1 na kikundi hiki, na mstari wa bluu kwa S2 na kikundi hiki. Mistari yenye mishale inaonyesha mwelekeo wa maambukizi ya pakiti kutoka S1 (nyekundu) na kutoka S2 (bluu).

Takwimu inaonyesha kuwa ruta zote nne lazima zifahamu uhifadhi wa rasilimali wa kila mpokeaji. Kwa hivyo, maombi ya ugawaji wa rasilimali hueneza nyuma kupitia mti wa kuelekeza.

RSVP hutumia aina mbili kuu za ujumbe: Resv na Njia. Ujumbe wa Resv huzalishwa na wapokeaji na kuenezwa juu ya mti, na kila nodi njiani ikichanganya na kuunganisha tena pakiti kutoka kwa vipokezi tofauti kila inapowezekana. Ujumbe huu husababisha kipanga njia kuingia katika hali ya uhifadhi wa rasilimali kwa kipindi hicho (anwani ya matangazo mengi). Hatimaye, jumbe zote za Resv zilizojumlishwa huwafikia wapangishi wanaotuma. Kulingana na habari iliyopokelewa, huweka vigezo sahihi vya udhibiti wa ratiba kwa hop ya kwanza.

Mchele. 7 inaonyesha mtiririko wa ujumbe wa Resv. Tafadhali kumbuka: ujumbe umeunganishwa; kwa hivyo, ni ujumbe mmoja tu unaotumwa kwenye tawi lolote la mti wa uwasilishaji uliojumuishwa. Hata hivyo, ni lazima jumbe hizi zitumwe tena mara kwa mara ili kuongeza muda wa kuhifadhi rasilimali.

Ujumbe wa Njia hutumiwa kueneza habari kuhusu njia ya kurudi. Itifaki zote za kisasa za uelekezaji wa onyesho nyingi huunga mkono tu njia ya moja kwa moja katika mfumo wa mti wa uenezi (chini kutoka kwa mtumaji). Lakini ujumbe wa Resv lazima usambazwe kwa mwelekeo wa kinyume kupitia vipanga njia vyote vya kati kwa wapangishi wote wanaotuma.

Kwa kuwa itifaki ya uelekezaji haitoi maelezo ya njia ya kurudi nyuma, inabebwa na RSVP katika ujumbe wa Njia. Mpangishi yeyote anayetaka kuwa mtumaji hutuma ujumbe wa Njia kwa washiriki wote wa kikundi. Njiani, kila kipanga njia na kila kipangishi lengwa huingia katika hali ya njia inayoonyesha kwamba pakiti za mtumaji huyo zinapaswa kutumwa kwa nodi ya upitishaji ambapo pakiti ilipokelewa. Mchele. 5 inaonyesha kuwa pakiti za Njia hupitishwa kwa njia sawa na pakiti za data.

Hebu tuangalie jinsi itifaki ya RSVP inavyofanya kazi. Kwa mtazamo wa mwenyeji, utendakazi wa itifaki una hatua zifuatazo (hatua mbili za kwanza katika mlolongo huu wakati mwingine ziko katika mpangilio wa nyuma).

Mpokeaji anajiunga na kikundi cha utangazaji anuwai kwa kutuma ujumbe wa IGMP kwa kipanga njia cha jirani.
Mtumaji anayetarajiwa hutuma ujumbe kwa anwani ya kikundi.
Mpokeaji hupokea ujumbe wa Njia inayomtambulisha mtumaji.
Sasa kwa kuwa mpokeaji ana maelezo ya njia ya kurudi nyuma, inaweza kutuma ujumbe wa Resv na maelezo ya mtiririko.
Ujumbe wa resv hupitishwa kupitia mtandao hadi kwa mtumaji.
Mtumaji huanza usambazaji wa data.
Mpokeaji huanza kupokea pakiti za data.

Njia za jana za kufanya kazi na idadi kubwa ya graphics hazifai kabisa kwa mifumo ya kisasa. Bila zana mpya, haiwezekani kukidhi mahitaji yanayokua ya uwasilishaji wa data kutokana na ukuaji wa kiasi cha data, kuenea kwa programu za wakati halisi na usambazaji wa multicast. RTP na RSVP hutoa msingi thabiti kwa kizazi kijacho cha LAN.

Mfano wa utumizi halisi wa itifaki hizi ni modeli ya VoIP (Voice over IP) - utumaji sauti kupitia mitandao ya IP, ambayo imefafanuliwa katika kiwango cha H.232 na hutoa utumaji wa taarifa za sauti, video na data kupitia mtandao wa IP. . Katika kesi hii, itifaki ya wakati halisi ya RTP hutumiwa kuanzisha uunganisho, na itifaki ya RSVP hutumiwa kuhifadhi rasilimali za mtandao.

Mojawapo ya mielekeo muhimu zaidi katika mageuzi ya mawasiliano ya kisasa ya simu ni ukuzaji wa simu za IP - aina ya teknolojia mpya zinazohakikisha upitishaji wa ujumbe wa media titika (hotuba, data, video) kupitia habari na mitandao ya kompyuta (ICNs), iliyojengwa kwenye msingi wa IP (Itifaki ya Mtandao), katika kujumuisha mitandao ya kompyuta ya ndani, ya shirika, ya kimataifa na Mtandao. Wazo la simu ya IP ni pamoja na simu ya mtandao, ambayo inaruhusu kupanga mawasiliano ya simu kati ya watumiaji wa mtandao, kati ya wanachama wa mitandao ya simu ya umma (PSTN) kupitia mtandao, pamoja na mawasiliano ya simu kati ya PSTN na wanachama wa mtandao kwa kila mmoja.

Simu ya IP ina idadi ya faida zisizo na shaka zinazohakikisha maendeleo yake ya haraka na upanuzi wa soko la simu za kompyuta. Inawanufaisha watumiaji wa mwisho, ambao wanapewa huduma ya simu kwa malipo ya chini kabisa kwa kila dakika. Kwa makampuni yenye matawi ya mbali, teknolojia ya IP inawaruhusu kupanga mawasiliano ya sauti kwa kutumia mitandao iliyopo ya IP ya kampuni. Badala ya mitandao kadhaa ya mawasiliano, moja hutumiwa. Faida isiyo na shaka ya simu ya IP juu ya simu ya kawaida ni uwezo wa kutoa huduma za ziada kupitia matumizi ya kompyuta ya multimedia na maombi mbalimbali ya mtandao. Kwa hivyo, kwa kutumia simu ya IP, biashara na watu binafsi wanaweza kupanua uwezo wao wa mawasiliano ili kujumuisha mikutano ya hali ya juu ya video, kushiriki programu, zana za aina ya ubao mweupe, na kadhalika.

Je, ni viwango na itifaki gani za kimataifa zinazodhibiti vigezo vya msingi na algoriti za utendakazi wa maunzi na mawasiliano ya programu yanayotumika katika simu ya IP? Ni wazi, kama jina linavyopendekeza, teknolojia hii inategemea itifaki ya IP, ambayo, hata hivyo, haitumiki tu kwa simu: ilitengenezwa awali kwa ajili ya kusambaza data ya digital kwa mifumo ya habari iliyobadilishwa pakiti.

Katika mitandao ambayo haitoi ubora wa huduma iliyohakikishwa (hizi ni pamoja na mitandao iliyojengwa kwenye itifaki ya IP), pakiti zinaweza kupotea, mpangilio wa kuwasili kwao unaweza kubadilika, na data iliyopitishwa katika pakiti inaweza kupotoshwa. Ili kuhakikisha utoaji wa kuaminika wa habari zinazopitishwa chini ya hali hizi, taratibu mbalimbali za safu ya usafiri hutumiwa. Wakati wa kusambaza data ya digital, itifaki ya TCP (Itifaki ya Udhibiti wa Usambazaji) hutumiwa kwa kusudi hili. Itifaki hii inahakikisha utoaji wa data wa kuaminika na kurejesha utaratibu wa awali wa pakiti. Ikiwa hitilafu imegunduliwa kwenye pakiti au pakiti imepotea, taratibu za TCP hutuma ombi la uhamisho tena.

Kwa programu za mikutano ya sauti na video, ucheleweshaji wa pakiti una athari kubwa zaidi kwenye ubora wa mawimbi kuliko upotovu wa data mahususi. Tofauti za ucheleweshaji zinaweza kusababisha kusitisha. Programu kama hizo zinahitaji itifaki nyingine ya safu ya usafiri ambayo hutoa urejeshaji wa mlolongo wa asili wa pakiti, uwasilishaji wao bila kuchelewa kidogo, uchezaji wa wakati halisi kwa wakati uliobainishwa, utambuzi wa aina ya trafiki, mawasiliano ya kikundi au njia mbili. Itifaki hii ni itifaki ya usafiri wa wakati halisi ya RTP (Itifaki ya Usafiri wa Wakati Halisi). Itifaki hii inadhibiti uhamishaji wa data ya medianuwai kwenye pakiti kupitia IVS katika kiwango cha usafirishaji na inakamilishwa na itifaki ya udhibiti wa uhamishaji data wa wakati halisi RTCP (Itifaki ya Udhibiti wa Wakati Halisi). Itifaki ya RTCP, kwa upande wake, hutoa udhibiti wa utoaji wa vyombo vya habari, ubora wa udhibiti wa huduma, mawasiliano kuhusu washiriki katika kikao cha sasa cha mawasiliano, usimamizi na utambulisho, na wakati mwingine inachukuliwa kuwa sehemu ya itifaki ya RTP.

Machapisho mengi yaliyotolewa kwa simu ya IP yanabainisha kuwa vifaa vingi vya mtandao na programu maalum za teknolojia hii hutengenezwa kwa msingi wa Pendekezo la Sekta ya Udhibiti wa Mawasiliano ya Kimataifa (ITU-T) H.323 (pamoja na TAPI 3.0, NetMeeting 2.0, nk). .). H.323 inahusiana vipi na itifaki za RTP na RTCP? H.323 ni mfumo wa dhana pana unaojumuisha viwango vingine vingi, kila kimoja kikijumuisha vipengele tofauti vya uhamishaji taarifa. Vingi vya viwango hivi, kama vile viwango vya sauti na video vya kodeki, vinatumika sana sio tu katika simu za IP. Kuhusu itifaki za RTP/RTCP, zinaunda msingi wa kiwango cha H.323, zinalenga kutoa teknolojia ya IP, na zinaweka msingi wa shirika la simu ya IP. Nakala hii imejitolea kwa kuzingatia itifaki hizi.

Itifaki ya usafiri wa wakati halisi ya RTP hutoa uwasilishaji wa wakati halisi hadi wa mwisho wa data ya medianuwai kama vile sauti shirikishi na video. Itifaki hii inatekeleza utambuzi wa aina ya trafiki, nambari za mlolongo wa pakiti, na kufanya kazi nayo mihuri ya nyakati na udhibiti wa maambukizi.

Kumbuka kwamba RTP yenyewe haina utaratibu wowote wa kuhakikisha utumaji wa data kwa wakati na ubora wa huduma, lakini hutumia huduma za msingi ili kuhakikisha hili. Haizuii pakiti za nje, lakini haifikiri kwamba mtandao wa msingi ni wa kuaminika kabisa na hupeleka pakiti katika mlolongo sahihi. Nambari za mfuatano zilizojumuishwa katika RTP huruhusu mpokeaji kuunda upya mlolongo wa pakiti za mtumaji.

Vitengo vya data vya itifaki ya RTP/RTCP huitwa pakiti. Pakiti zinazozalishwa kwa mujibu wa itifaki ya RTP na zinazotumiwa kusambaza data ya multimedia huitwa pakiti za habari au pakiti za data, na pakiti zinazozalishwa kwa mujibu wa itifaki ya RTCP na kutumika kusambaza habari za huduma zinazohitajika kwa uendeshaji wa kuaminika wa teleconference huitwa pakiti za udhibiti au udhibiti wa pakiti. Pakiti ya RTP inajumuisha kichwa kisichobadilika, kiendelezi cha hiari cha kichwa cha kutofautiana, na sehemu ya data. Pakiti ya RTCP huanza na sehemu ya kudumu (sawa na sehemu ya kudumu ya pakiti za habari za RTP), ikifuatiwa na vipengele vya kimuundo ambavyo vina urefu wa kutofautiana.

Ili itifaki ya RTP iwe rahisi zaidi na inaweza kutumika kwa matumizi mbalimbali, baadhi ya vigezo vyake vinafanywa kwa makusudi bila kufafanua, lakini hutoa dhana ya wasifu. Profaili ni seti ya vigezo vya itifaki za RTP na RTCP kwa darasa maalum la programu, ambayo huamua sifa za utendaji wao. Wasifu unafafanua matumizi ya sehemu za vichwa vya pakiti za kibinafsi, aina za trafiki, nyongeza za vichwa na viendelezi vya vichwa, aina za pakiti, huduma na algoriti ili kuhakikisha usalama wa mawasiliano, vipengele vya matumizi ya itifaki ya msingi, nk. (kama mfano, kifungu cha 11 kinazingatia. ile iliyopendekezwa katika wasifu wa RFC 1890 RTP kwa ajili ya mikutano ya sauti na video yenye udhibiti mdogo). Kila programu kawaida hufanya kazi na wasifu mmoja tu, na aina ya wasifu huwekwa kwa kuchagua programu inayofaa. Hakuna dalili ya wazi ya aina ya wasifu kwa nambari ya mlango, kitambulisho cha itifaki, n.k. haijatolewa.

Kwa hivyo, vipimo kamili vya RTP kwa programu fulani lazima vijumuishe hati za ziada, zinazojumuisha maelezo ya wasifu, pamoja na maelezo ya umbizo la trafiki ambayo hufafanua jinsi aina fulani ya trafiki, kama vile sauti au video, itachakatwa katika RTP.

Vipengele vya uhamishaji wa data wa media titika wakati wa mkutano wa sauti na video vinajadiliwa katika sehemu zifuatazo.

Mkutano wa sauti wa kikundi unahitaji anwani ya kikundi cha watumiaji wengi na milango miwili. Katika kesi hii, bandari moja inahitajika kwa kubadilishana data ya sauti, na nyingine hutumiwa kwa pakiti za udhibiti wa itifaki ya RTCP. Anwani ya kikundi na maelezo ya bandari hutumwa kwa washiriki waliokusudiwa katika mkutano wa simu. Ikiwa faragha inahitajika, pakiti za maelezo na udhibiti zinaweza kusimbwa kwa njia fiche kama ilivyofafanuliwa katika Sehemu ya 7.1, ambapo ufunguo wa usimbaji fiche lazima pia uzaliwe na kusambazwa.

Kwenye Mtandao, kama ilivyo kwenye mitandao mingine ya data iliyobadilishwa kwa pakiti, pakiti wakati mwingine hupotea na kupangwa upya, na hucheleweshwa kwa viwango tofauti vya muda. Ili kukabiliana na matukio haya, kichwa cha RTP kina muhuri wa muda na nambari ya mfuatano ambayo inaruhusu wapokeaji kuweka upya muda ili, kwa mfano, sehemu za mawimbi ya sauti zichezwe kila mara na spika kila baada ya milisekunde 20. Urekebishaji huu wa muda unafanywa kando na kwa kujitegemea kwa kila chanzo cha pakiti za RTP kwenye kikundi cha habari. Nambari ya mfuatano inaweza pia kutumiwa na mpokeaji kukadiria idadi ya pakiti zilizopotea.

Kwa kuwa washiriki katika kongamano la simu wanaweza kujiunga na kuondoka kwenye mkutano wakati unaendelea, ni muhimu kujua ni nani anayeshiriki kwa sasa katika mkutano huo na jinsi washiriki wa mkutano huo wanapokea data ya sauti. Kwa madhumuni haya, kila tukio la programu ya sauti wakati wa kongamano mara kwa mara hutoa ujumbe kwenye lango dhibiti (bandari ya RTCP) kwa ajili ya maombi ya washiriki wengine wote kuhusu upokeaji wa pakiti zinazoonyesha jina la mtumiaji wake. Ujumbe wa kupokea unaonyesha jinsi spika ya sasa inavyosikika vizuri na inaweza kutumika kudhibiti visimbaji vinavyobadilika. Kando na jina la mtumiaji, maelezo mengine ya kitambulisho kwa udhibiti wa kipimo data yanaweza pia kujumuishwa. Wakati wa kuondoka kwenye mkutano, tovuti hutuma pakiti ya RTCP BYE.

Ikiwa mawimbi ya sauti na video yanatumiwa katika teleconference, hupitishwa kando. Ili kusambaza kila aina ya trafiki bila ya nyingine, vipimo vya itifaki huanzisha dhana ya kikao cha mawasiliano cha RTP (angalia orodha ya vifupisho na maneno yaliyotumiwa). Kipindi hufafanuliwa na jozi mahususi ya anwani za usafiri lengwa (anwani moja ya mtandao pamoja na jozi ya bandari za RTP na RTCP). Pakiti za kila aina ya trafiki hutumwa kwa kutumia jozi mbili tofauti za bandari za UDP na/au anwani za upeperushaji anuwai. Hakuna muunganisho wa moja kwa moja wa RTP kati ya vipindi vya sauti na video, isipokuwa tu kwamba mtumiaji anayeshiriki katika vipindi vyote viwili lazima atumie jina moja la kisheria katika pakiti za RTCP za vipindi vyote viwili ili vipindi viweze kuunganishwa.

Sio tovuti zote zinaweza kupokea data ya media titika katika umbizo sawa. Fikiria kisa ambapo washiriki kutoka eneo moja wameunganishwa kupitia kiungo cha kasi ya chini kwa wengi wa washiriki wengine wa mkutano ambao wana ufikiaji wa mtandao kwa njia pana. Badala ya kulazimisha kila mtu kutumia kipimo data cha chini na usimbaji wa sauti wa ubora wa chini, kituo cha mawasiliano cha safu ya RTP, kinachoitwa kichanganyaji, kinaweza kuwekwa katika eneo la chini la kipimo data. Kichanganyaji hiki husawazisha upya pakiti za sauti zinazoingia ili kurejesha vipindi asili vya 20-ms, huchanganya mitiririko hii ya sauti iliyoundwa upya hadi mtiririko mmoja, husimba mawimbi ya sauti kwa kipimo data finyu, na husambaza mtiririko wa pakiti kwenye kiungo cha kasi ya chini. Katika kesi hii, pakiti zinaweza kushughulikiwa kwa mpokeaji mmoja au kikundi cha wapokeaji wenye anwani tofauti. Ili kuwezesha vituo vya kupokea ili kutoa dalili sahihi ya chanzo cha ujumbe, kichwa cha RTP kinajumuisha njia ya vichanganyaji kutambua vyanzo vilivyochangia utunzi wa pakiti mchanganyiko.

Baadhi ya washiriki wa mkutano wa sauti wanaweza kuunganishwa kwa viungo vya broadband, lakini huenda wasipatikane kupitia mikutano ya kikundi ya IP multicast (IPM). Kwa mfano, zinaweza kuwa nyuma ya ngome ya safu ya programu ambayo haitaruhusu pakiti zozote za IP kupitishwa. Kwa matukio hayo, huhitaji mixers, lakini aina nyingine ya vifaa vya mawasiliano ya kiwango cha RTP, kinachoitwa watafsiri. Kati ya relay mbili, moja imewekwa nje ya ngome na inapeleka mbele pakiti zote za utangazaji anuwai zilizopokelewa kwa muunganisho salama kwa upeanaji mwingine uliowekwa nyuma ya ngome. Relay nyuma ya ngome huzisambaza tena kama pakiti za upeperushaji anuwai kwa kikundi cha watumiaji wengi kilichozuiliwa kwa mtandao wa ndani wa tovuti.

Wachanganyaji na watafsiri wanaweza kuundwa kwa madhumuni kadhaa. Mfano: Kichanganyaji cha video ambacho hukadiri picha za video za watu binafsi kwenye mitiririko huru ya video na kuzitunga katika mtiririko mmoja wa video, kuiga tukio la kikundi. Mifano ya tafsiri: kuunganisha kundi la wapangishi wa IP/UDP-pekee kwa kundi la wapangishi wa ST-II-pekee, au kupitisha pakiti za video kwa pakiti kutoka kwa vyanzo mahususi bila kusawazisha upya au kuchanganya. Maelezo ya utendakazi wa wachanganyaji na watafsiri yanajadiliwa katika sehemu ya 5.

Maeneo yote ya pakiti za RTP/RTCP hupitishwa kwenye mtandao kwa ka (octets); baiti muhimu zaidi hupitishwa kwanza. Data zote za sehemu ya kichwa hupangwa kulingana na urefu wake . Oktet zilizoteuliwa kuwa za hiari zina thamani ya sifuri.

Muda kamili (Saa ya Saa ya Kukuta) katika RTP inawakilishwa kwa kutumia umbizo la muhuri wa muda wa Itifaki ya Saa ya Mtandao (NTP), ambayo ni marejeleo ya muda katika sekunde ikilinganishwa na saa sifuri mnamo Januari 1, 1900. Umbizo kamili la muhuri wa muda wa NTP ni nambari ya uhakika ya biti 64 isiyotiwa saini iliyo na sehemu kamili katika biti 32 za kwanza na sehemu ya sehemu katika biti 32 za mwisho. Sehemu zingine zilizo na uwakilishi wa kompakt zaidi hutumia biti 32 za kati tu - biti 16 za chini za sehemu kamili na biti 16 muhimu zaidi za sehemu ndogo.

Sehemu mbili zinazofuata za makala haya (3 na 4) zinajadili fomati za pakiti na vipengele vya uendeshaji vya itifaki za RTP na RTCP, mtawalia.

Kama ilivyobainishwa hapo juu, pakiti ya RTP inajumuisha kichwa kisichobadilika, kiendelezi cha hiari cha kichwa cha kutofautiana, na sehemu ya data. Kichwa kisichobadilika cha pakiti za itifaki za RTP kina umbizo lifuatalo: .

Oktet kumi na mbili za kwanza zipo katika kila pakiti ya RTP, ilhali sehemu ya CSRC (chanzo kinachochangia) inapatikana tu inapoingizwa na kichanganyaji. Viwanja vina madhumuni yafuatayo.

Toleo (V): Biti 2. Sehemu hii inabainisha toleo la RTP. Makala haya yanashughulikia toleo la 2 la itifaki ya RTP (thamani ya 1 ilitumika katika rasimu ya kwanza ya RTP).

Ufungaji (P): 1 kidogo. Ikiwa bitana ya padding imewekwa kwa moja, basi pakiti mwishoni ina pweza moja au zaidi ya padding ambayo si sehemu ya trafiki. Oktet ya mwisho ya pedi ina kiashiria cha idadi ya pweza kama hizo ambazo zinapaswa kupuuzwa baadaye. Ufungaji unaweza kuhitajika na baadhi ya algoriti za usimbaji fiche zilizo na ukubwa wa kizuizi kisichobadilika au kubeba pakiti nyingi za RTP katika kizuizi cha data cha msingi cha itifaki.

Kiendelezi (X): biti 1. Ikiwa kiendelezi kidogo kimewekwa, basi kichwa cha kudumu kinafuatwa na ugani wa kichwa na umbizo lililofafanuliwa katika .

CSRC Counter (CC): Biti 4. Kaunta ya CSRC ina idadi ya vitambulishi vya vyanzo vya CSRC vilivyojumuishwa (angalia orodha ya vifupisho na maneno yaliyotumika) ambayo yanafuata kichwa kisichobadilika.

Alama (M): biti 1. Tafsiri ya alama imedhamiriwa na wasifu. Inakusudiwa kuruhusu matukio muhimu (kama vile mipaka ya fremu za video) kuwekewa alama katika mtiririko wa pakiti. Wasifu unaweza kutambulisha biti za alama za ziada au kubainisha kuwa hakuna biti ya alama iliyopo kwa kubadilisha idadi ya biti katika uga wa aina ya trafiki (ona).

Aina ya trafiki (PT): bits 7. Sehemu hii inabainisha umbizo la trafiki ya RTP na kubainisha jinsi programu inavyoifasiri. Wasifu unafafanua upangaji msingi tuli kati ya thamani za PT na fomati za trafiki. Misimbo ya ziada ya aina ya trafiki inaweza kubainishwa kwa nguvu kupitia njia zisizo za RTP. Mtumaji wa pakiti ya RTP hutoa thamani ya aina moja ya trafiki ya RTP wakati wowote; Sehemu hii haikusudiwa kuzidisha mitiririko ya media mahususi (tazama ).

Nambari ya mlolongo: bits 16. Nambari ya nambari ya mfuatano huongezeka kwa moja kwa kila pakiti ya taarifa ya RTP iliyotumwa na inaweza kutumiwa na mpokeaji kutambua hasara za pakiti na kurejesha mlolongo wao wa awali. Thamani ya awali ya nambari ya mlolongo huchaguliwa nasibu ili kuifanya iwe vigumu kuvunja ufunguo kulingana na thamani zinazojulikana za sehemu hii (hata kama usimbaji fiche hautumiwi na chanzo, kwani pakiti zinaweza kupita kwa mtafsiri ambaye hatumii usimbaji fiche) . Muhuri wa wakati: bits 32. Muhuri wa muda unaonyesha sehemu ya sampuli ya pweza ya kwanza katika pakiti ya taarifa ya RTP. Sehemu ya sampuli lazima ipatikane kutoka kwa kipima muda ambacho huongeza thamani zake kwa ubinafsi na mstari kwa wakati ili kutoa usawazishaji na kugundua jita (angalia sehemu ya 4.3.1). Ubora wa kipima muda lazima uwe wa kutosha kwa usahihi unaohitajika wa muda na kipimo cha kuwasili kwa pakiti (ripoti ya kipima muda kwa kila fremu ya video kwa kawaida haitoshi). Masafa ya muda hutegemea umbizo la trafiki inayotumwa na huwekwa kitakwimu katika wasifu au vipimo vya umbizo la trafiki, au inaweza kuwekwa kwa ubadilikaji kwa miundo ya trafiki iliyofafanuliwa kupitia "njia zisizo za RTP". Ikiwa pakiti za RTP zitatolewa mara kwa mara, nyakati za sampuli zilizobainishwa na kipima muda cha sampuli lazima zitumike, badala ya thamani za kipima saa cha mfumo. Kwa mfano, kwa mawimbi ya sauti ya kiwango maalum, inashauriwa kuwa kitambuzi cha muhuri wa muda kiongezwe kwa moja kwa kila kipindi cha sampuli. Ikiwa programu ya sauti kutoka kwa kifaa cha kuingiza data inasoma vizuizi vilivyo na sampuli 160, basi muhuri wa muda lazima uongezwe kwa 160 kwa kila kizuizi kama hicho, bila kujali kama kizuizi kinatumwa kwenye pakiti au kubadilishwa kama kusitisha. Thamani ya awali ya muhuri wa muda, kama thamani ya mwanzo ya nambari ya mfuatano, ni kigezo cha nasibu. Pakiti nyingi za RTP zinazofuatana zinaweza kuwa na mihuri ya muda sawa ikiwa zitatolewa kimantiki kwa wakati mmoja, kwa mfano ikiwa ni za fremu sawa ya video. Pakiti za RTP zinazofuatana zinaweza kuwa na mihuri ya muda isiyo ya mononotiki ikiwa data haitasambazwa kwa mpangilio wa sampuli, kama ilivyo kwa fremu za video za MPEG zilizoingiliana (hata hivyo, nambari za mfuatano wa pakiti bado zitakuwa monotonic wakati zinatumwa).

SSRC: Biti 32. Sehemu ya SSRC (chanzo cha ulandanishi) hutambua chanzo cha ulandanishi (angalia orodha ya vifupisho na maneno yaliyotumika). Kitambulisho hiki huchaguliwa nasibu ili kusiwe na vyanzo viwili vya ulandanishi ndani ya kipindi sawa cha RTP vilivyo na kitambulisho sawa cha SSRC. Ingawa uwezekano wa vyanzo vingi kuchagua kitambulisho sawa ni mdogo, utekelezaji wote wa RTP lazima uwe tayari kutambua na kutatua migongano kama hiyo. Sehemu ya 6 inajadili uwezekano wa migongano pamoja na mbinu ya kuyasuluhisha na kugundua misururu ya safu ya RTP kulingana na upekee wa kitambulishi cha SSRC. Chanzo kikibadilisha anwani yake ya chanzo cha usafiri, lazima pia kiteue kitambulisho kipya cha SSRC ili kuepuka kufasiriwa kama chanzo cha kurudi nyuma.

Orodha ya CSRC: vipengee 0 hadi 15, biti 32 kila moja. Orodha ya CSRC (chanzo kinachochangia) inabainisha vyanzo vilivyojumuishwa vya trafiki iliyo kwenye pakiti. Idadi ya vitambulisho imebainishwa na uga wa CC. Ikiwa kuna vyanzo zaidi ya kumi na tano vilivyojumuishwa, basi 15 tu kati yao vinaweza kutambuliwa. Vitambulisho vya CSRC huingizwa na vichanganyaji wakati wa kutumia Vitambulisho vya SSRC kwa vyanzo vilivyobadilishwa. Kwa mfano, kwa vifurushi vya sauti, Vitambulisho vya SSRC vya vyanzo vyote vilivyochanganywa wakati kifurushi kiliundwa vimeorodheshwa katika orodha ya CSRC, hivyo kutoa kielelezo sahihi cha vyanzo vya ujumbe kwa mpokeaji.

Kama ilivyoelezwa hapo juu, kulingana na itifaki ya RTP, aina tofauti za trafiki lazima zisambazwe kando, katika vipindi tofauti vya mawasiliano vya RTP. Kipindi hufafanuliwa na jozi mahususi ya anwani za usafiri lengwa (anwani moja ya mtandao pamoja na jozi ya bandari za RTP na RTCP). Kwa mfano, katika kongamano la simu linalojumuisha sauti na video zilizosimbwa kando, kila aina ya trafiki lazima itumwe katika kipindi tofauti cha RTP na anwani yake ya usafiri lengwa. Haikusudiwi kuwa sauti na video zitatumwa katika kipindi sawa cha RTP na kutengwa kulingana na aina ya trafiki au sehemu za SSRC. Kuingiliana kwa pakiti kuwa na aina tofauti za trafiki lakini kutumia SSRC sawa kunaweza kusababisha shida kadhaa:

Ikiwa moja ya aina za trafiki zitabadilika wakati wa kikao, hakutakuwa na njia za jumla za kuamua ni ipi kati ya maadili ya zamani ambayo yamebadilishwa na mpya.
SSRC inabainisha thamani moja ya muda wa muda na nafasi ya nambari ya mlolongo. Kuingilia aina nyingi za trafiki kutahitaji vipindi tofauti vya ulandanishi ikiwa viwango vya saa vya mitiririko tofauti ni tofauti, na nafasi tofauti za mfuatano wa nambari ili kuonyesha aina ya trafiki ambayo upotevu wa pakiti unahusiana.
Ujumbe wa mtumaji na mpokeaji wa RTCP (angalia Sehemu ya 4.3) huelezea thamani moja tu ya muda wa muda na nafasi ya nambari ya mlolongo kwa SSRC na haibebi sehemu ya aina ya trafiki.
Kichanganyaji cha RTP hakina uwezo wa kuchanganya mitiririko iliyoingiliana ya aina tofauti za trafiki hadi mkondo mmoja.
Sababu zifuatazo huzuia maambukizi ya aina nyingi za trafiki katika kikao kimoja cha RTP: matumizi ya njia tofauti za mtandao au ugawaji wa rasilimali za mtandao; kupokea kikundi kidogo cha data ya media titika inapohitajika, kwa mfano, sauti tu ikiwa ishara ya video inazidi kipimo data kinachopatikana; utekelezaji wa wasikilizaji ambao hutumia michakato tofauti kwa aina tofauti za trafiki, wakati utumiaji wa vipindi tofauti vya RTP huruhusu utekelezaji wa michakato moja na mingi.

Kwa kutumia SSRC tofauti kwa kila aina ya trafiki, lakini kuzisambaza katika kikao sawa cha RTP, unaweza kuepuka matatizo matatu ya kwanza, lakini huwezi kuepuka mbili za mwisho. Kwa hivyo, maelezo ya itifaki ya RTP yanahitaji kwamba kila aina ya trafiki itumie kikao chake cha RTP.

Kijajuu kilichopo cha pakiti ya maelezo ya RTP kimekamilika kwa seti ya vitendakazi vinavyohitajika kwa jumla kwa aina zote za programu zinazoweza kutumia RTP. Hata hivyo, ili kukidhi vyema madhumuni mahususi, kichwa kinaweza kurekebishwa kupitia marekebisho au nyongeza zilizobainishwa katika maelezo ya wasifu.

Sehemu ya alama na aina ya trafiki hubeba maelezo mahususi ya wasifu, lakini ziko katika kichwa kisichobadilika kwa kuwa programu nyingi zinatarajiwa kuzihitaji. Oktet iliyo na sehemu hizi inaweza kufafanuliwa upya na wasifu ili kukidhi mahitaji tofauti, kwa mfano na alama zaidi au chache. Ikiwa kuna bits za alama, zinapaswa kuwekwa kwenye bits muhimu zaidi za pweza, kwa kuwa wachunguzi wanaojitegemea wanaweza kuona uwiano kati ya mifumo ya kupoteza pakiti na biti ya alama.

Maelezo ya ziada ambayo yanahitajika kwa umbizo fulani la trafiki (kwa mfano, aina ya usimbaji video) lazima yabebwe katika sehemu ya data ya pakiti. Inaweza kuwekwa mahali maalum mwanzoni au ndani ya safu ya data.

Ikiwa darasa fulani la programu linahitaji utendakazi wa ziada ambao hautegemei umbizo la trafiki, basi wasifu ambao programu hizo hufanya kazi lazima ubainishe sehemu za ziada zisizobadilika zipatikanazo mara baada ya uga wa SSRC wa kichwa kisichobadilika kilichopo. Programu hizi zitaweza kufikia kwa haraka sehemu za ziada moja kwa moja, ilhali wachunguzi au wakataji miti wanaojitegemea wasifu bado wataweza kuchakata pakiti za RTP kwa kutafsiri okteti kumi na mbili za kwanza pekee.

Iwapo itazingatiwa kuwa utendakazi wa ziada unahitajika kwa jumla katika wasifu wote, basi toleo jipya la RTP lazima lifafanuliwe ili kufanya mabadiliko ya kudumu kwa kichwa kisichobadilika.

Kitambulisho cha Chanzo cha Usawazishaji (SSRC).

Vitambulishi Vya Chanzo Cha Kuchangia (CSRC).

Ili kuruhusu utekelezaji wa mtu binafsi kufanya majaribio ya vitendakazi vipya, visivyo na umbizo ambavyo vinahitaji maelezo ya ziada kubebwa katika kichwa cha pakiti ya data, RTP hutoa utaratibu wa upanuzi wa kichwa cha pakiti. Utaratibu huu umeundwa ili upanuzi wa kichwa uweze kupuuzwa na programu zingine za mawasiliano ambazo haziitaji.

Ikiwa biti ya X kwenye kichwa cha RTP imewekwa kuwa moja, basi kiendelezi cha kichwa cha urefu tofauti huongezwa kwenye kichwa cha RTP kisichobadilika (kufuata orodha ya CSRC, ikiwa ipo). Kumbuka kuwa kiendelezi hiki cha kichwa ni cha matumizi machache tu. Kiendelezi cha kichwa cha pakiti cha RTP kina umbizo lifuatalo:

Kiendelezi kina sehemu ya urefu wa biti 16 inayoonyesha idadi ya maneno ya biti 32 ndani yake, bila kujumuisha kichwa cha upanuzi cha oktet nne (kwa hivyo urefu unaweza kuwa sifuri). Kiendelezi kimoja pekee kinaweza kuongezwa kwenye kichwa cha pakiti cha habari cha RTP kisichobadilika. Ili kuruhusu kila moja ya utekelezaji mwingi unaoshirikiana kufanya majaribio kwa kujitegemea na viendelezi tofauti vya vichwa, au kuruhusu utekelezaji fulani kufanya majaribio ya zaidi ya aina moja ya viendelezi vya kichwa, matumizi ya biti 16 za kwanza za kiendelezi hazijabainishwa, zimehifadhiwa kwa vitambulishi vya kutofautisha au. vigezo. Umbizo la biti hizi 16 lazima libainishwe na ubainifu wa wasifu ambao programu zinafanya kazi.