ungkinkan 

pengguna untuk membuat konferensi dengan tiga atau lebih 

peserta. Suara dan video percakapan banyak digunakan di 

Internet saat ini, dengan perusahaan-perusahaan Internet Skype, 

QQ, dan Google Talk.

c. Streaming Audio dan Video Langsung

Aplikasi kelas ketiga ini mirip dengan siaran radio tradisional 

dan televisi, kecuali pengiriman yang dilakukan melalui Internet. 

Aplikasi-aplikasi ini memungkinkan pengguna untuk menerima 

transmisi radio atau televisi secara langsung seperti acara 

olahraga langsung atau acara berita yang sedang berlangsung 

ditransmisikan dari pemain internet manapun di dunia. 

147

B. Streaming Video Yang Disimpan

Untuk streaming aplikasi video, video yang direkam sebelumnya 

ditempatkan di server, dan pengguna mengirim permintaan ke server 

untuk melihat video sesuai permintaan. Pengguna dapat menonton 

video dari awal hingga akhir tanpa gangguan, memungkinkan berhenti 

menonton video jauh sebelum vidio berakhir, atau berinteraksi dengan 

video mengubah posisi ke awal atau akhir. Sistem streaming video dapat 

diklasifikasikan ke dalam tiga kategori: Streaming UDP, streaming HTTP, 

dan streaming HTTP adaptif.

Karakteristik umum dari ketiga bentuk streaming video yaitu  

penggunaan buffering aplikasi sisi klien yang luas untuk mengurangi efek 

dari berbagai penundaan end-to-end dan berbagai jumlah bandwidth yang 

tersedia antara server dan klien. Untuk streaming video (baik disimpan dan 

hidup), pengguna biasanya dapat mentolerir penundaan awal beberapa 

detik kecil antara ketika klien meminta video dan ketika pemutaran video 

dimulai pada klien. 

Gambar 9.1 Keterlambatan Pemutaran Klien dalam Streaming Video

1. Streaming UDP

Dengan streaming UDP, server mentransmisikan video pada tingkat 

yang sesuai dengan tingkat konsumsi video klien dengan mencatat 

potongan video di atas UDP pada tingkat yang stabil. Misalnya, 

jika tingkat konsumsi video yaitu  2 Mbps dan setiap paket UDP 

membawa 8.000 bit video, maka server akan mengirimkan satu paket 

UDP ke dalam soketnya setiap (8000 bit) / (2 Mbps) = 4 Mbps

148

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 GET HTTP untuk URL tersebut. Server 

kemudian mengirim file video, dalam pesan tanggapan HTTP, secepat 

mungkin, yaitu, secepat kontrol kemacetan TCP dan kontrol aliran 

akan memungkinkan. Di sisi klien, bit dikumpulkan dalam buffer 

aplikasi klien. Setelah jumlah bit dalam buffer ini melebihi ambang 

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 lebih mudah (yang sering 

dikonfigurasi untuk memblokir sebagian besar lalu lintas UDP tetapi 

memungkinkan sebagian besar lalu lintas HTTP). Streaming melalui 

HTTP juga menunjukkan perlunya server kontrol media, seperti server 

RTSP, mengurangi biaya penyebaran skala besar melalui Internet. 

sebab  semua kelebihan ini, sebagian besar aplikasi streaming video 

termasuk YouTube dan Netflix memakai  streaming HTTP 

(melalui TCP) sebagai protokol streaming yang mendasarinya.

• Pra-pengambilan video

Seperti yang baru saja kita pelajari, buffer sisi-klien dapat digunakan 

untuk mengurangi efek dari berbagai penundaan end-to-end dan 

memvariasikan bandwidth yang tersedia. Untuk streaming video yang 

disimpan, klien dapat mencoba mengunduh video pada tingkat yang 

lebih tinggi dari tingkat konsumsi, sehingga mengambil frame video 

yang akan dikonsumsi di masa depan. Pengambilan vidio ini secara 

alami disimpan dalam buffer aplikasi klien. Pengambilan semacam 

itu terjadi secara alami dengan streaming TCP, sebab  mekanisme 

penghindaran kemacetan TCP akan berusaha memakai  semua 

bandwidth yang tersedia antara server dan klien.

• Penyangga Aplikasi Klien dan Penyangga TCP

Di sisi server, bagian dari file video berwarna putih telah dikirim ke 

soket server, sedangkan bagian darkened yaitu  yang masih harus 

dikirim. Setelah “melewati pintu soket,” byte ditempatkan di buffer 

149

kirim CCP sebelum dikirim ke Internet, sebab  buffer pengirim 

TCP di sisi server ditunjukkan penuh, Server sementara dicegah dari 

mengirimkan lebih banyak byte dari file video ke soket. Di sisi klien, 

aplikasi klien (media player) membaca byte dari buffer penerimaan 

TCP (melalui soket kliennya) dan menempatkan byte ke buffer 

aplikasi klien. Pada saat yang sama, aplikasi klien secara berkala 

mengambil frame video dari buffer aplikasi klien, mendekompresi 

frame, dan menampilkannya di layar pengguna. Perhatikan bahwa 

jika buffer aplikasi klien lebih besar dari file video, maka seluruh 

proses pemindahan bit dari penyimpanan server ke buffer aplikasi 

klien sama dengan unduhan file biasa melalui HTTP — klien hanya 

menarik video dari server secepat yang diizinkan TCP!

Gambar 9.2 Streaming Video yang Tersimpan melalui HTTP / TCP

Pertimbangkan sekarang apa yang terjadi ketika pengguna 

menjeda video selama proses streaming. Selama periode jeda, bit 

tidak dihapus dari buffer aplikasi klien, meskipun bit terus menghibur 

buffer dari server. Jika buffer aplikasi klien terbatas, akhirnya mungkin 

menjadi penuh, yang akan menyebabkan “tekanan balik” sepanjang 

perjalanan kembali ke server. Secara khusus, setelah bufferbecomes 

aplikasi klien penuh, bit tidak lagi dapat dihapus dari buffer menerima 

TCP klien, sehingga juga menjadi penuh. Setelah klien menerima 

buffer TCP menjadi penuh, bit tidak lagi dapat dihapus dari buffer 

server penyangga TCP, jadi itu juga menjadi penuh. Setelah TCP 

menjadi penuh, server tidak dapat mengirim bit lagi ke soket. 

• Analisis Streaming Video

Beberapa pemodelan sederhana akan memberikan lebih banyak 

wawasan tentang penundaan pemutaran awal dan pembekuan sebab  

penipisan aplikasi buffer. 

150

Gambar 9.3 Analisis Penyangga Sisi Klien untuk Streaming Video

• Analisis buffer sisi klien untuk streaming video

Pengakhiran Awal dan Pemosisian Ulang Video

(dalam bit) dari buffer aplikasi klien, dan biarkan Q menunjukkan 

jumlah bit yang harus buffered sebelum aplikasi klien mulai bermain. 

(tentu saja Q<B) membiarkan r menunjukkan tingkat konsumsi video 

tingkat di mana klien mengambil bit dari buffer aplikasi klien selama 

pemutaran. Jadi, misalnya, jika frame rate video yaitu  30 frame / 

detik, dan setiap frame (terkompresi) yaitu  100.000 bit, maka r=3 

Mbps.

C. Voice-over-IP

Suara percakapan waktu-nyata melalui Internet sering disebut sebagai 

telepon Internet, sebab , dari sudut pandang pengguna, ini mirip dengan 

layanan telepon tradisional. Ini juga biasa disebut Voice-over-IP (VoIP).

1. Keterbatasan Layanan IP Upaya Terbaik

Protokol lapisan jaringan Internet, IP, menyediakan layanan yang 

membuat upaya terbaik untuk memindahkan setiap datagram dari 

sumber ke tujuan secepat mungkin tetapi membuat nopromis apa pun 

tentang mendapatkan paket ke tujuan dalam beberapa waktu tunda 

atau tentang jumlah paket yang hilang.

 › Paket Hilang

Pertimbangkan salah satu segmen UDP yang dihasilkan oleh 

aplikasi VoIP. Segmen UDP diringkas dalam datagram IP. Saat 

151

datagram mengembara melalui jaringan, ia melewati buffer yang 

melalui komputer (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 tiba mungkin dibuang, tidak pernah sampai 

pada aplikasi penerima.

Kehilangan bisa dihilangkan dengan mengirim paket melalui 

TCP (yang menyediakan transfer data yang andal) daripada 

melalui UDP. Namun, mekanisme pengiriman ulang sering 

dianggap tidak dapat diterima untuk aplikasi audio real-time 

konversi seperti VoIP, sebab  mereka meningkatkan penundaan 

ujung ke ujung

 › Keterlambatan ujung ke ujung

yaitu  akumulasi dari transmisi, pemrosesan, dan keterlambatan 

antrian dalam router; keterlambatan propagasi dalam tautan; 

dan keterlambatan pemrosesan sistem akhir. Untuk aplikasi 

percakapan waktu-nyata, seperti VoIP, keterlambatan end-to-end 

yang lebih kecil dari 150 msec tidak dirasakan oleh pendengar 

manusia; keterlambatan antara 150 dan 400 msec dapat diterima 

tetapi tidak ideal; dan keterlambatan melebihi 400 msecs dapat 

secara serius menghambat interaktivitas dalam percakapan suara. 

 › Paket Jitter

Sebagai contoh, pertimbangkan dua paket berturut-turut dalam 

aplikasi VoIP. Pengirim mengirim paket kedua 20 msecs setelah 

mengirim paket pertama. Tetapi pada penerima, jarak antara 

paket-paket ini dapat menjadi lebih besar dari 20 msecs.

2. Menghapus Jitter pada Penerima untuk Audio

Untuk aplikasi VoIP, di mana paket-paket dihasilkan secara berkala, 

penerima harus berusaha untuk menyediakan playout potongan suara 

berkala di hadapan jitter jaringan acak. Ini biasanya dilakukan dengan 

menggabungkan dua mekanisme berikut:

 › Siapkan setiap chunk dengan cap waktu. Pengirim mencap 

setiap chunk dengan waktu di mana chunk dihasilkan.

 › Menunda pemutaran potongan pada penerima. Penundaan 

pemutaran potongan audio yang diterima harus cukup lama 

152

sehingga sebagian besar paket diterima sebelum waktu bermain 

yang dijadwalkan. 

Memperbaiki Keterlambatan Playout

Dengan strategi penundaan tetap, penerima mencoba untuk 

memainkan setiap chunk persis q msecs setelah chech dihasilkan. Jadi, 

jika sepotong cap waktu di pengirim pada waktu t, penerima memutar 

keluar pada waktu t+q dengan asumsi potongan telah tiba pada saat 

itu. Paket yang tiba setelah waktu pemutaran yang dijadwalkan 

dibuang dan dianggap hilang.

Gambar 9.4 Paket Hilang untuk Penundaan Main yang Tetap Berbeda

Seperti yang ditunjukkan oleh tangga paling kiri, pengirim 

menghasilkan paket secara berkala, katakanlah, setiap 20 msec. 

Paket pertama dalam dorongan pembicaraan ini diterima pada 

waktu r. Seperti yang ditunjukkan pada gambar, kedatangan paket-

paket berikutnya secara mencolok diberi jarak sebab  jitter jaringan. 

Mengikuti [Ramjee 1994], kita sekarang menjelaskan algoritma umum 

yang dapat digunakan penerima untuk menyesuaikan penundaan 

playout secara adaptif. Untuk tujuan ini, biarkan

3. Memulihkan dari Kehilangan Paket

Untuk menjaga kualitas audio yang dapat diterima di hadapan 

packetloss. Skema semacam itu disebut skema pemulihan kerugian. 

153

Di sini kita mendefinisikan kehilangan paket dalam arti luas: Paket 

hilang baik jika tidak pernah tiba di penerima atau jika tiba setelah 

waktu bermain yang dijadwalkan.

Forward Error Correction (FEC) / Teruskan Koreksi Kesalahan

Ide dasar FEC yaitu  menambahkan informasi yang berlebihan 

ke aliran paket asli. Untuk biaya yang secara umum meningkatkan 

laju transmisi, informasi yang berlebihan dapat digunakan untuk 

merekonstruksi pendekatan atau versi tepat dari beberapa paket yang 

hilang. Potongan yang redundan diperoleh dengan eksklusif ATAU 

potongan asli [Shacham 1990]. Dengan cara ini jika ada satu paket dari 

grup n+1 paket hilang, penerima dapat merekonstruksi paket yang 

hilang. Tetapi jika dua atau lebih paket dalam suatu kelompok hilang, 

penerima tidak dapat merekonstruksi paket yang hilang. Dengan 

menjaga n+1 ukuran kelompok, kecil, sebagian besar dari paket yang 

hilang dapat dipulihkan ketika kehilangan tidak berlebihan. Namun, 

semakin kecil ukuran grup, semakin besar peningkatan laju transmisi. 

Secara khusus, laju transmisi meningkat sebesar faktor 1 / n, sehingga, 

jika n=3 maka tingkat transmisi meningkat sebesar 33 persen. 

Gambar 9.5 Piggybacking Lower-Quality Redundant Information

 › Interleaving

Sebagai alternatif untuk transmisi redundan, aplikasi VoIP dapat 

mengirim audio yang disisipkan. Interleaving dapat mengurangi 

efek dari kehilangan paket. Jika, misalnya, panjang unit yaitu  5 

154

msecs dan chunk yaitu  20 msecs (yaitu, empat unitperpotong), 

maka chunk pertama dapat berisi unit 1, 5, 9, dan 13; potongan 

kedua dapat berisi units2, 6, 10, dan 14; dan seterusnya. Gambar 

9.6 menunjukkan bahwa hilangnya satu paket tunggal dari aliran 

interleaved menghasilkan beberapa celah kecil dalam aliran yang 

direkonstruksi, sebagai lawan dari celah besar tunggal yang akan 

terjadi dalam aliran tanpa interleaved.

 › Error Concealment / Penyembunyian Kesalahan

Skema penyembunyian kesalahan berusaha menghasilkan 

pengganti untuk paket yang hilang yang mirip dengan aslinya. 

Sebagaimana dibahas dalam [Perkins 1998], ini dimungkinkan 

sebab  audio sinyal, dan dalam pidato tertentu, menunjukkan 

sejumlah besar kemiripan jangka pendek. Dengan demikian, 

teknik ini bekerja untuk tingkat kerugian yang relatif kecil 

(kurang dari 15 persen), dan untuk paket kecil (4-40 msecs).

Gambar 9.6 Mengirim Audio yang disisipkan

4. Studi Kasus: VoIP dengan Skype

Skype yaitu  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-ke-telepon, layanan telepon-ke-

host, dan layanan konferensi video host-to-host multi-pihak. (Di sini, 

satu lagi host yaitu  perangkat IP yang terkoneksi Internet, termasuk 

PC, tablet, dan smartphone.) Skype diakuisisi oleh Microsoft di tahun 

2011.

155

Untuk kedua suara dan video, klien Skype memiliki banyak 

codec yang berbeda, yang mampu mengkodekan media atau berbagai 

tingkat dan kualitas. Misalnya, kecepatan video untuk Skype telah 

diukur hingga 30 kbps untuk sesi berkualitas rendah hingga hampir 1 

Mbps untuk sesi berkualitas tinggi [Zhang X 2012]. Biasanya, kualitas 

audio Skype lebih baik daripada “POTS” (Layanan Telepon Lama 

Biasa) berkualitas disediakan oleh sistem telepon kabel. (Skype codec 

biasanya sampel suara pada 16.000 sampel / detik atau lebih tinggi, 

yang menyediakan nada lebih kaya daripada POTS, yang sampelnya 

8.000 / detik.).

Secara default, Skype mengirim paket audio dan video melalui 

UDP. Namun, paket kontrol dikirim melalui TCP, dan paket media 

juga lebih dari TCP ketika firewall memblokir aliran UDP. Skype 

memakai  FEC untuk pemulihan kerugian 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].

Skype memakai  teknik P2P dalam sejumlah cara inovatif, 

dengan baik menggambarkan bagaimana P2P dapat digunakan dalam 

aplikasi yang melampaui distribusi konten dan berbagi file. 

Gambar 9.7 Skype Peer

156

D. Protocols for Real-Time Conversational Applications / 

Protokol untuk Aplikasi Percakapan Real-Time

Dengan standar yang sesuai untuk percakapan Real Time aplikasi, 

perusahaan independen menciptakan produk baru yang saling beroperasi 

satu sama lain. Pada bagian ini kita menguji RTP dan SIP untuk aplikasi 

percakapan waktu-nyata. Kedua standar menikmati penerapan luas dalam 

produk industri.

1. RTP

Sebagian besar aplikasi dapat memakai  

urutan angka dan cap waktu, akan lebih mudah untuk memiliki 

struktur paket standar yang mencakup bidang untuk data audio / 

video, nomor urutan, dan stempel waktu, serta bidang lain yang 

berpotensi bermanfaat. RTP, didefinisikan dalam RFC 3550, yaitu  

standar seperti itu. RTP dapat digunakan untuk mengangkut format 

umum seperti PCM, ACC, dan MP3 untuk suara dan MPEG dan H.263 

untuk video. Ini juga dapat digunakan untuk mengangkut format 

suara dan video hak milik. Hari ini, RTP menikmati implementasi 

luas di banyak produk dan prototipe penelitian. Ini juga melengkapi 

protokol interaktif penting real time lainnya, seperti SIP.

 › Dasar RTP

RTP biasanya berjalan di atas UDP. Sisi pengiriman merangkum 

potongan media dalam paket RTP, kemudian merangkum paket 

dalam segmen UDP, dan kemudian menyerahkan segmen 

tersebut ke IP. Sisi penerima mengekstrak paket RTP dari segmen 

UDP, lalu mengekstrak potongan media dari paket RTP, dan 

kemudian meneruskannya ke pemutar media untuk decoding 

dan rendering.

Aplikasi mengekstrak audio chunk dari paket RTP dan 

memakai  bidang header dari paket RTP untuk memecahkan 

kode dengan benar dan memutar audio chunk. Harus ditekankan 

bahwa RTP tidak menyediakan mekanisme untuk memastikan 

pengiriman data yang tepat waktu atau memberikan jaminan 

kualitas layanan lainnya (QoS); bahkan tidak menjamin 

pengiriman paket atau mencegah pengiriman paket yang tidak 

sesuai pesanan. Memang, enkapsulasi RTP hanya terlihat di 

157

sistem akhir. Rute tidak membedakan antara datagram IP yang 

membawa paket RTP dan datagram IP yang tidak.

RTP memungkinkan setiap sumber (misalnya, kamera 

atau mikrofon) untuk ditugaskan aliran paket RTP independen. 

Misalnya, untuk konferensi video antara dua peserta, empat 

aliran RTP dapat dibuka dua aliran untuk mentransmisikan audio 

(satu di setiap arah) dan dua aliran untuk mentransmisikan video 

(sekali lagi, satu di setiap arah). Namun, banyak teknik penyandian 

populer termasuk MPEG 1 dan MPEG 2 bundel audio dan video 

ke dalam satu aliran tunggal selama proses penyandian. Ketika 

audio dan video dibundel oleh encoder, maka hanya satu aliran 

RTP yang dihasilkan di setiap arah.

Gambar 9.8 RTP header fields

 › Bidang Header Paket RTP

Seperti yang ditunjukkan pada Gambar 9.8, empat bidang 

header paket RTP utama yaitu  tipe payload, sequencenumber, 

timestamp, dan bidang pengidentifikasi sumber. Bidang tipe 

payload dalam paket RTP yaitu  7 bit. Untuk aliran audio, bidang 

jenis muatan digunakan untuk menunjukkan jenis pengkodean 

audio (misalnya, PCM, modulasi delta adaptif, pengkodean 

prediksi linear) yang digunakan. Jika pengirim memutuskan 

untuk mengubah pengkodean di tengah-tengah asesi, pengirim 

dapat menginformasikan penerima perubahan melalui bidang 

jenis muatan ini. 

Untuk aliran video, jenis payload digunakan untuk 

menunjukkan jenis pengkodean video (misalnya, motionJPEG, 

MPEG 1, MPEG 2, H.261). Sekali lagi, pengirim dapat mengubah 

pengkodean video dengan cepat selama sesi berlangsung. Tabel 

9.3 mencantumkan beberapa jenis payload video yang saat 

ini didukung oleh RTP. Bidang-bidang penting lainnya yaitu  

sebagai berikut : 

1) Kolom nomor urut. Bidang nomor urut panjangnya 16 bit. 

Peningkatan urutan nomor oleh satu untuk setiap paket RTP 

yang dikirim, dan dapat digunakan oleh penerima untuk 

158

mendeteksi hilangnya paket dan untuk mengembalikan 

urutan paket. 

2) Bidang cap waktu. Bidang cap waktu panjangnya 32 bit. Ini 

mencerminkan pengambilan sampel byte pertama dalam 

paket data RTP. 

3) Synchronization source identifier (SSRC). Kolom SSRC 

yaitu  32 bit. Ini mengidentifikasi sumber aliran RTP. 

Biasanya, setiap aliran dalam sesi RTP memiliki SSRC 

yang berbeda. SSRC bukan alamat IP pengirim, melainkan 

nomor yang diberikan sumber secara acak ketika aliran 

baru dimulai. Probabilitas bahwa dua aliran mendapatkan 

SSRC yang sama sangat kecil. Jika ini terjadi, kedua sumber 

memilih nilai SSRC baru.

Tabel 9.2 Jenis Muatan Audio yang didukung oleh RTP

Nomor Jenis-

Muatan

Format Audio 

Tingkat 

Sampling

Nilai 

0 PCM μ-law 8 kHz 64 kbps

1 1016 8 kHz 4.8 kbps

3 GSM 8 kHz 13 kbps

7 LPC 8 kHz 2.4 kbps

9 G.722 16 kHz 46-64 kbps

14 Audio MPEG 90 kHz -

15 G.728 8 kHz 16 kbps

159

Tabel 9.3 Beberapa jenis payload video yang didukung oleh RTP

Nomor Jenis-Muatan Format Vidio

26 Motion JPEG (Gerakan JPEG/GIF)

31 H.264

32 Vidio MPEG 1

33 Vidio MPEG 2

2. SIP

Session Initiation Protocol (SIP), didefinisikan dalam [RFC 3261; 

RFC 5411], yaitu  protokol terbuka dan ringan yang melakukan hal 

berikut:

a. membuat panggilan antara penelepon dan callee melalui jaringan 

IP. Hal ini memungkinkan para peserta untuk menyetujui 

pengkodean media. Ini juga memungkinkan peserta untuk 

mengakhiri panggilan.

b. penelepon untuk menentukan alamat IP saat ini dari callee. 

Pengguna tidak memiliki satu alamat IP tetap sebab  mereka dapat 

diberi alamat secara dinamis (memakai  DHCP) dan sebab  

mereka mungkin memiliki beberapa perangkat IP, masing-masing 

dengan alamat IP yang berbeda.

c. manajemen panggilan, seperti menambahkan aliran media baru 

selama panggilan, mengubah pengodean selama panggilan, 

mengundang peserta baru selama panggilan, mentransfer 

panggilan, dan menahan panggilan.

 › Menyiapkan Panggilan ke Alamat IP yang Dikenal

Untuk memahami esensi SIP, yang terbaik yaitu  melihat 

contoh konkret. Dalam contoh ini, Alice di PC-nya dan dia ingin 

memanggil Bob, yang juga bekerja di PC-nya. PC Alice dan Bob 

sama-sama dilengkapi dengan perangkat lunak berbasis SIP untuk 

melakukan dan menerima panggilan telepon. Dalam contoh awal 

ini, kita berasumsi bahwa Alice mengetahui alamat IP PC Bob. 

Gambar 9.9 menggambarkan proses pembentukan panggilan SIP.

160

Gambar 9.9 Pembuatan Panggilan SIP Ketika Alice Mengetahui 

Alamat IP Bob

Pada Gambar 9.9, kita melihat bahwa sesi SIP dimulai ketika 

Alice mengirimi Bob pesan undangan, yang mencakup pesan 

permintaan HTTP. Pesan undangan ini dikirim melalui UDP 

ke port5060 yang terkenal untuk SIP. (Pesan SIP juga dapat 

dikirim melalui TCP.) Pesan undangan termasuk pengidentifikasi 

untuk Bob (bob@193.64.210.89), indikasi alamat IP Alice saat 

ini, indikasi bahwa Alicedesires ingin menerima audio, yang 

akan dikodekan dalam format AVP 0 (PCM disandikan μ-law) 

dienkapsulasi dalam RTP, dan indikasi bahwa ia ingin menerima 

paket RTP di port 38060. Setelah menerima pesan INVITE Alice, 

Bob mengirim pesan respons SIP, yang menyerupai pesan respons 

HTTP.

Pesan SIP respons ini juga dikirim ke port SIP 5060. Respons 

Bob termasuk 200 OK dan juga indikasi alamat IP-nya, penyandian 

yang diinginkan dan penerimaan paketisasi yang diinginkan, dan 

nomor portnya ke mana paket audio harus dikirim. Perhatikan 

bahwa dalam contoh ini Alice dan Bob akan memakai  

mekanisme pengkodean audio yang berbeda: Alice diminta untuk 

161

menyandikan heraudio dengan GSM sedangkan Bob diminta 

untuk menyandikan audionya dengan PCM μ-law. Setelah 

menerima respons Bob, Alice mengirimkan pesan pengakuan 

SIP kepada Bob. Setelah transaksi SIP ini, Bob dan Alicecan 

berbicara. (Untuk kenyamanan visual, Gambar 9.9 menunjukkan 

Alice berbicara setelah Bob, tetapi sebenarnya mereka tidak 

akan berbicara secara bersamaan.) Bob akan menyandikan dan 

mengemas audio sesuai permintaan dan mengirim paket audio 

ke nomor port 38060 di alamat IP 167.180.112.24. Alice juga 

akan menyandikan dan mengemas audio seperti yang diminta 

dan mengirim paket audio ke nomor port 48753 di alamat IP 

193.64.210.89. 

 › Alamat SIP

Ketika perangkat SIP Alice mengirim pesan undangan, pesan 

akan menyertakan alamat seperti email ini; infrastruktur SIP 

kemudian akan merutekan pesan ke perangkat IP yang sedang 

digunakan Bob (seperti yang akan kita bahas di bawah). Bentuk 

lain yang mungkin untuk alamat SIP dapat berupa nomor telepon 

lawas Bob atau hanya nama depan / tengah / belakang Bob 

(dengan asumsi itu unik). 

 › Pesan SIP

Berikut yaitu  pesan undangan SIP, bersama dengan beberapa 

baris tajuk umum. Mari kita lagi berasumsi bahwa Alice ingin 

memulai panggilan VoIP ke Bob, dan kali ini Alice hanya tahu 

alamat SIP Bob, bob @ domain.com, dan tidak tahu alamat 

IP perangkat yang sedang digunakan Bob. Pesan selanjutnya 

mungkin terlihat seperti ini:

Baris undangan menyertakan versi SIP, seperti halnya pesan 

permintaan HTTP. Setiap kali SIPmessage melewati perangkat 

SIP (termasuk perangkat yang berasal pesan), itu melampirkan 

162

header Via, yang menunjukkan alamat IP perangkat. (Kita akan 

segera melihat bahwa pesan undangan biasa melewati banyak 

perangkat SIP sebelum mencapai aplikasi SIP callee.).

 › Terjemahan Nama dan Lokasi Pengguna

Jadi sekarang mari kita anggap bahwa Alice hanya tahu alamat 

surel Bob, bob@domain.com, dan bahwa alamat yang sama ini 

digunakan untuk panggilan berbasis SIP. Dalam hal ini, Alice 

perlu mendapatkan alamat IP perangkat yang saat ini digunakan 

pengguna bob@domain.com. Untuk mengetahuinya, Alice 

membuat pesan undangan yang dimulai dengan undangan bob@

domain.com SIP / 2.0 dan mengirimkan pesan ini ke proxy SIP.

Setiap kali Bob beralih ke perangkat SIP baru, perangkat 

baru mengirim pesan register baru, yang menunjukkan alamat 

IP baru. Selain itu, jika Bob tetap berada di perangkat yang sama 

untuk periode waktu yang lama, perangkat akan mengirim pesan 

register penyegaran, yang menunjukkan bahwa alamat IP yang 

terakhir dikirim masih valid. (Dalam contoh di atas, refresh pesan 

yang perlu dikirim setiap 3600 detik untuk mempertahankan 

alamat di server registrar.) Perlu dicatat bahwa registrar analog 

dengan server nama otoritatif DNS: Server DNS menerjemahkan 

nama host tetap menjadi alamat IP tetap; pendaftar SIP 

menerjemahkan pengidentifikasi manusia tetap (misalnya, bob 

@ domain.com) ke alamat IP dinamis. Seringkali pendaftar SIP 

dan proksi SIP dijalankan di hosting yang sama.

Sebagai contoh, perhatikan Gambar 9.10, di mana jim@

umass.edu, saat ini bekerja pada 217.123.56.89, ingin memulai 

sesi Voice-over-IP (VoIP) dengan keith@upenn.edu, saat ini 

bekerja di197.87.54.21. Langkah-langkah berikut diambil

163

Gambar 9.10 Inisiasi Sesi, yang melibatkan Proksi dan Pendaftar Sip

(1) Jim mengirim pesan undangan ke proxy SIP umass. (2) 

Proxy melakukan pencarian DNS pada registrasi SSIP upenn.edu 

(tidak ditampilkan dalam diagram) dan kemudian meneruskan 

pesan ke server registrar. (3) sebab  keith@upenn.edu tidak lagi 

terdaftar di registrasi upenn, upenn registrar sendsa redirect 

response, menandakan bahwa ia harus mencoba keith@nyu.edu. 

(4) Proksi umass mengirim pesan undangan ke pendaftar SIP 

NYU. (5) Pendaftar NYU mengetahui alamat IP keith@upenn.

eduand meneruskan pesan undangan ke host 197.87.54.21, yang 

menjalankan klien SIP Keith. (6–8) Respons SIP dikirim kembali 

melalui pendaftar / proksi ke klien SIP di 217.123.56.89. (9) 

Penerbitan media langsung antara kedua klien. (Ada juga pesan 

pengakuan SIP, yang tidak ditampilkan.

E. Dukungan Jaringan untuk Multimedia

Jaminan Kualitas Layanan (QoS) Per-koneksi. Dengan jaminan QoS 

per-koneksi, setiap instansi aplikasi secara eksplisit mencadangkan 

bandwidth end-to-end dan sebab nya memiliki kinerja end-to-end yang 

164

terjamin. Jaminan keras berarti aplikasi akan menerima kualitas layanan 

yang diminta (QoS) dengan pasti. 

1. Dimensi Jaringan Usaha Terbaik

Pada dasarnya, kesulitan dalam mendukung aplikasi multimedia 

muncul dari persyaratan kinerja mereka yang ketat, delay paket end-

to-end yang rendah, delay jitter, dan loss dan fakta bahwa paket delay, 

delay jitter, dan kehilangan terjadi ketika jaringan menjadi padat. 

2. Menyediakan Berbagai Kelas Layanan

Mungkin peningkatan paling sederhana untuk layanan upaya terbaik 

satu ukuran untuk semua upaya di Internet saat ini yaitu  untuk 

membagi lalu lintas ke dalam kelas, dan menyediakan tingkat layanan 

yang berbeda untuk berbagai kelas lalu lintas ini. Sebagai contoh, 

ISP mungkin ingin memberikan kelas layanan yang lebih tinggi 

untuk trafik konferensi Voice-over-IP Voice-over-IP sensitif (dan 

membebankan biaya lebih untuk layanan ini!) Daripada lalu lintas 

elastis seperti e-mail atau HTTP. Alternatifnya, ISP mungkin hanya 

ingin memberikan kualitas layanan yang lebih tinggi kepada pelanggan 

yang bersedia membayar lebih untuk layanan yang ditingkatkan.

Perancang Internet awal jelas memiliki gagasan tentang berbagai 

kelas layanan dalam pikiran. Ingat bidang tipe layanan (ToS) di 

header IPv4 yang dibahas di Bab 4. IEN123 [ISI 1979] menjelaskan 

bidang Too juga hadir dalam leluhur datagram IPv4 sebagai berikut: 

“Jenis Layanan [bidang] memberikan indikasi parameter abstrak dari 

kualitas layanan yang diinginkan. Parameter ini dapat digunakan untuk 

memandu pemilihan parameter layanan aktual saat mengirimkan 

datagram melalui jaringan tertentu. 

Gambar 9.11 memperlihatkan skenario jaringan sederhana di 

mana dua aliran paket aplikasi berasal dari HostsH1 dan H2 pada 

satu LAN dan diperuntukkan bagi Hosts H3 dan H4 pada LAN lain. 

Perute pada duaLAN dihubungkan oleh tautan 1,5 Mbps. Mari kita 

asumsikan kecepatan LAN secara signifikan lebih tinggi dari 1.5Mbps, 

dan fokus pada antrian output router R1; di sinilah penundaan paket 

dan kehilangan paket akan terjadi jika laju pengiriman agregat H1 dan 

H2 melebihi 1,5 Mbps. Mari kita anggap lebih lanjut bahwa aplikasi 1 

Mbpsaudio (misalnya, panggilan audio berkualitas CD) berbagi 1,5 

165

Mbps menghubungkan antara R1 dan R2 dengan aplikasi penelusuran 

Web HTTP yang mengunduh Halaman Web dari H2 ke H4. 

Gambar 9.11 Aplikasi audio dan HTTP yang bersaing

Di Internet upaya terbaik, paket audio dan HTTP dicampur dalam 

antrian output di R1 dan (biasanya) ditransmisikan dalam urutan 

pertama-masuk-pertama-keluar (FIFO). Dalam skenario ini, ledakan 

paket dari Web server berpotensi mengisi antrian, menyebabkan 

paket audio IP tertunda berlebihan atau kehilangan buffer overeto di 

R1. Bagaimana kita memecahkan masalah potensial ini? Mengingat 

bahwa aplikasi penjelajahan Web HTTP tidak memiliki batasan 

waktu, intuisi kita mungkin untuk memberikan prioritas yang ketat 

pada paket audio di R1. Di bawah disiplin penjadwalan prioritas yang 

ketat, paket audio dalam buffer output R1 akan selalu ditransmisikan 

sebelum paket HTTP apa pun di buffer output R1. Tautan dari R1 ke 

R2 akan terlihat seperti tautan khusus 1,5 Mbps ke lalu lintas audio, 

dengan lalu lintas HTTP memakai  tautan R1-ke-R2 saja ketika 

tidak ada lalu lintas audio yang antri. Agar R1 membedakan antara 

antrian paket audio dan HTTP, setiap paket harus ditandai sebagai 

milik salah satu dari dua kelas lalu lintas ini. Ini yaitu  tujuan awal 

bidang tipe-layanan (ToS) di IPv4. Sejelas ini tampaknya, ini yaitu  

wawasan pertama kita tentang mekanisme yang diperlukan untuk 

menyediakan beberapa kelas lalu lintas

166

3. Per-Connection Quality-of-Service (QoS) 

Pada bagian sebelumnya, kita telah melihat bahwa penandaan dan 

pemolisian paket, isolasi lalu lintas, dan penjadwalan tautan-tingkat 

dapat memberikan satu kelas layanan dengan kinerja yang lebih 

baik daripada yang lain. Di bawah disiplin penjadwalan sertifikasi, 

seperti penjadwalan prioritas, kelas lalu lintas yang lebih rendah 

pada dasarnya “tidak terlihat” untuk kelas lalu lintas dengan prioritas 

tertinggi.

Mari kita kembali ke skenario kita dari Bagian 9.5.2 dan 

pertimbangkan dua aplikasi audio 1 Mbps mentransmisikan paket 

mereka melalui tautan 1,5 Mbps, seperti yang ditunjukkan pada 

Gambar 9.11. Kecepatan data gabungan dari dua aliran (2 Mbps) 

melebihi kapasitas tautan. Bahkan dengan klasifikasi dan penandaan, 

isolasi aliran, dan pembagian bandwidth yang tidak digunakan (yang 

tidak ada), ini jelas merupakan proposisi yang hilang.

Gambar 9.12 Dua aplikasi audio yang bersaing kelebihan tautan R1-ke-R2

waktu yang sama. Jika kedua aplikasi berbagi bandwidth secara 

sama, setiap aplikasi akan kehilangan 25 persen dari paket yang 

dikirimkan. Ini yaitu  QoS yang sangat rendah sehingga kedua 

aplikasi audio sama sekali tidak dapat digunakan; tidak perlu bahkan 

mengirim paket audio apa pun di tempat pertama.

Contoh motivasi kita pada Gambar 9.11 menggaris bawahi 

perlunya beberapa mekanisme jaringan baru dan protokol jika 

panggilan (aliran ujung ke ujung) harus dijamin dengan kualitas 

layanan yang diberikan begitu dimulai.