Ang materyal ng artikulo ay kinuha mula sa aking .
Istruktura ng packet ng RTP
Sa huli ginagamit namin TShark nagsagawa ng pagkuha ng mga RTP packet na ipinagpapalit sa pagitan ng aming receiver at transmitter. Buweno, sa isang ito ay ipinta namin ang mga elemento ng pakete sa iba't ibang kulay at pag-uusapan ang kanilang layunin.
Tingnan natin ang parehong pakete, ngunit may mga kulay na margin at mga paliwanag na label:
Sa ibaba ng listahan, ang mga byte na bumubuo sa RTP packet ay tinted, at ito naman ay ang payload ng UDP packet (ang header nito ay binilog sa itim). Ang mga may kulay na background ay nagpapahiwatig ng mga byte ng RTP header, at ang data block na naglalaman ng payload ng RTP packet ay naka-highlight sa berde. Ang data ay ipinakita sa hexadecimal na format. Sa aming kaso, ito ay isang audio signal na naka-compress ayon sa u-law (mu-law), i.e. ang isang sample ay may sukat na 1 byte. Dahil ginamit namin ang default na sampling rate (8000 Hz), na may packet rate na 50 Hz, ang bawat RTP packet ay dapat maglaman ng 160 bytes ng payload. Makikita natin ito sa pamamagitan ng pagbibilang ng mga byte sa berdeng lugar, dapat mayroong 10 linya ng mga ito.
Ayon sa pamantayan, ang dami ng data sa payload ay dapat na isang multiple ng apat, o sa madaling salita, dapat itong maglaman ng isang integer na numero ng apat na byte na salita. Kung mangyari na hindi tumutugma ang iyong payload sa panuntunang ito, kailangan mong magdagdag ng mga zero-valued byte sa dulo ng payload at itakda ang Padding bit. Ang bit na ito ay matatagpuan sa unang byte ng RTP header at may kulay na turkesa. Tandaan na ang lahat ng payload byte ay 0xFF, na kung ano ang hitsura ng u-law silence.
Ang header ng RTP packet ay binubuo ng 12 mandatoryong byte, ngunit sa dalawang kaso maaari itong mas mahaba:
-
Kapag ang isang packet ay nagdadala ng isang audio signal na nakuha sa pamamagitan ng paghahalo ng mga signal mula sa ilang mga pinagmumulan (RTP stream), pagkatapos pagkatapos ng unang 12 bytes ng header ay mayroong isang talahanayan na may listahan ng mga source identifier na ang mga payload ay ginamit upang lumikha ng payload ng packet na ito. Sa kasong ito, sa ibabang apat na bit ng unang byte ng header (field Bilang ng nag-aambag na source identifier) ay nagpapahiwatig ng bilang ng mga mapagkukunan. Ang laki ng field ay 4 bits, kaya maaaring maglaman ang talahanayan ng hanggang 15 source identifier. Ang bawat isa ay sumasakop ng 4 na byte. Ginagamit ang talahanayang ito kapag nagse-set up ng conference call.
-
Kapag may extension ang pamagat . Sa kasong ito, ang bit ay nakatakda sa unang byte ng header X. Sa pinalawak na header, pagkatapos ng talahanayan ng mga kalahok (kung mayroon man), mayroong isang extension na header ng isang salita, na sinusundan ng mga extension na salita. Ang extension ay isang koleksyon ng mga byte na magagamit mo upang maglipat ng karagdagang data. Ang pamantayan ay hindi nagtatakda ng format ng data na ito - maaari itong maging anuman. Halimbawa, maaaring ito ay ilang karagdagang setting para sa device na tumatanggap ng mga RTP packet. Para sa ilang mga aplikasyon, gayunpaman, ang mga pinahabang pamantayan ng header ay binuo. Ginagawa ito, halimbawa, para sa mga komunikasyon sa pamantayan ED-137 (Mga Pamantayan sa Interoperability para sa mga Bahagi ng VoIP ATM).
Ngayon tingnan natin ang mga field ng header nang mas detalyado. Nasa ibaba ang isang canonical na larawan na may istraktura ng RTP header, na hindi ko rin mapigilan at pininturahan sa parehong mga kulay.
VER β numero ng bersyon ng protocol (kasalukuyang bersyon 2);
P - isang bandila na itinakda sa mga kaso kung saan ang RTP packet ay pupunan ng mga walang laman na byte sa dulo;
X - i-flag na ang header ay pinalawak;
CC β naglalaman ng bilang ng mga identifier ng CSRC na sumusunod sa pare-parehong header (pagkatapos ng mga salita 1..3), ang talahanayan ay hindi ipinapakita sa figure;
M β marker ng simula ng isang frame o ang pagkakaroon ng speech sa channel (kung ginagamit ang speech pause detector). Kung ang receiver ay walang speech pause detector, ang bit na ito ay dapat na permanenteng itakda;
PTYPE - tumutukoy sa format ng payload;
Numero ng pagkakasunud-sunod - numero ng packet, na ginagamit upang ibalik ang pagkakasunud-sunod kung saan nilalaro ang mga packet, dahil ang tunay na sitwasyon ay kapag ang mga packet ay maaaring maabot ang receiver sa maling pagkakasunud-sunod kung saan sila ipinadala. Ang paunang halaga ay dapat na random, ito ay ginagawa upang kung ang RTP stream ay naka-encrypt, ito ay mahirap i-hack ito. Gayundin, binibigyang-daan ka ng field na ito na makita ang mga napalampas na packet;
Timestamp - timestamp. Ang oras ay sinusukat sa mga sample ng signal, i.e. kung ang isang pagsabog ay naglalaman ng 160 sample, ang timestamp ng susunod na pagsabog ay magiging 160 pa. Ang paunang halaga ng timestamp ay dapat na random;
SSRC β identifier ng pinagmulan ng package, ito ay dapat na natatangi. Mas mainam na buuin ito nang random bago simulan ang stream ng RTP.
Kung bumuo ka ng sarili mong RTP transmitter o receiver, kakailanganin mong suriin ang iyong mga packet nang higit sa isang beses upang mapataas ang pagiging produktibo, inirerekomenda kong matutunan mo kung paano gumamit ng packet filtering sa TShark, pinapayagan ka nitong makuha lamang ang mga packet na interes sa iyo. Sa isang kapaligiran kung saan dose-dosenang mga RTP device ang gumagana sa network, ito ay napakahalaga. Sa TShark command line, ang mga opsyon sa pag-filter ay tinukoy gamit ang opsyong "-f". Ginamit namin ang opsyong ito kapag gusto naming kumuha ng mga packet mula sa port 8010:
-f "udp port 8010"
Ang mga parameter ng pag-filter ay mahalagang hanay ng mga pamantayan na dapat tumugma sa isang "nahuli" na packet. Maaaring suriin ng kundisyon ang address, port, halaga ng isang tiyak na byte sa packet. Ang mga kundisyon ay maaaring pagsamahin sa mga lohikal na operasyong "AT", "OR", atbp. Isang napakalakas na tool.
Kung gusto mong tingnan ang dynamics ng mga pagbabago sa field sa mga batch, kakailanganin mong i-duplicate ang output TShark sa isang file, tulad ng ipinakita sa huling artikulo, sa pamamagitan ng pagpasa ng output TShark sa pasukan tee. Susunod, buksan ang log file gamit ang mas kaunti, vim o isa pang tool na maaaring mabilis na gumana sa malalaking text file at maghanap ng mga string, maaari mong malaman ang lahat ng mga nuances ng pag-uugali ng mga packet field sa isang RTP stream.
Kung kailangan mong makinig sa signal na ipinadala ng RTP stream, pagkatapos ay kailangan mong gamitin ang bersyon TShark na may visual na interface Wireshark. Sa simpleng pagmamanipula ng mouse, maaari kang makinig at makita ang waveform ng signal. Ngunit sa isang kundisyon - kung ito ay naka-encode sa u-law o a-low na format.
Susunod gagawa kami ng duplex intercom sa iyo. Mag-stock ng isang pares ng mga headset at isang kausap.
Pinagmulan: www.habr.com