SVEUČILIŠTE U ZAGREBU
FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA
LABORATORIJ TELEKOMUNIKACIJA I
INFORMATIKE 2
VIŠEMEDIJSKE KOMUNIKACIJE
Analiza prometa VoIP komunikacije
Igor Staudacher
0036434915
Zagreb, lipanj 2011.
Sadržaj
1 Sjednica između dva korisnika ....................................................... 1
1.1 Normalna A/V kvaliteta ........................................................................................................... 1
1.2 Niska A/V kvaliteta .................................................................................................................. 5
1.3 Visoka A/V kvaliteta ................................................................................................................ 7
2 Sjednica između više korisnika ....................................................... 9
3 Korisnik na čekanju ...................................................................... 11
4 Preusmjeravanje poziva ............................................................... 13
5 Dodatak – Nazivi datoteka ........................................................... 15
1
1 Sjednica između dva korisnika
U ovoj vježbi bilo je potrebno uspostaviti 3 poziva s korisnikom [email protected].
Svaki poziv je imao određeni stupanj kvalitete audia i videa. U jednom pozivu sam ja
bio pozivatelj, a u ostalima pozivan.
1.1 Normalna A/V kvaliteta
U ovom scenariju sam bio pozvan od strane korisnika [email protected]. Slika 1
prikazuje niz SIP poruka pri uspostavi, trajanju i prekidanju poziva. Moj SIP klijent
dobiva INVITE poruku i odgovara sa 180 Ringing kako bi obavijestio pozivatelja da
mora čekati na javljanje, odnosno da moj telefon zvoni. Kada prihvatim poziv, šaljem
200 OK poruku i pozivatelj mi odgovara s ACK. Sada kreće RTP promet. Nakon
nekog vremena pozivatelj prekida vezu i ja dobivam poruku BYE i odgovaram s 200
OK. S ovime je poziv završen.
Slika 1. SIP poruke u prvom scenariju
2
Jedino poruke INVITE i 200 OK imaju SDP opis sjednice u kojoj se opisuje sjednica,
mediji koji će se prenositi i koji kodeci će se koristiti. INVITE poruka predlaže
audio/video kodeke, dok se s porukom 200 OK potvrđuju formati koje pozvani
korisnik podržava.
SIP poruka sastoji se od zahtjeva/odziva, zaglavlja poruke i tijela poruke. U
zahtjevu/odzivu se definira tip SIP poruke kao što su INVITE, BYE, NOTIFY,
OPTIONS i dr. Također se označava ime SIP korisnika, njegova IP adresa i port. To
je prikazano na slici 2.
Slika 2. Zahtjev/odziv SIP poruke
U zaglavlju poruke se nalaze sljedeći podaci:
1) Niz entiteta kroz koje poruka mora proći da bi došla do odredišta (zaglavlja
Via)
2) Izvor i odredište poruke (zaglavlja From i To)
3) Jedinstveni identifikator pozivatelja/poziva (zaglavlje Call-ID)
4) Koji tipovi poruke su dozvoljeni u sjednici (zaglavlje Allows)
5) Duljina zaglavlja (zaglavlje Content-length)
6) Ostali podaci vezani uz sjednicu
Slika 3. Zaglavlje SIP poruke
3
Tijelo poruke, koje je prikazano na slici 4, sadrži SDP opis sjednice koji sadrži niz
podataka zapisanih pomoću atributa kojima je dodijeljena neka vrijednost, tj. format
SDP opisa je:
atribut = vrijednost
Svaki SDP opis sjednice mora obavezno sadržavati podatke o verziji protokola SDP,
inicijatoru, identifikatoru i imenu sjednice. Nakon toga idu ostali opcionalni podaci o
sjednici, a zatim slijedi opis medija koji se prenose sjednicom. Vrsta medija se
definira pomoću atributa m, a dodatni podaci o tom mediju pomoću atributa a. U
našem primjeru se prvo navode podaci o audiu, tj. podaci o transportnoj adresi i vrsti
mogućih kodeka. Zatim slijede detaljniji podaci o svakom kodeku, kao što su
frekvencija uzrokovanja signala i sl. Podržani audio kodeci su: G.711 PCMU, G.711
PCMA, G726-32, GSM, CN i ostali. Slično je i sa opisom video kodeka, a podržani
su: H.263, H.261 i JPEG (slanje niza JPEG slika).
Slika 4. Tijelo poruke sa SDP opisom sjednice
U ovoj sjednici bilo je ukupno 4 RTP tokova kao što pokazuje slika 5. Prema SIP
posredniku idu dvije RTP struje, jedna za audio, druga za video podatke. Isto tako
prema mom SIP klijentu dolaze podaci o audiu i videu preko dvije RTP struje. Za
slanje audia se koristi G.711 PCMU s Comfort Noise opcijom koja se koristi kada
4
korisnik trenutno ništa ne govori pa se generira bijeli šum kako drugi korisnik ne bi
dobio dojam da se veza prekinula. Za prijenos videa se koristi kodek H.263.
Slika 5. RTP tokovi
Na slici 6 prikazan je jedan RTP paket. Svi RTP paketi se prenose pomoću
transportnog protokola UDP. Sastoji se od sljedećih zaglavlja:
1) Version – verzija protokola RTP koji se koristi u sesiji
2) Padding – označava postoje li dodatni bitovi na kraju RTP paketa
3) Extension – označava postoji li dodatno Extension zaglavlje unutar RTP
paketa
4) Contributing Source Identifiers Count – označava broj CSRC identifikatora
5) Marker – označava da su trenutni podaci važni za aplikaciju
6) Payload Type – označava tip kodeka
7) Sequence Number – trenutni broj RTP paketa, može se koristiti za
dekodiranje audia
8) Timestamp – vremenska oznaka za trenutne audio/video podatke unutar RTP
paketa
9) Synchronization Source Identifier – identifikator izvora podataka
10) Payload – podaci
5
Slika 6. RTP paket
Slika 7 prikazuje dolazni i odlazni audio i video promet. Može se primijetiti da video
zauzima veći dio prometa.
Slika 7. A/V promet u 1. scenariju
1.2 Niska A/V kvaliteta
U ovom scenariju sam ja bio pozivatelj i zvao sam korisnika [email protected]. U
INVITE poruci su drugačije postavljeni audio kodeci tako da se sugerira drugom
korisniku da koristi kodeke koji daju nižu kvalitetu audia i videa, a na prvom mjestu za
audio se nalazi kodek GSM 06.10, a za video H.263.
6
Pri razgovoru se koristi kodek GSM 06.10 za audio, a H.263 za video. Iako se koristi
isti kodek za video kao u prošlom scenariju, nije ista rezolucija videa. Prošli scenarij
je imao rezoluciju 176x144 (QCIF), a ovaj 128x96 (sub-QCIF), kao što prikazuje slika
8.
Slika 8. Predložena rezolucija slike za nižu kvalitetu
Kao i u prošlom scenariju, postoji 4 RTP toka. Slika 9 prikazuje dio A/V prometa i
može se zaključiti da je udio audio, a pogotovo video prometa nešto niži nego u
prošlom scenariju.
Slika 9. A/V promet u 2. scenariju
7
1.3 Visoka A/V kvaliteta
Ja sam bio pozvan od strane korisnika [email protected]. U njegovoj INVITE poruci
bio je isti raspored kodeka kao i u prvom scenariju. Također postoje 4 RTP toka, a
korišteni kodeci su G.711 PCMU za audio i H.263 sa rezolucijom 352x288 (CIF) za
video, kao što prikazuje slika 10.
Slika 10. Predložena rezolucija slike za visoku kvalitetu
Slika 9 prikazuje promet u ovom scenariju i vidi se da se šalje više podataka o audio
i videu nego u prošlim scenarijima.
Slika 11. A/V prometu 3. scenariju
8
Tablica 1 prikazuje korištene kodeke u svim scenarijima i tri slike kako bi se prikazala
očita razlika u kvaliteti videa.
Tablica 1. Razlika u kvaliteti u trima scenarijima
Normalna kvaliteta Niža kvaliteta Visoka kvaliteta
G.711 PCMU
H.263 (QCIF)
GSM 06.10
H.263 (sub-QCIF)
G.711 PCMU
H.263 (CIF)
9
2 Sjednica između više korisnika
U ovoj sjednici sam ja prvo pozvao korisnika [email protected], a zatim sam u
konferenciju dodao korisnika [email protected].
Slika 12 prikazuje tijek slanja SIP poruka. Prvo se šalje INVITE poruka korisniku
[email protected]. On prihvaća poziv sa 200 OK i ja mu odgovaram sa ACK, te
započinje slanje audia i videa. Nakon 6.5 sekundi šaljem INVITE poruku korisniku
[email protected] koji također prihvaća moj poziv. Konferencija je uspostavljenja.
Nakon nekog vremena prekidam konferenciju slanjem BYE poruka.
Slika 12. Slijed SIP poruka u konferencijskom pozivu
10
U konferenciji postoji 8 RTP toka kao što prikazuje slika 13. Prema svakom korisniku
su otvorena 4 RTP toka za izmjenu audio/video podataka. Međutim, korisnici
[email protected] i [email protected] imaju otvorena samo 4 RTP, tj. šalju
audio/video podatke samo prema meni. Ja, tj. moj SIP telefon, služi kao poveznica
između njih dvoje. Kad primim podatke od jednog korisnika, ukomponiram ih sa
svojim audio/video podacima i šaljem drugom korisniku. Ne postoji direktna RTP
veza između njih dvoje. Na slici se također može vidjeti da se podaci šalju na dva
različita porta, svaki je otvoren za jednog korisnika.
Slika 13. RTP tokovi u konferencijskom pozivu
Slično kao i kod poziva između dva korisnika, mijenjanjem postavki o kvaliteti audia ili
videa, predlažu se drugačiji kodeci koji imaju manju kvalitetu i za koje je potreban
manji broj bitova po sekundi za prijenos podataka. Takvi kodeci su GSM 06.10 i
H.263 (sub-QCIF) za nižu kvalitetu i G.711 PCMU i H.263 (CIF) za višu kvalitetu.
11
3 Korisnik na čekanju
U ovom scenariju sam ja zvao korisnika [email protected]. Slika 14 prikazuje tijek
slanja i primanja SIP poruka. S INVITE porukom pozivam korisnika i poziv je
uspostavljen nakon poruka 200 OK i ACK. U trenutku 8.271 stavljam korisnika na
čekanje pomoću INVITE poruke koja ima promijenjeni SDP opis sjednice. Naime,
atribut Media attribute (a) je postavljen na sendonly čime obavještavam drugog
korisnika da u promijenjenoj sjednici neće primati A/V podatke, ali ih može slati.
Nakon 5 sekundi opet želim promijeniti parametre sjednice, tj. ne želim da moj
sugovornik više bude na čekanju. Ponovno se šalje INVITE poruka, ali ovaj put je
atribut Media attribute (a) postavljen na sendrcv pa će sugovornikom SIP telefon
znati da od sada može slati, ali i primati A/V podatke. Promjene tih atributa su vidljive
na slici 15.
Slika 14. Slijed SIP poruka pri stavljanju poziva na čekanje
12
Slika 15. Parametar s kojim se stavlja poziv na čekanje
13
4 Preusmjeravanje poziva
Ja sam prvo pozvao korisnika [email protected] i zatim prebacio taj poziv na
korisnika [email protected]. Slika 16 prikazuje slijed SIP poruka.
Slika 16. Slijed SIP poruka pri prijenosu poziva
Nakon što INVITE porukom pozovem korisnika [email protected], on mi odgovara s
porukom 200 OK. Nakon što mu pošaljem ACK poruku, poziv je uspostavljen. U
trenutku 12.975 želim promijeniti parametre sjednice i staviti korisnika
[email protected] na čekanje jer želim pozvati drugog korisnika. U INVITE poruci je,
unutar SDP opisa sjednice, zaglavlje Media attribute postavljeno na sendonly. Nakon
200 OK i ACK poruka je korisnik stavljen na čekanje i odmah se šalje INVITE poruka
korisniku [email protected] s kojime želim uspostaviti poziv. U trenutku 20.343 je
uspostavljen poziv s njim. Ja odmah želim taj poziv preusmjeriti na korisnika
[email protected] pa korisniku [email protected] o tome obavještavam s REFER
porukom. Ona služi kako bi obavijestili korisnika [email protected] da uspostavi
poziv s korisnikom [email protected], a adresa tog korisnika je zapisana u Refer-To
zaglavlju, kako prikazuje slika 17.
14
Slika 17. Refer-To parametar unutar SIP poruke
Korisnik [email protected] prihvaća transfer s 202 Accepted porukom, a zatim s
NOTIFY porukom, koja je prikazana na slici 18, me obavještava da nema problema
pri preusmjeravanju poziva i da je poziv između njih uspostavljen. Međusobnim
slanjem BYE poruka se prekidaju pozivi između mene i ostalih korisnika, a oni
nastavljaju razgovarati.
Slika 18. NOTIFY poruka
15
5 Dodatak – Nazivi datoteka
Unutar datoteke Staudacher_Igor.rar se nalaze Wireshark datoteke sa SIP
prometom. Format naziva je sljedeći:
[Ime scenarija] – [Uloga u scenariju] – [A/V kvaliteta] –SIP.pcap
Slijedi popis datoteka po scenarijima:
1. a) Normalna kvaliteta - 2korisnika-B-default-SIP.pcap
b) Niska kvaliteta - 2korisnika-A-lower-SIP.pcap
c) Visoka kvaliteta – 2korisnika-B-higher-SIP.pcap
2. Konferencijski poziv – Conference-A-default-SIP.pcap
3. Poziv na čekanju – Hold-A-default-SIP.pcap
4. Prijenos poziva – Transfer-A-default-SIP.pcap