9.

1 Aplikasi Jaringan Multimedia

Aplikasi jaringan multimedia adalah aplikasi jaringan yang menggunakan audio atau video. Setiap aplikasi jaringan
multimedia memiliki serangkaian persyaratan layanan dan masalah desain yang unik.
9.1.1 Properti Video
Karakteristik yang paling menonjol dari video adalah bit rate yang tinggi. Video yang didistribusikan melalui
Internet biasanya berkisar dari 100 kbps untuk konferensi video berkualitas rendah hingga lebih dari 3 Mbps untuk
streaming film definisi tinggi. Streaming video mengkonsumsi bandwidth dan bit rate paling banyak. Oleh karena itu,
ketika merancang karakteristik penting lainnya dari video adalah dapat dikompresi, sehingga menukar kualitas video
dengan bit rate. Video adalah urutan gambar, biasanya ditampilkan dengan kecepatan konstan, misalnya, pada 24 atau
30 gambar per detik. Ada dua jenis redundansi dalam video, yang keduanya dapat dimanfaatkan kompresi untuk video,
yaitu:
1. Redundansi spasial adalah redundansi dalam gambar yang diberikan. Secara intuitif, gambar yang sebagian besar
terdiri dari ruang putih memiliki tingkat redundansi yang tinggi dan dapat dikompresi secara efisien tanpa
mengorbankan kualitas gambar.
2. Redundansi temporal mencerminkan pengulangan dari gambar ke gambar berikutnya.
9.1.2 Properti Audio
Audio digital (termasuk pidato dan musik digital) memiliki kebutuhan bandwidth yang jauh lebih rendah
daripada video. Audio digital memiliki sifat uniknya sendiri yang harus dipertimbangkan ketika merancang aplikasi
jaringan multimedia. Untuk memahami sifat-sifat ini, pertama-tama mari kita pertimbangkan bagaimana audio analog
(yang dihasilkan oleh manusia dan alat musik) diubah menjadi sinyal digital:
 Sinyal audio analog diambil sampelnya pada tingkat tertentu, misalnya, pada 8.000 sampel per detik. Nilai
setiap sampel akan menjadi beberapa bilangan real.
 Masing-masing sampel kemudian dibulatkan ke salah satu dari sejumlah nilai yang terbatas. Operasi ini disebut
sebagai kuantisasi. Jumlah nilai hingga tersebut (disebut nilai kuantisasi) biasanya merupakan pangkat dua,
misalnya 256 nilai kuantisasi.
 Setiap nilai kuantisasi diwakili oleh sejumlah bit yang tetap. Misalnya, jika ada 256 nilai kuantisasi, maka setiap
nilai—dan karenanya setiap sampel audio—diwakili oleh satu byte. Representasi bit dari semua sampel
kemudian digabungkan bersama untuk membentukdigital representasidari sinyal. Sebagai contoh, jika sinyal
audio analog diambil sampelnya pada 8.000 sampel per detik dan setiap sampel dikuantisasi dan diwakili oleh 8
bit, maka sinyal digital yang dihasilkan akan memiliki kecepatan 64.000 bit per detik. Untuk pemutaran melalui
speaker audio, sinyal digital kemudian dapat dikonversi kembali—yaitu, didekodekan—menjadi sinyal analog.
Namun, sinyal analog yang didekodekan hanya merupakan perkiraan dari sinyal asli, dan kualitas suara
mungkin menurun secara nyata (misalnya, suara frekuensi tinggi mungkin hilang dalam sinyal yang
didekodekan). Dengan meningkatkan laju sampling dan jumlah nilai kuantisasi, sinyal yang didekodekan dapat
lebih mendekati sinyal analog asli. Jadi (seperti halnya video), ada pertukaran antara kualitas sinyal yang
didekodekan dan laju bit dan persyaratan penyimpanan sinyal digital.
Teknik pengkodean dasar yang baru saja dijelaskan disebut Pulse Code Modulation (PCM). PCM dengan laju
pengambilan sampel 8.000 sampel per detik dan 8 bit per sampel, menghasilkan laju 64 kbps. Audio compact disk (CD)
juga menggunakan PCM, dengan sampling rate 44.100 sampel per detik dengan 16 bit per sampel; ini memberikan
kecepatan 705,6 kbps untuk mono dan 1,411 Mbps untuk stereo.

1
9.1.3 Jenis Aplikasi Jaringan Multimedia
Jenis Aplikasi Jaringan Multimedia diklasifikasikan dalam tiga kategori:
(i) Streaming Stored Audio dan Video
Streaming video yang disimpan biasanya menggabungkan komponen video dan audio. Streaming audio yang
disimpan (seperti layanan musik streaming Spotify) sangat mirip dengan streaming video yang disimpan, meskipun bit
rate biasanya jauh lebih rendah. Dalam aplikasi ini, media yang mendasarinya adalah video yang direkam sebelumnya,
seperti film, acara televisi, acara olahraga yang direkam sebelumnya, atau video buatan pengguna yang direkam
sebelumnya (seperti yang biasa terlihat di YouTube). Video yang direkam sebelumnya ini ditempatkan di server, dan
pengguna mengirim permintaan ke server untuk melihat video sesuai permintaan. Streaming video yang disimpan
memiliki tiga fitur pembeda utama.
 Streaming. Dalam aplikasi video streaming yang disimpan, klien biasanya memulai pemutaran video dalam
beberapa detik setelah mulai menerima video dari server. Ini berarti bahwa klien akan memutar dari satu lokasi
dalam video sementara pada saat yang sama menerima bagian video selanjutnya dari server.
 Interaktivitas. Karena media telah direkam sebelumnya, pengguna dapat menjeda, memposisikan ulang ke
depan, memposisikan ulang mundur, maju cepat, dan seterusnya melalui konten video
 Pemutaran terus menerus. Setelah pemutaran video dimulai, itu harus dilanjutkan sesuai dengan waktu asli
perekaman. Oleh karena itu, data harus diterima dari server tepat waktu untuk dimainkan di klien; jika tidak,
pengguna mengalami pembekuan bingkai video (ketika klien menunggu bingkai yang tertunda) atau
melewatkan bingkai (ketika klien melompati bingkai yang tertunda).
9.2 Streaming Video Tersimpan
Streaming video tersimpan adalah video yang direkam sebelumnya ditempatkan di server, dan pengguna mengirim
permintaan ke server ini untuk melihat video sesuai permintaan. Pengguna dapat menonton video dari awal hingga akhir
tanpa gangguan, dapat berhenti menonton video sebelum berakhir, atau berinteraksi dengan video dengan menjeda atau
memposisikan ulang ke adegan masa depan atau masa lalu. Sistem video streaming dapat diklasifikasikan ke dalam tiga
kategori yaitu: Streaming UDP, streaming HTTP, dan streaming HTTP adaptif. Sebagian besar sistem saat ini
menggunakan streaming HTTP dan streaming HTTP adaptif.
9.2.1 Streaming UDP
Dengan streaming UDP, server mentransmisikan video dengan kecepatan yang sesuai dengan tingkat konsumsi
video klien dengan mencatat potongan video melalui UDP dengan kecepatan tetap.
Sebelum meneruskan potongan video ke UDP, server akan merangkum potongan video dalam paket transport
yang dirancang khusus untuk mengangkut audio dan video, menggunakan Real-Time Transport Protocol (RTP).
Properti lain yang membedakan streaming UDP adalah bahwa selain streaming video server-ke-klien, klien dan server
juga memelihara, secara paralel, koneksi kontrol terpisah di mana klien mengirim perintah mengenai perubahan status
sesi (seperti jeda, lanjutkan , reposisi, dan sebagainya).
Streaming UDP memiliki tiga kelemahan. Pertama, karena jumlah bandwidth yang tersedia tidak dapat diprediksi
dan bervariasi antara server dan klien, streaming UDP dengan kecepatan konstan dapat gagal menyediakan pemutaran
berkelanjutan. Kedua, streaming UDP memerlukan server kontrol media, seperti server RTSP, untuk memproses
permintaan interaktivitas klien-ke-server dan untuk melacak status klien untuk setiap sesi klien yang sedang
berlangsung. Hal ini meningkatkan keseluruhan biaya dan kerumitan penerapan sistem video-on-demand skala besar.

2
Ketiga, banyak firewall dikonfigurasi untuk memblokir lalu lintas UDP, mencegah pengguna di belakang firewall ini
untuk menerima video UDP.
9.2.2 Streaming HTTP
Dalam streaming HTTP, video hanya disimpan di server HTTP sebagai file biasa dengan URL tertentu. Ketika
pengguna ingin melihat video, klien membuat koneksi TCP dengan server dan mengeluarkan permintaan HTTP GET
untuk URL tersebut. Server kemudian mengirimkan file video, dalam pesan respons HTTP, secepat mungkin, yaitu
secepat yang dimungkinkan oleh kontrol kongesti TCP dan kontrol aliran. Di sisi klien, byte dikumpulkan dalam buffer
aplikasi klien. Setelah jumlah byte dalam buffer ini melebihi ambang batas yang telah ditentukan, aplikasi klien
memulai pemutaran khususnya, secara berkala mengambil frame video dari buffer aplikasi klien, mendekompresi frame,
dan menampilkannya di layar pengguna.
Penggunaan HTTP melalui TCP juga memungkinkan video untuk melintasi firewall dan NAT dengan lebih mudah
(yang sering dikonfigurasi untuk memblokir sebagian besar lalu lintas UDP tetapi untuk mengizinkan sebagian besar
lalu lintas HTTP). Streaming melalui HTTP juga meniadakan kebutuhan akan server kontrol media, seperti server
RTSP, sehingga mengurangi biaya penyebaran skala besar melalui Internet. Karena semua keunggulan ini, sebagian
besar aplikasi streaming video saat inimenggunakan streaming HTTP (melalui TCP) sebagai protokol streaming yang
mendasarinya.
 Prefetching Video
Buffering sisi klien dapat digunakan untuk mengurangi efek dari berbagai penundaan ujung ke ujung dan berbagai
bandwidth yang tersedia. Untuk streaming video yang disimpan, klien dapat mencoba mengunduh video dengan
kecepatan yang prefetching lebih tinggi daripada tingkat konsumsi, sehingga melakukan frame video yang akan
dikonsumsi di masa depan. Video yang diambil sebelumnya ini secara alami disimpan dalam buffer aplikasi klien.
Misalkan tingkat konsumsi video adalah 1 Mbps tetapi jaringan mampu mengirimkan video dari server ke klien
dengan kecepatan konstan 1,5 Mbps. Kemudian klien tidak hanya dapat memutar video dengan penundaan pemutaran
yang sangat kecil, tetapi juga dapat meningkatkan jumlah data video yang di-buffer sebesar 500 Kbits setiap detik.
Dengan cara ini, jika di masa mendatang klien menerima data dengan kecepatan kurang dari 1 Mbps untuk periode
waktu yang singkat, klien akan dapat terus menyediakan pemutaran berkelanjutan karena cadangan dalam buffernya.
[Wang 2008] menunjukkan bahwa ketika rata-rata throughput TCP kira-kira dua kali kecepatan bit media, streaming
melalui TCP menghasilkan kelaparan minimal dan penundaan buffering yang rendah.
 Client Application Buffer dan TCP Buffer
Pada Gambar 9.2 mengilustrasikan interaksi antara client dan server untuk HTTP streaming. Di sisi server, bagian
dari file video berwarna putih telah dikirim ke soket server, sedangkan bagian yang digelapkan adalah yang tersisa
untuk dikirim. Setelah "melewati pintu soket," byte ditempatkan di buffer pengiriman TCP sebelum dikirim ke Internet.
karena buffer pengiriman TCP di sisi server terlihat penuh, server untuk sementara dicegah mengirim lebih banyak byte
dari file video ke soket. Di sisi klien, aplikasi klien (pemutar media) membaca byte dari buffer penerima TCP (melalui
soket kliennya) dan menempatkan byte ke buffer aplikasi klien. Pada saat yang sama, aplikasi klien secara berkala
mengambil bingkai video dari buffer aplikasi klien, mendekompresi bingkai, dan menampilkannya di layar pengguna.
Perhatikan bahwa jika buffer aplikasi klien lebih besar dari file video, maka seluruh proses pemindahan byte dari
penyimpanan server ke buffer aplikasi klien setara dengan pengunduhan file biasa melalui HTTP.

3
 Gambar 9.2 Streaming video yang disimpan melalui HTTP/TCP
 Analisis Video Streaming 

Gambar 9.3 Analisis buffer sisi klien untuk streaming video

Beberapa pemodelan sederhana akan memberikan lebih banyak wawasan tentang penundaan pemutaran awal
danpembekuan karena penipisan buffer aplikasi. Seperti ditunjukkan pada Gambar 9.3, biarkan B menunjukkan ukuran
(dalam bit) buffer aplikasi klien, dan biarkan Q menunjukkan jumlah bit yang harus buffer Q<B. sebelum aplikasi klien
mulai bermain. (Tentu saja, ) Biarkan r menunjukkan tingkat konsumsi video —tingkat di mana klien menarik bit dari
buffer aplikasi klien selama pemutaran. Jadi, misalnya, jika kecepatan bingkai video adalah 30 bingkai/detik, dan setiap
bingkai (terkompresi) adalah 100.000 bit, maka  r=3 Mbps Untuk melihat hutan melalui pepohonan, kita akan
mengabaikan buffer kirim dan terima TCP. 
Mari kita asumsikan bahwa server mengirimkan bit dengan kecepatan konstan x setiap kali buffer klien tidak penuh.
(Ini adalah penyederhanaan kasar, karena tingkat pengiriman TCP bervariasi karena kontrol kemacetan; kami akan
memeriksa lebih lanjut tingkat ketergantungan waktu yang realistis x(t) dalam masalah di akhir bab ini.) Misalkan pada
waktu t=0 buffer aplikasi kosong dan video mulai masuk ke buffer aplikasi klien. Kami sekarang bertanya apa? waktu
t=tp playout dimulai? Dan sementara kita melakukannya, pada jam berapa t=tf melakukan buffer aplikasi klien menjadi
penuh?
Pertama, mari kita tentukan t , waktu ketika Q bit telah memasuki buffer aplikasi dan playout dimulai. Ingat bahwa bit
tiba ke buffer aplikasi klien dengan kecepatan x dan tidak ada bit yang dihapus dari buffer ini sebelum permainan
dimulai. Jadi, jumlah waktu yang dibutuhkan untuk membangun Q bit (penundaan buffering awal) adalah tp=Q/x.
Sekarang mari kita tentukan tf , titik waktu buffer aplikasi klien menjadi penuh. Kita amati dulu bahwa jika x<r
(yaitu, jika laju pengiriman server kurang dari laju konsumsi video), maka buffer klien tidak akan pernah penuh!
Memang, mulai waktu tp , buffer akan habis pada tingkat r dan hanya akan diisi dengan laju x<r. Akhirnya buffer klien
akan kosong seluruhnya, pada saat video akan dibekukan layar sementara buffer klien menunggu t detik lagi untuk
4
membangun Q bit video. Dengan demikian, ketika tingkat yang tersedia di jaringan kurang dari tingkat video, pemutaran
akan bergantian antara periode playout terus menerus dan periode pembekuan. Dalam masalah pekerjaan rumah, Anda
akan diminta untuk menentukan panjang setiap playout dan periode pembekuan kontinu sebagai fungsi dari Q, r, dan x.
Sekarang mari kita tentukan tr ketika x>r Dalam hal ini, mulai dari waktu tp, buffer meningkat dari Q ke B pada laju x-r
karena bit
terkuras pada laju r tetapi tiba pada laju x, seperti yang ditunjukkan pada Gambar 9.3. Dengan petunjuk ini, Anda akan
menjadi ditanya dalam masalah pekerjaan rumah untuk menentukan tr , waktu buffer klien menjadi penuh. Perhatikan
bahwa ketika tingkat yang tersedia di jaringan lebih dari kecepatan video, setelah penundaan buffering awal, pengguna
akan
nikmati pemutaran terus menerus sampai video berakhir.
 Pemutusan Awal dan Pemosisian Ulang Video
Sistem streaming HTTP sering menggunakan header rentang byte HTTP dalam pesan permintaan HTTP GET,
yang menentukan rentang byte spesifik yang saat ini ingin diambil klien dari video yang diinginkan. Ini sangat
berguna ketika pengguna ingin memposisikan ulangke titik waktu mendatang dalam video. Ketika pengguna
memposisikan ulang ke posisi baru, klien mengirimkan permintaan HTTP baru, yang menunjukkan dengan header
rentang byte dari byte mana dalam file yang harus dikirim oleh server. Ketika server menerima permintaan HTTP
baru, server dapat melupakan permintaan sebelumnya dan mengirim byte yang dimulai dengan byte yang
ditunjukkan dalam permintaan rentang byte.
Sementara kami membahas tentang pemosisian ulang, kami secara singkat menyebutkan bahwa ketika
pengguna memposisikan ulang ke titik masa depan dalam video atau menghentikan video lebih awal, beberapa data
yang telah diambil tetapi belum dilihat yang dikirimkan oleh server akan tidak ditonton
9.3 Voice-over-IP 
Suara percakapan real-time melalui internet sering disebut sebagai telepon Internet, hal ini juga biasa disebut Voice-
over-IP (VoIP). Pada bagian ini akan dijelaskan prinsip dan protokol yang mendasari VoIP.
9.3.1 Batasan Layanan IP Upaya Terbaik 
Protokol lapisan jaringan Internet, IP, menyediakan layanan upaya terbaik. Artinya, layanan melakukan upaya
terbaiknya untuk memindahkan setiap datagram dari sumber ke tujuan secepat mungkin, tetapi tidak menjanjikan apa pun
tentang pengiriman paket ke tujuan dalam batas penundaan tertentu atau tentang batas persentase paket yang hilang.
Kurangnya jaminan tersebut menimbulkan tantangan yang signifikan untuk desain aplikasi percakapan real-time, yang
sangat sensitif terhadap keterlambatan paket, jitter, dan kehilangan paket.
 Packet Loss 
Pertimbangkan salah satu segmen UDP yang dihasilkan oleh aplikasi VoIP kami. Segmen UDP dienkapsulasi
dalam datagram IP. Saat datagram mengembara melalui jaringan, ia melewati buffer router (yaitu antrian) sambil
menunggu transmisi pada tautan keluar. Ada kemungkinan bahwa satu atau lebih buffer di jalur dari pengirim ke
penerima penuh, dalam hal ini datagram IP yang datang dapat dibuang, tidak pernah sampai ke aplikasi penerima. 
Kerugian dapat dihilangkan dengan mengirimkan paket melalui TCP (yang menyediakan transfer data yang
andal) daripada melalui UDP. Namun, mekanisme transmisi ulang sering dianggap tidak dapat diterima untuk
aplikasi audio percakapan real-time seperti VoIP, karena meningkatkan penundaan end-to-end [Bolot 1996]. Selain
itu, karena kontrol kongesti TCP, kehilangan paket dapat mengakibatkan pengurangan laju transmisi pengirim TCP

5
 ke laju yang lebih rendah dari laju pengurasan penerima, yang mungkin menyebabkan kelaparan buffer. Ini dapat
berdampak parah pada kejelasan suara di penerima. Untuk alasan ini, 
Tapi kehilangan paket tidak selalu membawa malapetaka seperti yang dibayangkan. Memang, tingkat kehilangan
paket antara 1 dan 20 persen dapat ditoleransi, tergantung pada bagaimana suara dikodekan dan ditransmisikan, dan
bagaimana kehilangan itu disembunyikan di penerima. Misalnya, koreksi kesalahan maju (FEC) dapat membantu
menyembunyikan kehilangan paket. Kita akan melihat di bawah bahwa dengan FEC, informasi yang berlebihan
ditransmisikan bersama dengan informasi asli sehingga beberapa data asli yang hilang dapat dipulihkan dari
informasi yang berlebihan. Namun demikian, jika satu atau lebih tautan antara pengirim dan penerima sangat padat,
dan kehilangan paket melebihi 10 hingga 20 persen (misalnya, pada tautan nirkabel), maka sebenarnya tidak ada
yang dapat dilakukan untuk mencapai kualitas audio yang dapat diterima. Jelas, layanan upaya terbaik memiliki
keterbatasan. 
 End-to-End Delay 
End-to-end delay penundaan adalah akumulasi transmisi, pemrosesan, dan antrian di router; penundaan propagasi
dalam tautan; dan penundaan pemrosesan sistem akhir. Untuk aplikasi percakapan waktu nyata, seperti VoIP,
penundaan ujung ke ujung yang lebih kecil dari 150 mdtk tidak dirasakan oleh pendengar manusia; penundaan antara
150 dan 400 msecs dapat diterima tetapi tidak ideal; dan penundaan yang melebihi 400 mdtk dapat sangat
menghambat interaktivitas dalam percakapan suara. Sisi penerima aplikasi VoIP biasanya akan mengabaikan paket
apa pun yang tertunda lebih dari ambang batas tertentu, misalnya, lebih dari 400 msec. Dengan demikian, paket yang
tertunda lebih dari ambang batas secara efektif hilang. 
 Packet Jitter 
Sebuah komponen penting dari end-to-end delay adalah delay antrian yang bervariasi yang dialami sebuah paket
di router jaringan. Karena penundaan yang bervariasi ini, waktu dari saat sebuah paket dibangkitkan di sumber
sampai diterima di penerima dapat berfluktuasi dari paket ke paket. Fenomena ini disebut jitter. Sebagai contoh,
pertimbangkan dua paket berurutan dalam aplikasi VoIP kami. Pengirim mengirimkan paket kedua 20 msecs setelah
mengirim paket pertama. Tapi di penerima, jarak antar paket ini bisa menjadi lebih besar dari 20 msecs. Untuk
melihat ini, misalkan paket pertama tiba di antrian yang hampir kosong di router, tetapi tepat sebelum paket kedua
tiba di antrian, sejumlah besar paket dari sumber lain tiba di antrian yang sama. Karena paket pertama mengalami
penundaan antrian yang kecil dan paket kedua mengalami penundaan antrian yang besar pada router ini, paket
pertama dan kedua menjadi berjarak lebih dari 20 msec. Jarak antar paket berurutan juga bisa menjadi kurang dari 20
msec.

9.3.2 Menghapus Jitter di Receiver untuk Audio 

Untuk aplikasi VoIP kami, di mana paket-paket dihasilkan secara berkala, receiver harus berusaha untuk
menyediakan pemutaran potongan suara secara berkala dengan adanya jitter jaringan acak. Ini biasanya dilakukan
dengan menggabungkan dua mekanisme berikut: 
1. Mengawali setiap potongan dengan stempel waktu. Pengirim mencap setiap potongan dengan waktu saat
potongan itu dibuat. 
2. Menunda pemutaran potongan di penerima. Seperti yang kita lihat dalam diskusi sebelumnya tentang
Gambar 9.1, penundaan pemutaran dari potongan audio yang diterima harus cukup lama sehingga sebagian

6
 besar paket diterima sebelum waktu pemutaran yang dijadwalkan. Penundaan pemutaran ini dapat
diperbaiki sepanjang durasi sesi audio atau bervariasi secara adaptif selama masa pakai sesi audio. 
Kami sekarang membahas bagaimana ketiga mekanisme ini, bila digabungkan, dapat mengurangi atau bahkan
menghilangkan efek jitter. Kami memeriksa dua strategi pemutaran: penundaan pemutaran tetap dan penundaan
pemutaran adaptif.
 Fixed Playout Delay 
Dengan strategi fixed-delay, receiver mencoba memainkan setiap chunk tepat q mdtk setelah chunk dihasilkan.
Jadi, jika suatu potongan diberi stempel waktu pada pengirim pada waktu t, penerima memainkan t+q, potongan
pada waktu dengan asumsi potongan telah tiba pada saat itu. Paket yang tiba setelah waktu pemutaran yang
dijadwalkan akan dibuang dan dianggap hilang. 
Apa pilihan yang baik untuk q? VoIP dapat mendukung penundaan hingga sekitar 400 mdtk, meskipun
pengalaman percakapan yang lebih memuaskan dicapai dengan nilailebih kecil q yang. Di sisi lain, jika q dibuat jauh
lebih kecil dari 400 msec, maka banyak paket mungkin melewatkan waktu pemutaran yang dijadwalkan karena jitter
paket yang diinduksi jaringan. Secara kasar, jika variasi besar dalam penundaan ujung-ke-ujung adalah tipikal, lebih
baik menggunakanbesar q; di sisi lain, jika penundaan kecil dan variasi penundaan juga kecil, lebih baik
menggunakankecil q, mungkin kurang dari 150 msecs. 

Gambar 9.4 Paket hilang untuk penundaan pemutaran tetap yang berbeda
Gambar 9.4 menunjukkan waktu di mana paket dibangkitkan dan diputar untuk satu semburan bicara. Dua
penundaan pemutaran awal yang berbeda dipertimbangkan. Seperti yang ditunjukkan oleh tangga paling kiri, pengirim
menghasilkan paket secara berkala—katakanlah, setiap 20 mdtk. Paket pertama dalam semburan bicara ini diterima pada
waktu r. Seperti yang ditunjukkan pada gambar, kedatangan paket berikutnya tidak merata karena jitter jaringan p−r.
Untuk jadwal pemutaran pertama, penundaan pemutaran awal tetap diatur ke Dengan jadwal ini,keempat   paket
tidak tiba pada waktu pemutaran yang dijadwalkan, dan penerima menganggapnya hilang. Untuk jadwal pemutaran
kedua, penundaan pemutaran awal tetap diatur ke Untuk jadwal ini, semua paket tiba sebelum p′−r. 
 Penundaan Playout Adaptif
Contoh sebelumnya menunjukkan trade-off penundaan-kerugian penting yang muncul saat merancang strategi
playout dengan penundaan playout tetap. Dengan membuat penundaan pemutaran awal menjadi besar, sebagian besar
paket akan mencapai tenggat waktu mereka dan oleh karena itu akan ada kerugian yang dapat diabaikan; namun, untuk
layanan percakapan seperti VoIP, penundaan yang lama dapat mengganggu jika tidak dapat ditoleransi. Idealnya, kami
ingin penundaan playout diminimalkan dengan batasan bahwa kerugian di bawah beberapa persen. 
Cara alami untuk menangani trade-off ini adalah dengan memperkirakan penundaan jaringan dan varian dari
penundaan jaringan, dan menyesuaikan penundaan pemutaran yang sesuai pada awal setiap lonjakan bicara.

7
 Penyesuaian adaptif penundaan pemutaran di awal semburan bicara ini akan menyebabkan periode diam pengirim
dikompresi dan diperpanjang; namun, kompresi dan pemanjangan keheningan dalam jumlah kecil tidak terlihat dalam
ucapan. Mengikuti [Ramjee 1994], sekarang menjelaskan algoritme umum yang dapat digunakan penerima untuk
menyesuaikan penundaan pemutarannya secara adaptif. Untuk tujuan ini, misalkan 
ti= stempel waktu ipaket ke-waktu paket dihasilkan oleh pengirim 
ri= waktu paket i diterima oleh penerima 
pi= waktu paket i diputar di penerima 
Penundaan jaringan ujung ke ujung dari i paket ke-i adalah ri-pi. Karena jitter jaringan, penundaan ini akan
bervariasi dari paket ke paket. Mari d menunjukkan perkiraan rata-rata delay jaringan pada penerimaan I th i  paket.
Perkiraan ini dibangun dari stempel waktu sebagai berikut: 
di=(1−u)di−1+u(ri−ti) 
dimana u adalah konstanta tetap (misalnya,u=0.01 ). Jadi d adalah rata-rata yang dihaluskan dari yang diamati
penundaan jaringan r1−t1,…,ri−ti Perkiraan ini memberi bobot lebih pada penundaan jaringan yang baru-baru ini diamati
daripada penundaan jaringan yang diamati di masa lalu. Bentuk perkiraan ini tidak boleh sepenuhnya asing; ide yang
sama digunakan untuk memperkirakan waktu pulang pergi di TCP. Biarkan v menunjukkan perkiraan deviasi rata-rata
penundaan dari perkiraan penundaan rata-rata. Ini perkiraan juga dibangun dari cap waktu:
vi=(1−u)vi−1+u| ri−ti−di|
Estimasi d dan v dihitung untuk setiap paket yang diterima, meskipun hanya digunakan untuk
tentukan titik playout untuk paket pertama dalam setiap semburan bicara. Setelah menghitung perkiraan ini, penerima
menggunakan algoritme berikut untuk pemutaran paket. Jika paket i adalah paket pertama dari semburan bicara, waktu
pemutarannya, p, dihitung sebagai:
pi=ti+di+Kvi 
Dimana K adalah konstanta positif (misalnya, K=4 ). Maksud dari Kvi adalah untuk mengatur waktu pemutaran
cukup jauh ke depan sehingga hanya sebagian kecil dari paket yang tiba di talk spurt akan hilang karena kedatangan yang
terlambat. Titik pemutaran untuk paket berikutnya dalam semburan bicara dihitung sebagai offset dari titik waktu ketika
paket pertama dalam semburan bicara dimainkan. Secara khusus, misalkan 
qi=pi−ti 
adalah lamanya waktu dari saat paket pertama dalam semburan bicara dihasilkan hingga paket tersebut dimainkan. Jika
paket j juga termasuk dalam semburan bicara ini, ia dimainkan pada waktu 
pj=tj+qi
Algoritma yang baru saja dijelaskan masuk akal dengan asumsi bahwa penerima dapat mengetahui apakah sebuah
paket adalah paket pertama dalam semburan bicara. Ini dapat dilakukan dengan memeriksa energi sinyal di setiap paket
yang diterima. 
9.3.3 Memulihkan dari Packet Loss 
Sekarang akan dijelaskan secara singkat beberapa skema yang mencoba untuk mempertahankan kualitas audio
yang dapat diterima dengan adanya packet loss. Skema seperti ini disebut skema pemulihan kerugian. Di sini kita
mendefinisikan packet loss adalah sebuah paket hilang, baik jika tidak pernah sampai di penerima atau jika tiba setelah
waktu pemutaran yang dijadwalkan. Contoh VoIP kami akan kembali berfungsi sebagai konteks untuk menggambarkan
skema pemulihan kerugian.  Aplikasi VoIP menggunakan dua jenis skema antisipasi kerugian, yaitu:
1. Forward Error Correction (FEC) 

8
 Ide dasar dari FEC adalah untuk menambahkan informasi yang berlebihan ke aliran paket asli. Untuk biaya
sedikit meningkatkan laju transmisi, informasi yang berlebihan dapat digunakan untuk merekonstruksi perkiraan atau
versi yang tepat dari beberapa paket yang hilang. Mengikuti [Bolot 1996] dan [Perkins 1998], kami sekarang
menguraikan dua mekanisme FEC sederhana. Mekanisme pertama mengirimkan potongan yang dikodekan
berlebihan setelah setiap n potongan. Potongan redundan diperoleh dengan eksklusif OR-ing n potongan asli
n+1 [Shacham 1990]. Dengan cara ini jika salah satu paket dari kelompok paket hilang, penerima dapat sepenuhnya
merekonstruksi paket yang hilang. Tetapi jika dua atau lebih paket dalam satu grup hilang, penerima tidak dapat
merekonstruksi paket yang hilang. Dengan menjaga , ukuran grup, kecil, sebagian besar dari paket yang
hilang n+1 dapat dipulihkan ketika kehilangan tidak berlebihan. Namun, semakin kecil ukuran grup, semakin
besar peningkatan relatif dari tingkat transmisi. Secara khusus, laju transmisi meningkat dengan faktor 1/n, sehingga
jika kemudian laju transmisi meningkat sebesar 33 persen. Selanjutnya, skema sederhana n=3 ini, meningkatkan
penundaan pemutaran, karena penerima harus menunggu untuk menerima seluruh kelompok paket sebelum dapat
memulai pemutaran. Untuk detail lebih praktis tentang cara kerja FEC untuk transportasi multimedia, lihat [RFC
5109]. 
Mekanisme FEC kedua adalah mengirimkan aliran audio beresolusi lebih rendah sebagai informasi yang
berlebihan. Misalnya, pengirim mungkin membuat aliran audio nominal dan aliran audio dengan kecepatan bit
rendah dan resolusi rendah yang sesuai. (Aliran nominal dapat berupa pengkodean PCM pada 64 kbps, dan aliran
berkualitas rendah dapat berupa penyandian GSM pada 13 kbps.) Aliran laju bit rendah disebut sebagai redundan 
aliran. Seperti yang ditunjukkan pada Gambar 9.5, pengirim membangun npaket ke-dengan mengambil npotongan
ke-dari (n−1) aliran nominal dan menambahkan potongan pertama dari aliran yang berlebihan. Dengan cara ini,
setiap kali ada kehilangan paket yang tidak berurutan, penerima dapat menyembunyikan kehilangan dengan
memainkan potongan kode bit rate rendah yang datang dengan paket berikutnya. Tentu saja, potongan kecepatan bit
rendah memberikan kualitas yang lebih rendah daripada potongan nominal. Namun, aliran sebagian besar potongan
berkualitas tinggi, potongan kualitas rendah sesekali, dan tidak ada potongan yang hilang memberikan kualitas audio
yang baik secara keseluruhan. Perhatikan bahwa dalam skema ini, penerima hanya perlu menerima dua paket
sebelum pemutaran, sehingga peningkatan penundaan pemutaran kecil. Selanjutnya, jika pengkodean laju bit rendah
jauh lebih kecil daripada pengkodean nominal, maka peningkatan marjinal dalam laju transmisi akan kecil. 
Untuk mengatasi kerugian berturut-turut, kita dapat menggunakan variasi sederhana. Alih-alih menambahkan
hanya(n−1) (n−1) (nbit2) potongan laju bit rendah st ke- n ke potongan nominal, pengirim dapat menambahkan
potongan rendah st dan nd (n−1) (n 3) potongan laju bit, atau tambahkan potongan laju bit rendah st dan rd, dan
seterusnya. Dengan menambahkan potongan bit rate yang lebih rendah ke setiap potongan nominal, kualitas audio
pada penerima menjadi dapat diterima untuk variasi yang lebih luas dari lingkungan usaha terbaik yang keras. Di sisi
lain, potongan tambahan meningkatkan bandwidth transmisi dan penundaan pemutaran. 

9
 Gambar 9.5 Membonceng informasi redundan berkualitas rendah
 Interleaving 
Sebagai alternatif untuk transmisi redundan, aplikasi VoIP dapat mengirim audio interleaved. Seperti ditunjukkan
pada Gambar 9.6, pengirim mengurutkan ulang unit data audio sebelum transmisi, sehingga unit yang awalnya
berdekatan dipisahkan oleh jarak tertentu dalam aliran yang ditransmisikan. Interleaving dapat mengurangi efek
packet loss. Gambar 9.6 menunjukkan bahwa hilangnya satu paket dari aliran interleaved menghasilkan beberapa
celah kecil dalam aliran yang direkonstruksi, sebagai lawan dari celah besar tunggal yang akan terjadi pada aliran
yang tidak disisipkan. Interleaving dapat secara signifikan meningkatkan kualitas yang dirasakan dari aliran audio
[Perkins 1998]. Ini juga memiliki overhead yang rendah. Kerugian yang jelas dari interleaving adalah meningkatkan
latency.
 Penyembunyian Kesalahan

Gambar 9.6 Mengirimaudio yang disisipkan

Skema penyembunyian kesalahan berusaha menghasilkan pengganti untuk paket yang hilang yang serupa
dengan aslinya. Seperti yang dibahas dalam [Perkins 1998], ini dimungkinkan karena audio sinyal, dan khususnya
ucapan,
Bentuk paling sederhana dari pemulihan berbasis penerima adalah pengulangan paket. Pengulangan paket menggantikan
paket yang hilang dengan salinan paket yang tiba segera sebelum kehilangan. Ini memiliki kompleksitas komputasi yang
rendah dan berkinerja cukup baik. Bentuk lain dari pemulihan berbasis penerima adalah interpolasi, yang menggunakan
audio sebelum dan sesudah kehilangan untuk menginterpolasi paket yang sesuai untuk menutupi kehilangan
9.3.4 Studi Kasus: VoIP dengan Skype
Skype adalah aplikasi VoIP yang sangat populer dengan lebih dari 50 juta akun aktif setiap hari. Selain
menyediakan layanan VoIP host-to-host, Skype menawarkan layanan host-to-phone, layanan telepon-ke-host, dan
layanan konferensi video host-to-host multi-pihak. Skype diakuisisi oleh Microsoft pada tahun 2011.
Karena protokol Skype adalah hak milik, dan karena semua paket kontrol dan media Skype dienkripsi, maka sulit
untuk secara tepat menentukan bagaimana Skype beroperasi. Namun demikian, dari situs Web Skype dan beberapa studi
pengukuran, peneliti telah mempelajari cara kerja Skype secara umum [Baset 2006; Guha 2006; Chen 2006; Suh 2006;
Ren 2006; Zhang X 2012]. Untuk suara dan video, klien Skype memiliki banyak codec yang berbeda, yang mampu
mengkodekan media pada berbagai tingkat dan kualitas. Misalnya, kecepatan video untuk Skype telah diukur serendah

10
30 kbps untuk sesi berkualitas rendah hingga hampir 1 Mbps untuk sesi berkualitas tinggi [Zhang X 2012]. Biasanya,
kualitas audio Skype lebih baik daripada kualitas "POTS" (Layanan Telepon Lama Biasa) yang disediakan oleh sistem
telepon kabel. (Codec Skype biasanya mengambil sampel suara pada 16.000 sampel/dtk atau lebih tinggi, yang
memberikan nada lebih kaya daripada POTS, yang mengambil sampel pada 8.000/dtk.) Secara default, Skype
mengirimkan paket audio dan video melalui UDP. Namun, paket kontrol dikirim melalui TCP, dan paket media juga
dikirim melalui TCP ketika firewall memblokir aliran UDP. Skype menggunakan FEC untuk pemulihan kehilangan
untuk aliran suara dan video yang dikirim melalui UDP. Klien Skype juga mengadaptasi aliran audio dan video yang
dikirimnya ke kondisi jaringan saat ini, dengan mengubah kualitas video dan overhead FEC [Zhang X 2012].

9.4 Protokol untuk Aplikasi Percakapan Real-Time

Aplikasi Percakapan Real-Time, termasuk VoIP dan konferensi video, sangat menarik dan sangat populer. Oleh karena
itu tidak mengherankan bahwa badan standar, seperti IETF dan ITU, sibuk selama bertahun-tahun (dan terus sibuk!)
dalam menyusun standar untuk kelas aplikasi ini.
Dengan standar yang sesuai untuk aplikasi percakapan real-time, independen perusahaan menciptakan produk baru yang
saling beroperasi satu sama lain. Pada bagian ini kita memeriksa RTP dan SIP untuk aplikasi percakapan real-time.

9.4.1 RTP
Di bagian sebelumnya, kita mengetahui bahwa sisi pengirim dari aplikasi VoIP menambahkan bidang header ke potongan
audio sebelum meneruskannya ke lapisan transport. Bidang ini termasuk urutan nomor dan stempel waktu. Karena
sebagian besar aplikasi jaringan multimedia dapat menggunakan urutan nomor dan stempel waktu, akan lebih mudah
untuk memiliki struktur paket standar yang mencakup bidang untuk data audio/video, nomor urut, dan stempel waktu,
serta bidang lain yang berpotensi berguna. RTP, didefinisikan dalam RFC 3550. RTP dapat digunakan untuk mengangkut
format umum seperti: PCM, ACC, dan MP3 untuk suara dan MPEG dan H.263 untuk video. Hal ini juga dapat digunakan
untuk mengangkut format suara dan video eksklusif. Saat ini, RTP menikmati implementasi luas di banyak produk dan
prototipe penelitian. Ini juga melengkapi protokol interaktif real-time penting lainnya, seperti SIP.

Gambar 9.7 Bidang Header RTP

Seperti yang ditunjukkan pada Gambar 9.8, empat bidang header paket RTP utama adalah jenis muatan, urutan nomor,
stempel waktu, dan bidang pengenal sumber. Bidang jenis muatan dalam paket RTP panjangnya 7 bit. Untuk aliran audio,
bidang jenis muatan adalah digunakan untuk menunjukkan jenis pengkodean audio (misalnya, PCM, modulasi delta
adaptif, linier pengkodean prediktif) yang sedang digunakan. Jika pengirim memutuskan untuk mengubah penyandian di
tengah sesi a, pengirim dapat menginformasikan penerima perubahan melalui bidang jenis muatan ini. Pengirim mungkin
ingin mengubah penyandian untuk meningkatkan kualitas audio atau mengurangi aliran RTP kecepatan bit.
9.4.2 SIP
Session Initiation Protocol (SIP), didefinisikan dalam [RFC 3261; RFC 5411], terbuka dan protokol yang ringan yang
melakukan hal berikut:
- Menyediakan mekanisme untuk membuat panggilan antara pemanggil dan yang dipanggil melalui jaringan IP.
Memungkinkan penelepon untuk memberi tahu yang dipanggil bahwa ia ingin memulai panggilan. Hal ini

11
 memungkinkan para pengguna untuk menyetujui pengkodean media. Hal ini juga memungkinkan pengguna
untuk mengakhiri panggilan.
- Menyediakan mekanisme bagi penelepon untuk menentukan alamat IP saat ini dari callee. Pengguna tidak
memiliki satu alamat IP tetap karena alamat tersebut dapat diberikan alamat secara dinamis (menggunakan
DHCP) dan karena mereka mungkin memiliki beberapa perangkat IP, masing-masing dengan alamat IP yang
berbeda.
- Menyediakan mekanisme untuk manajemen panggilan, seperti menambahkan aliran media baru selama
panggilan, mengubah penyandian selama panggilan, mengundang pengguna baru selama panggilan, transfer
panggilan, dan memegang panggilan.

Menyiapkan Panggilan ke Alamat IP yang Diketahui

Untuk memahami esensi SIP, yang terbaik adalah melihat contoh konkret. Dalam contoh ini, Alice ada di PC-nya dan dia
ingin menelepon Bob, yang juga bekerja di PC-nya. PC Alice dan Bob keduanya dilengkapi dengan perangkat lunak
berbasis SIP untuk melakukan dan menerima panggilan telepon. Dalam contoh awal ini, kita akan asumsikan bahwa Alice
mengetahui alamat IP PC Bob. Gambar 9.9 mengilustrasikan proses pembuatan panggilan SIP.

Gambar 9.8 Pembentukan panggilan SIP ketika Alice mengetahui alamat IP Bob
Pada Gambar 9.8, kita melihat bahwa sesi SIP dimulai ketika Alice mengirimi Bob sebuah pesan INVITE, yang
menyerupai pesan permintaan HTTP. Pesan INVITE ini dikirim melalui UDP ke port yang terkenal 5060 untuk SIP.
(Pesan SIP juga dapat dikirim melalui TCP.) Pesan INVITE menyertakan pengidentifikasi untuk Bob
(bob@193.64.210.89), indikasi alamat IP Alice saat ini, indikasi bahwa Alice keinginan untuk menerima audio, yang
akan dikodekan dalam format AVP 0 (PCM encoded -law) dan dienkapsulasi dalam RTP, dan indikasi bahwa dia ingin
menerima paket RTP pada port 38060. Setelah menerima pesan INVITE Alice, Bob mengirimkan pesan respons SIP,
yang menyerupai HTTP pesan tanggapan. Pesan SIP tanggapan ini juga dikirim ke port SIP 5060. Tanggapan Bob
termasuk 200 OK serta indikasi alamat IP-nya, pengkodean yang diinginkan dan paketisasi untuk penerimaan, dan nomor
12
portnya ke mana paket audio harus dikirim. Perhatikan bahwa dalam contoh ini Alice dan Bob akan menggunakan
mekanisme pengkodean audio yang berbeda: Alice diminta untuk menyandikannya audio dengan GSM sedangkan Bob
diminta untuk mengkodekan audionya dengan PCM. Setelah menerima Bob's respon, Alice mengirimkan Bob pesan
pengakuan SIP. Setelah transaksi SIP ini, Bob dan Alice bisa berbicara. (Untuk kenyamanan visual, Gambar 9.9
menunjukkan Alice berbicara setelah Bob, tetapi sebenarnya mereka akan melakukannya biasanya berbicara pada saat
yang sama.) Bob akan mengkodekan dan mengemas audio seperti yang diminta dan mengirim paket audio ke nomor port
38060 pada alamat IP 167.180.112.24. Alice juga akan mengkodekan dan mengemas audio seperti yang diminta dan
kirim paket audio ke nomor port 48753 di alamat IP 193.64.210.89.

Dari contoh sederhana ini, kita telah mempelajari sejumlah karakteristik utama SIP. Pertama, SIP adalah protokol out of-
band: Pesan SIP dikirim dan diterima di soket yang berbeda dari yang digunakan untuk mengirim dan menerima data
media. Kedua, pesan SIP itu sendiri dapat dibaca ASCII dan menyerupai pesan HTTP. Ketiga, SIP membutuhkan semua
pesan untuk diakui, sehingga dapat dijalankan melalui UDP atau TCP.

Alamat SIP
Pada contoh sebelumnya, alamat SIP Bob adalah sip:bob@193.64.210.89. Namun, kami berharap banyak—jika bukan
kebanyakan—alamat SIP agar menyerupai alamat email. Misalnya, alamat Bob mungkin sip: bob@domain.com. Saat
perangkat SIP Alice mengirim pesan INVITE, pesan tersebut akan sertakan alamat seperti email ini; infrastruktur SIP
kemudian akan merutekan pesan ke perangkat IP yang Bob gunakan saat ini. Bentuk lain yang mungkin untuk alamat SIP
adalah Nomor telepon Bob atau hanya nama depan/tengah/belakang Bob.
Sebuah fitur menarik dari alamat SIP adalah bahwa mereka dapat dimasukkan dalam halaman Web, seperti halnya alamat
email orang yang disertakan dalam halaman Web dengan URL mail to. Misalnya, Bob memiliki homepage pribadi, dan
dia ingin menyediakan sarana bagi pengunjung homepage untuk memanggilnya. Dia bisa kemudian cukup sertakan URL
sip:bob@domain.com. Ketika pengunjung mengklik URL, SIP aplikasi di perangkat pengunjung diluncurkan dan pesan
INVITE dikirim ke Bob.

Pesan SIP
Dalam pengantar singkat SIP ini, kami tidak akan membahas semua jenis dan header pesan SIP. Sebagai gantinya, kami
akan mengambil sekilas pada pesan SIP INVITE, bersama dengan beberapa baris header umum. Mari kita asumsikan lagi
bahwa Alice ingin memulai panggilan VoIP ke Bob, dan kali ini Alice hanya tahu alamat SIP Bob, bob@domain.com,
dan tidak mengetahui alamat IP perangkat yang digunakan Bob saat ini. Kemudian pesannya mungkin terlihat seperti ini:

13
Baris INVITE menyertakan versi SIP, seperti halnya pesan permintaan HTTP. Kapanpun SIP pesan melewati perangkat
SIP (termasuk perangkat yang memulai pesan), ia melampirkannya melalui header, yang menunjukkan alamat IP
perangkat. (Kita akan segera melihat bahwa pesan INVITE melewati banyak perangkat SIP sebelum sampai ke aplikasi
SIP penerima.) Mirip dengan pesan email, pesan SIP menyertakan baris header Dari dan baris header Ke. Pesan termasuk
Call-ID, yang secara unik mengidentifikasi panggilan (mirip dengan pesan-ID di email). Ini termasuk Baris header
Content-Type, yang mendefinisikan format yang digunakan untuk mendeskripsikan konten yang terdapat dalam SIP
pesan. Ini juga termasuk baris header Content-Length, yang menyediakan panjang dalam byte dari isi dalam pesan.
Akhirnya, setelah carriage return dan line feed, pesan berisi konten. Dalam hal ini, konten memberikan informasi tentang
alamat IP Alice dan bagaimana Alice ingin menerima audionya.

Terjemahan Nama dan Lokasi Pengguna

Pada contoh pada Gambar 9.8, kami berasumsi bahwa perangkat SIP Alice mengetahui alamat IP di mana Bob dapat
dihubungi. Tetapi asumsi ini cukup tidak realistis, bukan hanya karena alamat IP sering secara dinamis ditetapkan dengan
DHCP, tetapi juga karena Bob mungkin memiliki beberapa perangkat IP (misalnya, perangkat yang berbeda untuk rumah,
kantor, dan mobilnya). Jadi sekarang mari kita anggap bahwa Alice hanya mengetahui alamat email Bob,
bob@domain.com, dan alamat yang sama ini digunakan untuk panggilan berbasis SIP. Dalam hal ini, Alice perlu
mendapatkan alamat IP perangkat yang sedang digunakan pengguna bob@domain.com. Untuk mengetahui hal ini, Alice
membuat pesan INVITE yang dimulai dengan INVITE bob@domain.com SIP/2.0 dan mengirimkan pesan ini ke proxy
SIP. Proxy akan merespons dengan balasan SIP yang mungkin menyertakan alamat IP perangkat yang saat ini digunakan
bob@domain.com. Atau, balasannya mungkin menyertakan alamat IP kotak pesan suara Bob, atau mungkin menyertakan
URL halaman Web (yang mengatakan "Bob sedang tidur. Tinggalkan aku sendiri!"). Juga, hasil yang dikembalikan oleh
proxy mungkin bergantung pada penelepon: Jika panggilan itu dari istri Bob, dia mungkin menerima panggilan dan
memberikan alamat IP-nya; jika panggilan itu dari ibu mertua Bob, dia mungkin akan menjawab dengan URL yang
mengarah ke halaman Web saya sedang tidur!
Sekarang, Anda mungkin bertanya-tanya, bagaimana server proxy dapat menentukan alamat IP saat ini untuk
bob@domain.com? Untuk menjawab pertanyaan ini, kita perlu mengatakan beberapa kata tentang perangkat SIP lain,
pendaftar SIP. Setiap pengguna SIP memiliki registrar terkait. Setiap kali pengguna meluncurkan SIP aplikasi pada
perangkat, aplikasi mengirimkan pesan register SIP ke registrar, menginformasikan registrar dari alamat IP saat ini.
Misalnya, ketika Bob meluncurkan aplikasi SIP-nya di PDA-nya, aplikasi akan mengirim pesan di sepanjang baris:

Pencatat Bob melacak alamat IP Bob saat ini. Setiap kali Bob beralih ke perangkat SIP baru, perangkat baru mengirim
pesan register baru, yang menunjukkan alamat IP baru. Juga, jika Bob tetap diperangkat yang sama untuk waktu yang
lama, perangkat akan mengirim pesan daftar penyegaran, menunjukkan bahwa alamat IP yang terakhir dikirim masih

14
valid. (Pada contoh di atas, segarkan pesan perlu dikirim setiap 3600 detik untuk mempertahankan alamat di server
pencatat.) Perlu diperhatikanbahwa registrar dianalogikan dengan server nama otoritatif DNS: Server DNS
menerjemahkan host tetap nama ke alamat IP tetap; pencatat SIP menerjemahkan pengidentifikasi manusia tetap
(misalnya, bob@domain.com) ke alamat IP dinamis. Seringkali pendaftar SIP dan proksi SIP dijalankan di tempat yang
sama tuan rumah.
Sekarang mari kita periksa bagaimana server proxy SIP Alice mendapatkan alamat IP Bob saat ini. Dari diskusi
sebelumnya, kita melihat bahwa server proxy hanya perlu meneruskan pesan INVITE Alice ke Bob pendaftar/proksi.
Pencatat/proksi kemudian dapat meneruskan pesan ke perangkat SIP Bob saat ini. Akhirnya, Bob, setelah menerima
pesan INVITE Alice, dapat mengirim tanggapan SIP ke Alice.
Sebagai contoh, perhatikan Gambar 9.9, di mana jim@umass.edu, saat ini mengerjakan 217.123.56.89, ingin memulai
sesi Voice-over-IP (VoIP) dengan keith@upenn.edu, saat ini sedang mengerjakan 197.87.54.21. Perhatikan langkah-
langkah berikut :

Gambar 9.9 Inisiasi sesi, yang melibatkan proxy dan pendaftar SIP
(1) Jim mengirim pesan INVITE ke umass SIP proxy.
(2) Proksi melakukan pencarian DNS di SIP registrar upenn.edu (tidak ditampilkan dalam diagram) dan
kemudian meneruskan pesan ke server registrar.
(3) Karena keith@upenn.edu tidak lagi terdaftar di registrar upenn, registrar upenn mengirimkan
respons pengalihan, yang menunjukkan bahwa ia harus mencoba keith@nyu.edu.
(4) Proksi umass mengirimkan pesan INVITE ke registrar SIP NYU.
(5) Pencatat NYU mengetahui alamat IP keith@upenn.edu dan meneruskan pesan INVITE ke host 197.87.54.21,
yang menjalankan klien SIP Keith.
(6–8) Respons SIP dikirim kembali melalui pendaftar/proksi ke klien SIP pada 217.123.56.89.
(9) Media adalah dikirim langsung antara dua klien. (Ada juga pesan pengakuan SIP, yang bukan ditampilkan.)

9.5 Support Network Untuk Multimedia

15
Di Bagian 9.2 hingga 9.4, kita mempelajari bagaimana mekanisme tingkat aplikasi seperti buffering klien, prefetching,
mengadaptasi kualitas media ke bandwidth yang tersedia, playout adaptif, dan mitigasi kerugian teknik dapat digunakan
oleh aplikasi multimedia untuk meningkatkan kinerja aplikasi multimedia.
Kita juga mempelajari bagaimana jaringan distribusi konten dan jaringan overlay P2P dapat digunakan untuk
menyediakan pendekatan tingkat sistem untuk menyampaikan konten multimedia. Teknik dan pendekatan ini semuanya
dirancang untuk digunakan dalam upaya Internet terbaik saat ini. Memang, mereka digunakan saat ini justru karena
Internet hanya menyediakan satu kelas layanan dengan upaya terbaik. Tetapi sebagai perancang jaringan komputer, kami
mau tidak mau bertanya apakah jaringan (bukan aplikasi atau infrastruktur tingkat aplikasi sendiri) mungkin
menyediakan mekanisme untuk mendukung pengiriman konten multimedia. Seperti yang akan kita lihat sebentar lagi,
jawabannya adalah, tentu saja, "ya"! Tetapi kita juga akan melihat bahwa sejumlah mekanisme tingkat jaringan baru ini
masih harus disebarkan secara luas. Ini mungkin karena kompleksitasnya dan fakta bahwa level aplikasi teknik bersama
dengan layanan upaya terbaik dan sumber daya jaringan berdimensi benar (misalnya, bandwidth) memang dapat
menyediakan multimedia end-to-end yang “cukup baik” (walaupun tidak selalu sempurna).

Tabel 9.4 merangkum tiga pendekatan luas untuk menyediakan dukungan tingkat jaringan untuk multimedia aplikasi.
- Membuat servis terbaik dari layanan terbaik. Mekanisme dan infrastruktur tingkat aplikasi yang kami pelajari di
Bagian 9.2 hingga 9.4 dapat berhasil digunakan dalam jaringan yang berdimensi baik, dimana packet loss dan
delay end-to-end yang berlebihan jarang terjadi. Ketika permintaan meningkat adalah diperkirakan ISP
menyebarkan bandwidth tambahan dan kapasitas switching untuk terus memastikan penundaan yang memuaskan
dan kinerja packet-loss [Huang 2005]. Kami akan membahas jaringan seperti itu dimensi lebih lanjut dalam
Bagian 9.5.1.
- Layanan yang dibedakan. Sejak awal Internet, telah dibayangkan bahwa berbagai jenis lalu lintas (misalnya,
seperti yang ditunjukkan dalam bidang Jenis Layanan di header paket IP4v) dapat menjadi disediakan dengan
kelas layanan yang berbeda, daripada layanan satu ukuran untuk semua upaya terbaik. Dengan layanan yang
berbeda, satu jenis lalu lintas mungkin diberikan prioritas ketat di atas kelas lain lalu lintas ketika kedua jenis lalu
lintas antri di router. Misalnya, paket milik aplikasi percakapan waktu nyata mungkin diprioritaskan daripada
paket lain karena penundaannya yang ketat kendala. Memperkenalkan layanan yang berbeda ke dalam jaringan
akan membutuhkan mekanisme baru untuk penandaan paket (menunjukkan kelas layanan paket), penjadwalan
paket, dan banyak lagi. Kami akan membahasnya layanan yang berbeda, dan mekanisme jaringan baru yang
diperlukan untuk mengimplementasikan layanan ini, di Bagian 9.5.2 dan 9.5.3.

16
 - Jaminan Kualitas Layanan (QoS) Per-koneksi. Dengan jaminan QoS per koneksi, setiap instance aplikasi secara
eksplisit mencadangkan bandwidth end-to-end dan dengan demikian memiliki jaminan kinerja ujung ke ujung.
Jaminan keras berarti aplikasi akan menerima kualitas yang diminta layanan (QoS) dengan pasti. Jaminan lunak
berarti aplikasi akan menerima permintaannya kualitas layanan dengan probabilitas tinggi. Misalnya, jika
pengguna ingin melakukan panggilan VoIP dari Host A ke Host B, aplikasi VoIP pengguna mencadangkan
bandwidth secara eksplisit di setiap tautan di sepanjang rute antara kedua host. Tetapi mengizinkan aplikasi untuk
membuat reservasi dan membutuhkan jaringan untuk menghormati pemesanan membutuhkan beberapa
perubahan besar. Pertama, kita membutuhkan protokol yang, atas nama aplikasi, cadangan link bandwidth pada
jalur dari pengirim ke penerima mereka. Kedua, kita akan perlu kebijakan penjadwalan baru dalam antrian router
sehingga reservasi bandwidth per koneksi dapat dihormati. Terakhir, untuk melakukan reservasi, aplikasi harus
memberikan jaringan deskripsi lalu lintas yang ingin mereka kirim ke jaringan dan jaringan perlu dipolisikan
setiap lalu lintas aplikasi untuk memastikan bahwa aplikasi mematuhi deskripsi itu. Mekanisme ini, ketika
digabungkan, memerlukan perangkat lunak baru dan kompleks di host dan router. Karena QoS per koneks i
layanan terjamin belum melihat penerapan yang signifikan, kami akan membahas mekanisme ini hanya secara
singkat di Bagian 9.5.4.

9.5.1 Dimensi Jaringan Upaya Terbaik

Pada dasarnya, kesulitan dalam mendukung aplikasi multimedia muncul dari ketatnya persyaratan kinerja dan fakta
bahwa paket delay, delay jitter, dan loss terjadi setiap kali jaringan menjadi padat. Pendekatan pertama untuk
meningkatkan kualitas aplikasi multimedia hanya untuk "membuang uang ke masalah" dan dengan demikian hanya
menghindari pertengkaran sumber daya. Dalam hal multimedia jaringan, ini berarti menyediakan cukup kapasitas tautan
di seluruh jaringan sehingga kemacetan jaringan, dan penundaan paket yang diakibatkannya dan kerugian, tidak pernah
(atau hanya sangat jarang) terjadi. Dengan kapasitas tautan yang cukup, paket dapat melewati hari ini Internet tanpa
antrian delay atau loss. Dari banyak perspektif, ini adalah situasi yang ideal—multimedia aplikasi akan bekerja dengan
sempurna, pengguna akan senang, dan ini semua dapat dicapai tanpa perubahan arsitektur upaya terbaik Internet.
17
Mengingat bahwa upaya terbaik Internet saat ini dapat (dari sudut pandang teknologi) mendukung lalu lintas multimedia
ditingkat kinerja yang sesuai jika itu berdimensi untuk melakukannya, pertanyaan alami adalah mengapa hari ini Internet
tidak melakukannya. Jawabannya terutama ekonomi dan organisasi. Dari ekonomi sudut pandang, apakah pengguna
bersedia membayar ISP mereka cukup untuk ISP memasang bandwidth yang cukup untuk mendukung aplikasi
multimedia melalui Internet upaya terbaik? Masalah organisasi mungkin bahkan organizational lebih menakutkan.
Perhatikan bahwa jalur ujung ke ujung antara dua titik akhir multimedia akan melewati will jaringan beberapa ISP. Dari
sudut pandang organisasi, apakah ISP ini mau bekerja sama? (mungkin dengan bagi hasil) untuk memastikan bahwa jalur
ujung ke ujung memiliki dimensi yang tepat untuk mendukung aplikasi multimedia? Untuk perspektif tentang masalah
ekonomi dan organisasi ini, lihat [Davies 2005]. Untuk perspektif tentang penyediaan jaringan backbone tier-1 untuk
mendukung lalu lintas yang sensitif terhadap penundaan, lihat [Fraleigh 2003].

9.5.2 Menciptakan Berbagai Kelas Layanan

Mungkin peningkatan paling sederhana untuk layanan satu ukuran untuk semua upaya terbaik di Internet saat ini adalah
untuk membagi lalu lintas ke dalam kelas-kelas, dan memberikan tingkat layanan yang berbeda untuk kelas lalu lintas
yang berbeda ini. Untuk misalnya, ISP mungkin ingin menyediakan kelas layanan yang lebih tinggi untuk Voice-over-IP
yang sensitif terhadap penundaan atau lalu lintas telekonferensi (dan biaya lebih untuk layanan ini!) daripada lalu lintas
elastis seperti e-mail atau HTTP.
Atau, ISP mungkin hanya ingin memberikan kualitas layanan yang lebih tinggi kepada pelanggan yang bersedia
membayar lebih untuk layanan yang ditingkatkan ini. Sejumlah ISP akses kabel perumahan dan akses nirkabel seluler
ISP telah mengadopsi tingkat layanan berjenjang seperti itu — dengan pelanggan layanan platinum menerima yang lebih
baik kinerja daripada pelanggan layanan emas atau perak.
Kita semua akrab dengan berbagai kelas layanan dari kehidupan kita sehari-hari—penumpang maskapai penerbangan
kelas satu mendapatkan layanan yang lebih baik daripada penumpang kelas bisnis, yang pada gilirannya mendapatkan
layanan yang lebih baik daripada kami yang Terbang dengan kelas ekonomi; VIP disediakan akses langsung ke acara
sementara orang lain menunggu dalam antrean; sesepuh dihormati di beberapa negara dan menyediakan kursi
kehormatan dan makanan terbaik di meja. Ini penting untuk dicatat bahwa layanan diferensial tersebut disediakan di
antara kumpulan lalu lintas, yaitu, di antara kelas-kelas: lalu lintas, bukan di antara koneksi individu. Misalnya, semua
penumpang kelas satu diperlakukan sama (dengan tidak ada penumpang kelas satu yang menerima perlakuan lebih baik
dari penumpang kelas satu lainnya), hanya karena semua paket VoIP akan menerima perlakuan yang sama di dalam
jaringan, terlepas dari yang tertentu koneksi ujung ke ujung yang mereka miliki. Seperti yang akan kita lihat, dengan
menangani sejumlah kecil lalu lintas agregat, daripada sejumlah besar koneksi individu, mekanisme jaringan baru
diperlukan untuk memberikan layanan yang lebih baik dari yang terbaik dapat dibuat relatif sederhana.
Perancang Internet awal jelas memiliki gagasan tentang beberapa kelas layanan ini dalam pikiran. Ingat field type-of-
service (ToS) di header IPv4 yang dibahas dalam Bab 4. IEN123 [ISI 1979] menjelaskan Bidang ToS juga hadir dalam
leluhur datagram IPv4 sebagai berikut: “Jenis Layanan [bidang] memberikan indikasi parameter abstrak dari kualitas
layanan yang diinginkan. Parameter ini adalah digunakan untuk memandu pemilihan parameter layanan aktual saat
mentransmisikan datagram melalui gram jaringan tertentu. Beberapa jaringan menawarkan prioritas layanan, yang entah
bagaimana memperlakukannya dengan baik mendahulukan lalu lintas karena lebih penting daripada lalu lintas lainnya.”
Lebih dari empat dekade lalu, visi the menyediakan tingkat layanan yang berbeda untuk kelas lalu lintas yang berbeda
sudah jelas! Namun, itu membawa kami jangka waktu yang sama lama untuk mewujudkan visi ini.

18
9.5.3 Diffserv
Setelah melihat motivasi, wawasan, dan mekanisme khusus untuk menyediakan berbagai kelas layanan, mari kita
selesaikan studi kita tentang pendekatan untuk membuktikan beberapa kelas layanan dengan sebuah contoh——
Arsitektur Internet Diffserv [RFC 2475; Kilkki 1999]. Diffserv menyediakan diferensiasi layanan—yaitu, kemampuan
untuk menangani kelas lalu lintas yang berbeda dengan cara yang berbeda dalam Internet dengan cara yang terukur.
Kebutuhan akan skalabilitas muncul dari fakta bahwa jutaan arus lalu lintas sumber-tujuan simultan simultaneous
mungkin ada di router backbone. Kita akan segera melihat bahwa kebutuhan ini dipenuhi dengan hanya menempatkan
yang sederhana fungsionalitas dalam inti jaringan, dengan operasi kontrol yang lebih kompleks diimplementasikan di
tepi jaringan.
Dalam beberapa kasus, pengguna akhir mungkin telah setuju untuk membatasi kecepatan pengiriman paketnya agar
sesuai dengan yang dideklarasikan profil lalu lintas. Profil lalu lintas mungkin berisi batas kecepatan puncak, serta
tingkat ledakan aliran paket, seperti yang kita lihat sebelumnya dengan mekanisme ember bocor. Selama pengguna
mengirim paket ke dalam jaringan dengan cara yang sesuai dengan profil lalu lintas yang dinegosiasikan, paket
menerima penandaan prioritasnya dan diteruskan sepanjang rutenya ke tujuan. Di sisi lain, jika profil lalu lintas adalah
dilanggar, paket di luar profil mungkin ditandai secara berbeda, mungkin berbentuk (misalnya, tertunda jadi bahwa
batasan kecepatan maksimum akan diamati), atau mungkin dijatuhkan di tepi jaringan. Peran fungsi pengukuran, yang
ditunjukkan pada Gambar 9.17, adalah untuk membandingkan aliran paket yang masuk dengan profil lalu lintas yang
dinegosiasikan dan untuk menentukan apakah sebuah paket berada dalam profil lalu lintas yang dinegosiasikan. Itu
keputusan aktual tentang apakah akan segera berkomentar, meneruskan, menunda, atau menjatuhkan paket adalah
masalah kebijakan ditentukan oleh administrator jaringan dan tidak ditentukan dalam arsitektur Diffserv.

Gambar 9.10. Contoh Jaringan Diffserv Sederhana

9.5.4 Jaminan Kualitas Layanan (QoS) Per Koneksi: Reservasi Sumber Daya dan Panggilan Masuk
Di bagian sebelumnya, kita telah melihat penandaan dan pemolisian paket, isolasi lalu lintas, dan level tautan
penjadwalan dapat memberikan satu kelas layanan dengan kinerja yang lebih baik dari yang lain. Di bawah tertentu
disiplin penjadwalan, seperti penjadwalan prioritas, kelas lalu lintas yang lebih rendah pada dasarnya "tidak terlihat"
untuk kelas lalu lintas dengan prioritas tertinggi. Dengan dimensi jaringan yang tepat, layanan kelas tertinggi dapat
memang mencapai packet loss dan delay yang sangat rendah—pada dasarnya kinerja seperti sirkuit. Tapi bisakah
jaringan menjamin bahwa aliran yang sedang berlangsung di kelas lalu lintas prioritas tinggi akan terus menerima seperti
layanan sepanjang durasi aliran hanya menggunakan mekanisme yang telah kami jelaskan sejauh ini? Saya tidak bisa. Di

19
bagian ini, kita akan melihat mengapa mekanisme dan protokol jaringan tambahan diperlukan ketika jaminan layanan
keras diberikan untuk koneksi individu.
Contoh motivasi kami pada Gambar 9.18 menyoroti perlunya beberapa mekanisme jaringan baru dan protokol jika
panggilan (aliran ujung ke ujung) akan dijamin kualitas layanan yang diberikan setelah dimulai:
- Reservasi sumber daya. Satu-satunya cara untuk menjamin bahwa panggilan akan memiliki sumber daya (tautan
bandwidth, buffer) yang diperlukan untuk memenuhi QoS yang diinginkan adalah dengan secara eksplisit
mengalokasikan sumber daya tersebut ke panggilan—proses yang dikenal dalam bahasa jaringan sebagai
reservasi sumber daya. Setelah sumber daya dicadangkan, panggilan memiliki akses sesuai permintaan ke sumber
daya ini selama durasinya, terlepas dari tuntutan semua panggilan lainnya. Jika panggilan cadangan dan
menerima jaminan link x Mbps bandwidth, dan tidak pernah mentransmisikan pada tingkat yang lebih besar dari
x, panggilan akan melihat bebas kerugian dan penundaan kinerja.
- Penerimaan panggilan. Jika sumber daya akan dicadangkan, maka jaringan harus memiliki mekanisme untuk
panggilan untuk meminta dan memesan sumber daya. Karena sumber daya tidak terbatas, panggilan membuat
panggilan masuk permintaan akan ditolak masuk, yaitu, diblokir, jika sumber daya yang diminta tidak tersedia.
Penerimaan panggilan semacam itu dilakukan oleh jaringan telepon—kami meminta sumber daya saat kami
melakukan panggilan jumlah.
- Pensinyalan pengaturan panggilan. Proses penerimaan panggilan yang dijelaskan di atas mengharuskan
panggilan dapat cadangan sumber daya yang cukup di setiap router jaringan di jalur sumber-ke-tujuan ke
memastikan bahwa persyaratan QoS end-to-end terpenuhi. Setiap router harus menentukan sumber daya lokal
diperlukan oleh sesi, pertimbangkan jumlah sumber dayanya yang sudah dikomit ke yang lain sesi yang sedang
berlangsung, dan menentukan apakah memiliki sumber daya yang cukup untuk memenuhi QoS per-hop
persyaratan sesi di router ini tanpa melanggar jaminan QoS lokal yang dibuat untuk sesi yang sudah diterima.
Protokol pensinyalan diperlukan untuk mengoordinasikan berbagai aktivitas ini—per-hop alokasi sumber daya
lokal, serta keputusan ujung-ke-ujung secara keseluruhan apakah panggilan tersebut telah dapat mencadangkan
sumber daya yang cukup di setiap router di jalur ujung ke ujung.

9.6 Ringkasan
Jaringan multimedia adalah salah satu perkembangan paling menarik di Internet saat ini. Orang-orang di seluruh dunia
semakin sedikit waktu di depan televisi mereka, dan malah menggunakan ponsel cerdas mereka dan perangkat untuk
menerima transmisi audio dan video, baik secara langsung maupun yang direkam sebelumnya. Apalagi, dengan situs-
situs seperti YouTube, pengguna telah menjadi produsen sekaligus konsumen konten Internet multimedia. Di Selain
distribusi video, Internet juga digunakan untuk mentransfer panggilan telepon. Bahkan, selama ini
10 tahun ke depan, Internet, bersama dengan akses Internet nirkabel, dapat membuat sistem telepon circuitswitched
tradisional menjadi sesuatu dari masa lalu. VoIP tidak hanya menyediakan layanan telepon murah, tetapi, juga
menyediakan berbagai layanan nilai tambah, seperti konferensi video, layanan direktori online, pesan suara, dan integrasi
ke jejaring sosial seperti Facebook dan WeChat.

Di Bagian 9.1, kami menggambarkan karakteristik intrinsik video dan suara, dan kemudian diklasifikasikan aplikasi
multimedia ke dalam tiga kategori: (i) streaming audio/video yang tersimpan, (ii) percakapan voice/video-over-IP, dan
(iii) streaming audio/video langsung.

20
Di Bagian 9.2, kami mempelajari streaming video yang disimpan secara mendalam. Untuk aplikasi streaming video,
video yang direkam sebelumnya ditempatkan di server, dan pengguna mengirim permintaan ke server ini untuk melihat
video sesuai permintaan. Kami melihat bahwa sistem video streaming dapat diklasifikasikan ke dalam dua kategori:
streaming UDP dan HTTP. Kami mengamati bahwa ukuran kinerja terpenting untuk streaming video adalah rata-rata
keluaran.

Di Bagian 9.3, kami memeriksa bagaimana aplikasi multimedia percakapan, seperti VoIP, dapat dirancang untuk
dijalankan melalui jaringan upaya terbaik. Untuk multimedia percakapan, pertimbangan waktu adalah: penting karena
aplikasi percakapan sangat sensitif terhadap penundaan. Di samping itu, aplikasi multimedia percakapan hilang—toleran
—kehilangan sesekali hanya menyebabkan sesekali gangguan dalam pemutaran audio/video, dan kehilangan ini sering
kali dapat disembunyikan sebagian atau seluruhnya. Kami melihat bagaimana kombinasi buffer klien, nomor urut paket,
dan cap waktu dapat sangat meringankan efek jitter yang diinduksi jaringan. Kami juga mensurvei teknologi di balik
Skype, salah satu yang terkemuka perusahaan voice- dan video-over-IP.

Di Bagian 9.4, kami memeriksa dua yang paling penting protokol standar untuk VoIP, yaitu, RTP dan SIP.

Di Bagian 9.5, kami memperkenalkan bagaimana beberapa mekanisme jaringan (disiplin penjadwalan tingkat tautan dan
polisi lalu lintas) dapat digunakan untuk memberikan layanan yang berbeda di antara beberapa kelas lalu lintas.

21