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 pskocir@iptel.org.

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 pskocir@iptel.org. 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 pskocir@iptel.org. 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 pskocir@iptel.org. 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 pskocir@iptel.org, a zatim sam u

konferenciju dodao korisnika dbrezak@iptel.org.

Slika 12 prikazuje tijek slanja SIP poruka. Prvo se šalje INVITE poruka korisniku

pskocir@iptel.org. 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

dbrezak@iptel.org 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

pskocir@iptel.org i dbrezak@iptel.org 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 pskocir@iptel.org. 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 pskocir@iptel.org i zatim prebacio taj poziv na

korisnika dbrezak@iptel.org. Slika 16 prikazuje slijed SIP poruka.

Slika 16. Slijed SIP poruka pri prijenosu poziva

Nakon što INVITE porukom pozovem korisnika pskocir@iptel.org, 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

pskocir@iptel.org 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 dbrezak@iptel.org s kojime želim uspostaviti poziv. U trenutku 20.343 je

uspostavljen poziv s njim. Ja odmah želim taj poziv preusmjeriti na korisnika

pskocir@iptel.org pa korisniku dbrezak@iptel.org o tome obavještavam s REFER

porukom. Ona služi kako bi obavijestili korisnika dbrezak@iptel.org da uspostavi

poziv s korisnikom pskocir@iptel.org, a adresa tog korisnika je zapisana u Refer-To

zaglavlju, kako prikazuje slika 17.

14

Slika 17. Refer-To parametar unutar SIP poruke

Korisnik dbrezak@iptel.org 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