You are on page 1of 124

PROYEK AKHIR

RANCANG BANGUN RTP PACKET-CHUNK DE-ENCAPSULATOR


DATA AV STREAM FORMAT RTP SEBAGAI TERMINAL ACCESS
MULTI-SOURCE STREAMING SERVER

AHMAD BUDI SETIYAWAN


NRP. 7206.040.045

Dosen Pembimbing:
A. Subhan KH, ST
NIP. 19770120 200801 1010

JURUSAN TEKNIK TELEKOMUNIKASI


POLITEKNIK ELEKTRONIKA NEGERI SURABAYA
i
INSTITUT TEKNOLOGI SEPULUH NOPEMBER
SURABAYA
2010
PROYEK AKHIR

RANCANG BANGUN RTP PACKET-CHUNK


DE-ENCAPSULATOR DATA AV STREAM FORMAT RTP
SEBAGAI TERMINAL ACCESS MULTI-SOURCE
STREAMING SERVER

AHMAD BUDI SETIYAWAN


NRP. 7206.040.045

Dosen Pembimbing:
A. Subhan KH, ST
NIP. 19770120 200801 1010

JURUSAN TEKNIK TELEKOMUNIKASI


POLITEKNIK ELEKTRONIKA NEGERI SURABAYA
INSTITUT TEKNOLOGI SEPULUH NOPEMBER
SURABAYA
2010

i
RANCANG BANGUN RTP PACKET-CHUNK
DE-ENCAPSULATOR DATA AV STREAM FORMAT RTP SEBAGAI
TERMINAL ACCESS MULTI-SOURCE STREAMING SERVER

Oleh :
AHMAD BUDI SETIYAWAN
NRP.7206.040.045

Proyek Akhir Ini Diajukan Sebagai Salah Satu Syarat Untuk


Memperoleh Gelar Sarjana Sains Terapan (S.ST)
di
Politeknik Elektronika Negeri Surabaya
Institut Teknologi Sepuluh Nopember Surabaya

Disetujui oleh :
Tim Penguji Proyek Akhir : Dosen Pembimbing :

ENGESAHAN
1. Tri Budi Santoso, ST, MT 1. A Subhan KH, ST
NIP. 19700105 199502 1001 NIP. 19770120 200801 1010

2. Reni Soelistijorini, B.Eng, MT


NIP. 19710428 199903 2002

3. Moh. Agus Zainudin, ST, MT


NIP. 19780812 200801 1015

Mengetahui,
Ketua Jurusan Teknik Telekomunikasi

Arifin, ST. MT
NIP. 19600503 198803 1004
ABSTRAK
ii
ABSTRAK

Teknologi internet berbasis IP berkembang sangat pesat dan telah


menjadi standar untuk sistem komunikasi data secara global. IP sangat
baik dalam skalabilitas sehingga membuat teknologi internet cukup
murah dan bisa menangani kebutuhan internet yang semakin meningkat.
Namun, masalah mungkin terjadi ketika streaming server yang ada saat
ini hanya dapat mengirimkan paket RTP dari satu sumber video saja.
Sehingga streaming server yang sudah ada saat ini belum bisa dijadikan
dasar pengembangan IPTV.
Multi-Source Streaming Server (MSS) merupakan konsep sistem
streaming video yang memiliki beberapa sumber. Konsep Multi-Source
Streaming Server diharapkan bisa sebagai acuan untuk mengembangkan
IPTV.

Kata kunci : Streaming server, Multi-Source Streaming Server, IPTV

iii
ABSTRACT

IP-based internet technology develops very rapidly and has become


the standard for global data communication systems. IP that is very good
in making scalability of internet technology is cheap enough and can
handle the growing internet needs. However, problems may occur when
the streaming server is currently only able to send RTP packets from one
video source only. So the existing streaming server currently can’t be the
foundation to develop IPTV.
Multi_source Streaming Server (MSS) is the concept of video
streaming that has several sources. The concept of Multmimedia-Source
Streaming Server is expected to be a reference to develop IPTV.

Key Word : Streaming server, Multi-Source Streaming Server, IPTV

iv
KATA PENGANTAR
‫الحمد ﷲ رب العا لمين‬

Puji syukur kehadirat Allah SWT yang telah melimpahkan


Rahmat dan Hidayah-Nya kepada kami, sehingga kami dapat
menyelesaikan penyusunan dan pembutan laporan Proyek Akhir ini
yang mengambil judul :

RANCANG BANGUN RTP PACKET-CHUNK


DE-ENCAPSULATOR DATA AV STREAM FORMAT RTP
SEBAGAI TERMINAL ACCESS MULTI-SOURCE STREAMING
SERVER

Proyek Akhir yang kami laksanakan ini merupakan salah satu


kegiatan yang berkaitan dengan kurikulum perkuliahan yang harus
dipenuhi sebagai persyaratan menyelesaikan studi D4 di Politeknik
Elektronika Negeri Surabaya ITS.
Dalam menyelesaikan Proyek Akhir ini kami melaksanakan
berdasarkan toeri-teori yang telah kami peroleh dalam perkulihan,
membaca literatur, dan bimbingan dari dosen pembimbing serta pihak
lain yang telah banyak memberikan semangat dan bantuannya.
Penyusun menyadari sepenuhnya bahwa masih banyak
kekurangan yang dimiliki sehingga menyebabkan kurang sempurnanya
laporan Proyek Akhir ini. Untuk itulah penyusun minta maaf dan
mengharapkan saran dan kritik yang membangun demi kesempurnaan
laporan Proyek Akhir ini. Semoga buku Laporan yang kami tulis ini
dapat memberikan manfaat terhadap perkembangan ilmu pengetahuan
bagi semua pihak pada umumnya dan bagi kami sendiri pada khususnya
Surabaya, July 2010

Penyusun

v
UCAPAN TERIMAKASIH

Alhamdulillah, atas segala limpahan rahmat, taufiq, hidayah


dan inayah-Nya sehingga proyek akhir ini dapat kami selesaikan sesuai
dengan jadwal yang ditentukan. Kami sadar bahwa terwujudnya proyek
akhir ini tak lepas dari bantuan, bimbingan, dan dukungan dari berbagai
pihak. Oleh karena itu dengan segala kerendahan hati kami sampaikan
terima kasih kepada :
1. Allah Subhanhu Wata’alla atas beribu nikmat, petunjuk,
pertolongan, bimbingan, serta perlindungan yang telah diberikan
kepada saya.
2. Bapak, ibu dan keluarga saya yang dengan do’a kasih sayang dan
kesabaran selalu mendukung saya dalam menempuh pendidikan di
PENS ITS. Bantuan moral serta spiritual yang mereka berikan
sangat membantu saya dalam menyelesaikan proyek akhir ini,
semoga apa yang selama ini saya lakukan dapat membuat saya
menjadi orang yang lebih baik dan tidak mengecewakan. Amin.
3. Bapak Ir. Dadet Pramadihanto, M.Eng. PhD selaku Direktur PENS
ITS.
4. Bapak Arifin ST, MT. selaku Kepala Jurusan Teknik
Telekomunikasi.
5. Bapak A Subhan KH, ST sebagai dosen pembimbing. Terima kasih
atas bimbingan, petunjuk dan bantuannya yang dengan penuh
kesabarannya sehingga saya dapat menyelesaikan proyek akhir ini.
6. Seluruh Bapak dan Ibu dosen yang telah membimbing, mengajar
dan memberikan ilmunya kepada kami selama belajar di kampus.
7. Buat teman-teman sekelompok perancangan sistem, terima kasih
atas bantuannya dan menjadi teman dalam suka meupun duka.
8. Teman-teman seperjuangan D4T B yang kompak, Thanx banget dan
terima kasih atas atensi, bantuan dan ilmunya.
“FRIENDS FOREVER”.

vi
9. Dan seluruh pihak yang namanya tidak mungkin saya sebutkan satu
per satu di sini. Terima kasih telah membantu saya dalam
menyelesaikan studi dan proyek akhir ini.

Dengan segala asa saya pribadi mengucapkan Terima kasih dan


Maaf yang sebesar-besarnya.

vii
DAFTAR ISI
HALAMAN JUDUL ....................................................................... i
LEMBAR PENGESAHAN............................................................. ii
ABSTRAK ....................................................................................... iii
ABSTRACT ..................................................................................... iv
KATA PENGANTAR ..................................................................... v
UCAPAN TERIMA KASIH ........................................................... vi
DAFTAR ISI .................................................................................... viii
DAFTAR GAMBAR ....................................................................... xi
DAFTAR TABEL............................................................................ xv
BAB I PENDAHULUAN ................................................................ 1
1.1 Latar Belakang ................................................................... 1
1.2 Rumusan Masalah .............................................................. 2
1.3 Batasan Masalah................................................................. 2
1.4 Tujuan ................................................................................ 2
1.5 Metodologi ......................................................................... 2
1.5.1 Studi Literatur .......................................................... 2
1.5.2 Observasi .................................................................. 2
1.5.3 Mendisain dan Merancang Sistem ........................... 3
1.5.4 Implementasi De-enkapsulasi pada MSS ................. 3
1.5.5 Pengujian .................................................................. 5
1.6 Sistematika Pembahasan .................................................... 5
BAB II TEORI PENUNJANG ....................................................... 7
2.1 Model Referensi OSI .......................................................... 7
2.2 Aplikasi Multimedia Networking ....................................... 8

viii
2.2.1 Contoh Aplikasi Multimedia Networking ................ 8
2.3 Konsep Streaming .............................................................. 10
2.3.1 Proses Transmisi pada Proses Video Streaming ...... 11
2.3.2 Pengaksesan Data Streaming dari Web Server ........ 12
2.3.3 Real Time Streaming Protokol (RTSP) .................... 13
2.3.4 QoS Audio/Video Streaming ................................... 15
2.3.5 Menghilangkan Delay Jitter ..................................... 18
2.3.6 Memperbaiki Packet Loss ........................................ 20
2.4 Protokol Streaming ............................................................. 20
2.4.1 RTP (Real Time Protocol)........................................ 21
2.4.2 RTCP (Real Time Control Protocol) ........................ 23
2.5 De-enkapsulasi ................................................................... 24
2.6 Pemrograman Socket .......................................................... 25
2.6.1 Jenis-jenis Socket ..................................................... 27
2.7 ORTP ................................................................................. 28
2.8 Demultiplxing .................................................................... 43
BAB III PERANCANGAN SISTEM ............................................. 45
3.1 Deskripsi Umum Sistem..................................................... 45
3.1.1 Tahap Perencanaan Flowchart ................................. 45
3.2 Perencanaan Perangkat Pendukung .................................... 47
3.2.1 Perancangan Perangkat Keras (hardware) ................ 47
3.2.2 Perancangan Perangkat Lunak (software) ................ 47
3.3 Implementasi Sistem .......................................................... 47
3.3.1 Instalasi Perangkat Keras (Hardware) ...................... 48
3.3.2 Instalasi Perangkat Lunak (Software) ...................... 48

ix
3.3.2.1 Instalasi oRTP-0.16.3 ................................... 48
3.3.2.2 Instalasi dan Konfigurasi Wireshark ............ 51
3.3.2.3 Kompile dan Jalankan oRTP 0.16.3 ............ 53
3.4 Tempat dan Waktu Pelaksanaan......................................... 53
3.5 Metode Pengukuran Parameter QoS .................................. 54
BAB IV IMPLEMENTASI DAN PENGUJIAN ........................... 55
4.1 Pengujian Demultiplexing Pengiriman packet RTP ........... 55
4.2 Analisa MTU dan Penambahan RTP Header ..................... 58
4.3 Pengukuran Time Eksekusi Demultiplexer ........................ 64
4.4 Pengukuran QoS Audio/Video Streaming.......................... 67
4.4.1 Packet Loss .............................................................. 68
4.4.2 Delay ........................................................................ 71
4.4.3 Jitter.......................................................................... 81
4.4.3 Throughput ............................................................... 84
BAB V PENUTUP ........................................................................... 89
5.1 Kesimpulan ........................................................................ 89
5.1 Saran................................................................................... 90
DAFTAR PUSTAKA ...................................................................... 91
LAMPIRAN ..................................................................................... 93

x
DAFTAR GAMBAR

Gambar 1.1 Blok diagram sistem ...................................................... 3


Gambar 1.2 Blok diagram de-enkapsulator ....................................... 4
Gambar 2.1 Komponen sistem penyusun streaming ......................... 10
Gambar 2.2 Sistem transmisi unicast ................................................ 11
Gambar 2.3 Sistem transmisi multicast ............................................. 12
Gambar 2.4 Proses pengiriman file audio/video dari web server
ke media player ............................................................ 13
Gambar 2.5 Interaksi antara client dan server menggunakan
protokol RTSP .............................................................. 15
Gambar 2.6 Proses terjadinya delay jitter ......................................... 18
Gambar 2.7 Packet delivery, time-varying delay (jitter),
and playout delay .......................................................... 19
Gambar 2.8 Delay per paket dan efek playout delay........................ 19
Gambar 2.9 RTP OSI model ............................................................ 21
Gambar 2.10 RTP header .................................................................. 22
Gambar 2.11 Paket delivery RTP dan RTCP .................................... 24
Gambar 2.12 Blok diagram RTP de-encapsulation ........................... 25
Gambar 2.13 Ilustrasi interface socket .............................................. 26
Gambar 2.14 Classifier paket ............................................................ 44
Gambar 2.15 Demultiplexer .............................................................. 44
Gambar 3.1 Blok diagram de-encapsulator ....................................... 45
Gambar 3.2 Flowchart sistem............................................................ 46
Gambar 3.3 Desain sistem................................................................. 48

xi
Gambar 3.4 Konfigurasi oRTP 0.16.3 ............................................... 49
Gambar 3.5 Kompile paket oRTP 0.16.3 .......................................... 49
Gambar 3.6 Menjalankan contoh program oRTP 0.16.3 ................... 50
Gambar 3.7 Install program dan file pendukung oRTP 0.16.3 .......... 51
Gambar 3.8 Wireshark ...................................................................... 51
Gambar 3.9 Menu capture interface .................................................. 52
Gambar 3.10 Analisa protokol streaming menggunakan wireshark .. 52
Gambar 3.11 Hasil packet capture oleh wireshark ............................ 53
Gambar 4.1 Capture paket pertama yang diterima demultiplexer ..... 55
Gambar 4.2 Capture paket pertama yang dikirim demultiplexer ...... 55
Gambar 4.3 Capture paket kedua yang diterima demultiplexer ........ 56
Gambar 4.4 Capture paket kedua yang dikirim demultiplexer .......... 56
Gambar 4.5 Capture paket ketiga yang diterima demultiplexer ........ 56
Gambar 4.6 Capture paket ketiga yang dikirim demultiplexer.......... 57
Gambar 4.7 Capture paket keempat yang diterima demultiplexer .... 57
Gambar 4.8 Capture paket keempat yang dikirim demultiplexer ...... 57
Gambar 4.9 Video dengan ukuran paket kirim 172 bytes ................. 59
Gambar 4.10 Video dengan ukuran paket kirim 332 bytes ............... 59
Gambar 4.11 Video dengan ukuran paket kirim 492 bytes ............... 60
Gambar 4.12 Video dengan ukuran paket kirim 652 bytes ............... 60
Gambar 4.13 Video dengan ukuran paket kirim 812 bytes ............... 61
Gambar 4.14 Video dengan ukuran paket kirim 972 bytes ............... 61
Gambar 4.15 Video dengan ukuran paket kirim 1132 bytes ............. 62
Gambar 4.16 Video dengan ukuran paket kirim 1292 bytes ............. 62
Gambar 4.17 Video dengan ukuran paket kirim 1452 bytes ............. 63

xii
Gambar 4.18 Video dengan ukuran paket kirim 1500 bytes ............. 63
Gambar 4.19 Video dengan ukuran paket kirim 1501 bytes ............. 64
Gambar 4.20 Grafik nilai time eksekusi pada demultiplexer ............ 67
Gambar 4.21 Topologi sesi komunikasi peer to peer ........................ 67
Gambar 4.22 Topologi sesi komunikasi student PENS ..................... 68
Gambar 4.23 Grafik nilai packet loss pada demultiplexer untuk
komunikasi peer to peer ............................................... 69
Gambar 4.24 Grafik nilai packet loss pada demultiplexer untuk
komunikasi student PENS ........................................... 70
Gambar 4.25 Grafik nilai delay paket RTP menuju port 5000
untuk komunikasi peer to peer ..................................... 72
Gambar 4.26 Grafik nilai delay paket RTP menuju port 5001
untuk komunikasi peer to peer ..................................... 73
Gambar 4.27 Grafik nilai delay paket RTP menuju port 5002
untuk komunikasi peer to peer ..................................... 74
Gambar 4.28 Grafik nilai delay paket RTP menuju port 5003
untuk komunikasi peer to peer ..................................... 75
Gambar 4.29 Grafik nilai delay paket RTP menuju port 5000
untuk komunikasi jaringan student PENS ................... 78
Gambar 4.30 Grafik nilai delay paket RTP menuju port 5001
untuk komunikasi jaringan student PENS ................... 79
Gambar 4.31 Grafik nilai delay paket RTP menuju port 5002
untuk komunikasi jaringan student PENS ................... 80
Gambar 4.32 Grafik nilai delay paket RTP menuju port 5003
untuk komunikasi jaringan student PENS ................... 81

xiii
Gambar 4.33 Grafik nilai jitter pada demultiplexer untuk
komunikasi peer to peer ............................................... 82
Gambar 4.34 Grafik nilai jitter pada demultiplexer untuk
komunikasi jaringan student PENS ............................. 84
Gambar 4.35 Grafik nilai throughput pada demultiplexer untuk
komunikasi peer to peer ............................................... 85
Gambar 4.36 Grafik nilai throughput pada demultiplexer untuk
komunikasi jaringan student PENS ............................. 87

xiv
DAFTAR TABEL

Tabel 2.1 Model referensi OSI .......................................................... 7


Tabel 2.2 Kategori packet loss .......................................................... 16
Tabel 2.3 Kategori besar delay .......................................................... 17
Tabel 2.4 Kategori peak jitter ............................................................ 18
Tabel 4.1 Pengaruh ukuran data, RTP header, MTU terhadap
kondisi video ..................................................................... 58
Tabel 4.2 Time eksekusi pada demultiplexer .................................... 64
Tabel 4.3 Packet loss pada demultiplexer untuk sesi komunikasi
peer to peer ........................................................................ 68
Tabel 4.4 Packet loss pada demultiplexer untuk sesi komunikasi
jaringan student PENS ...................................................... 70
Tabel 4.5 Delay paket RTP menuju port 5000 untuk sesi komunikasi
peer to peer ........................................................................ 71
Tabel 4.6 Delay paket RTP menuju port 5001 untuk sesi komunikasi
peer to peer ........................................................................ 72
Tabel 4.7 Delay paket RTP menuju port 5002 untuk sesi komunikasi
peer to peer ........................................................................ 73
Tabel 4.8 Delay paket RTP menuju port 5003 untuk sesi komunikasi
peer to peer ........................................................................ 74
Tabel 4.9 Delay paket RTP menuju port 5000 untuk sesi komunikasi
jaringan student PENS ...................................................... 77
Tabel 4.10 Delay paket RTP menuju port 5001 untuk sesi komunikasi
jaringan student PENS ...................................................... 78

xv
Tabel 4.11 Delay paket RTP menuju port 5002 untuk sesi komunikasi
jaringan student PENS ...................................................... 79
Tabel 4.12 Delay paket RTP menuju port 5003 untuk sesi komunikasi
jaringan student PENS ...................................................... 80
Tabel 4.13 Perbandingan jitter pada masing-masing port untuk
komunikasi peer to peer .................................................... 82
Tabel 4.14 Perbandingan jitter pada masing-masing port untuk
komunikasi jaringan student PENS ................................... 83
Tabel 4.15 Perbandingan throughput pada masing-masing port untuk
komunikasi peer to peer .................................................... 84
Tabel 4.16 Perbandingan jitter pada masing-masing port untuk
komunikasi jaringan student PENS ................................... 86

xvi
BAB I
PENDAHULUAN

Pada bab ini berisi mengenai materi yang memberikan


penggambaran secara umum hal – hal yang berhubungan dengan
penulisan tentang proyek akhir, antara lain :
1. Latar Belakang.
2. Tujuan.
3. Batasan masalah.
4. Metodologi.
5. Sistematika pembahasan.

1.1 Latar Belakang


Sekarang ini dapat dikatakan bahwa seluruh mata rantai
broadcasting mulai dari proses produksi hingga ke distribusi televisi
telah dilakukan secara digital, namun mata rantai ke end-user umumnya
masih dilakukan secara analog. DVB (Digital Video Broadcast) adalah
salah satu sistem yang digunakan untuk mentransmisikan siaran TV
digital hingga ke end-user.
Sekarang sudah ada berbagai macam streaming server yang
dibangun untuk mentransmisikan stream RTP. Streaming server
mengirimkan data secara real time dan bekerja menggunakan protokol
RTP. Namun dibalik keunggulan streaming server yang sudah ada,
kebanyakan hanya bisa mentransmisikan data dari satu source saja. Dan
tidak tertutup kemungkinan bahwa streaming video bisa dikembangkan,
sehingga memiliki lebih dari satu source. Konsep sistem streaming
server yang memiliki banyak source ini disebut Multi-Source Streaming
Server (MSS). Konsep MSS ini diharapkan bisa sebagai acuan untuk
mengembangkan IPTV.
Maka pada tugas akhir ini dibuatlah rancang bangun RTP packet-
chunk de-encapsulator data AV stream format RTP sebagai terminal
access multi-source streaming server. Disini kita mengimplementasikan
mekanisme streaming P2P multi-source. Hal yang menarik dari proyek
akhir ini adalah bagaimana de-encapsulator dapat mengidentifikasi
informasi header dan menata ulang kembali data video yang
ditransmisikan oleh multiplexer pada waktu yang sama (real time).
Kemudian mengirimkan ke displayer dengan kondisi sudah tertata dan
siap di olah. Hasil dari penelitian ini diharapkan dapat bermanfaat bagi
masyarakat yang ingin mengembangkan IPTV.


 
2

1.2 Rumusan Masalah


Permasalahan yang akan diselesaikan pada proyek akhir ini adalah:
1. Bagaimana melakukan de-encapsulator packet-chunk multi-
source video streaming?
2. Bagaimana identifikasi informasi header packet-chunk yang
telah diberikan oleh multiplexer?

1.3 Batasan Masalah


Batasan masalah dalam proyek akhir ini yaitu :
1. De-encapsulator packet-chunk multi-source video streaming
yang digunakan pada transmisi data video.
2. Identifikasi informasi Header pada packet-chunk multi-
source video streaming yang digunakan pada transmisi data
video.

1.4 Tujuan
Penelitian pada proyek akhir ini bertujuan sebagai berikut :
a. Merancang dan mengimplementasikan RTP packet-chunk de-
encapsulator data AV stream format RTP sebagai terminal
access multi-source video streaming.
b. Mengimplementasikan multi-source video dalam arsitektur IPTV
peer-to-peer (P2P).

1.5 Metodologi
Untuk meyelesaikan desain dan perancangan ini, maka dilakukan
langkah-langkah yang meliputi : mendesain dan merancang sistem,
mendesain demultiplexser dan de-encapsulasi, Implementasi
demultiplexer dan de-encapsulator pada multi- source video streaming,
analisa packet loss, delay jitter, end-to-end delay dan kesimpulan.
Rincian tahapan yang akan ditempuh adalah sebagai berikut

1.5.1 Studi Literatur


Sebelum sistem didesain dan dirancang akan dilakukan studi
pustaka atau literatur terlebih dahulu untuk memahami konsep-konsep
sistem yang harus dipelajari agar dalam perancangan sistem tidak
mengalami kendala yang berarti.

1.5.2 Observasi
Sambil melakukan studi pustaka atau literatur akan dilakukan
3

observasi untuk menguji coba konsep-konsep sistem yang sudah


dipelajari agar dapat dilakukan sebuah pemodelan terhadap sistem yang
akan dirancang.

1.5.3 Mendesain dan Merancang Sistem


Untuk mendesain dan merancang sistem arsitektur multi-source
video streaming, diambil empat data video oleh multiplexer. Dari
keempat video tersebut, masing-masing diambil data frame videonya.
Keempat frame video tersebut kemudian di-multiplexing, proses ini
dilakukan secara kontinyu untuk frame selanjutnya. Data video
kemudian dienkapsulasi menjadi paket – paket RTP yang siap dikirim.
Paket RTP kemudian dikirimkan pada satu port. Pada sisi terminal
access, paket RTP diterima oleh demultiplexer yang sekaligus bertindak
sebagai de-encapsulator. Setelah berhasil dipisah, data dikirimkan
kembali ke displayer dengan port yang berbeda-beda.

Sistem yang akan dirancang secara umum adalah sesuai Gambar 1.1
berikut : 

 
Gambar 1.1. Blok diagram sistem

1.5.4 Implementasi De-enkapsulasi pada MSS.


De-encapsulasi, terjadi saat data diterima oleh client tujuan Data
mengalir ke atas dari layer yang lebih rendah ke layer yang lebih tinggi
dari TCP/IP protokol. Setiap layer membuka header yang cocok dan
menggunakan informasi yang dikandungnya untuk disampaikan ke
layer di atasnya sampai pada layer tertinggi atau layer aplikasi.
4

1. Pada tujuan, bit stream kemudian diubah menjadi frame dan


melepas Ethernet Frame Header.
2. IP-header kemudian dilepas dan dikirim ke layer-3 sebagai paket
3. Paket selanjutnya melepas UDP Header dan mengirim data tersebut
ke layer-4 sebagai segment
4. Segment kemudian melepas layer-4 header (melepas RTP Header)
dan memberikan data ke layer -5,6,7 yang akhirnya diterima oleh
user sebagai data.
5. Proses pelepasan header dari layer ke layer disebut sebagai de-
encapsulasi.

Gambar 1.2 adalah gambaran mengenai bagian de-encapsulator yang


akan dirancang:

C 3.3
C 3.2
C 3.1

C 2.3
C 2.2
C 2.1

C 1.3
C 1.2
C 1.1
C 4.3
C 4.2
C 4.1

 
Gambar 1.2. Blok diagram de-enkapsulator

1.5.5 Pengujian
Pada tahap ini akan menganalisa hal-hal berikut ini :
5

1. Sistem yang telah dibuat akan dilakukan pengetesan koneksi dan


menganalisa parameter – parameter QoS packet-chunk RTP untuk
mendukung kinerja yang diinginkan.
2. Time Eksekusi
Time eksekusi adalah waktu yang dibutuhkan untuk pemrosesan
paket data, dari de-encapsulator menerima data sampai selesai di
de-enkapsulasi dan siap untuk dikirimkan ke displayer.

1.6 Sistematika Pembahasan


Buku laporan proyek akhir ini tersusun atas beberapa bab
pembahasan. Sistematika pembahasan tersebut adalah sebagai berikut:

¾ Bab 1 Pendahuluan
Menguraikan latar belakang, rumusan masalah, batasan masalah,
tujuan, metodologi dan sistematika pembahasan.
¾ Bab 2 Teori Penunjang
Berisikan dasar teori untuk menunjang penyelesaian masalah dan
dijelaskan landasan teori dari poin – poin penting yang digunakan
dalam proyek akhir ini.
¾ Bab 3 Perancangan Sistem
Membahas tentang proses perencanaan sistem secara keseluruhan
dan konfigurasi setiap perangkat yang digunakan baik server
maupun client. Serta metode pengumpulan data dan analisa.
¾ Bab 4 Implementasi, Hasil dan Pembahasan
Memuat implementasi sistem, hasil pengujian dan analisa terhadap
hasil yang didapat sesuai dengan tujuan yang ditetapkan.
¾ Bab 5 Penutup
Berisi tentang kesimpulan dari pembahasan bab – bab sebelumnya
dan saran – saran serta beberapa kemungkinan pengembangan
proyek akhir ini.
6

====Halaman ini sengaja dikosongkan====


BAB II
TEORI PENUNJANG
2.1 Model Referensi OSI
OSI adalah referensi komunikasi dari Open System
Interconnection. OSI model digunakan sebagai titik referensi untuk
membahas spesifikasi protokol. OSI model terdiri dari 7 layer. Dimana
bagian atas dari layernya (layer 7,6,dan 5) difokuskan untuk bentuk
pelayanan dari suatu aplikasi. Sedangkan untuk layer bagian bawahnya
(layer 4, 3, 2 dan 1) berorientasikan tentang aliran data dari ujung satu
ke ujung yang lainnya. Model referensi OSI dapat dijelaskan seperti
Tabel 2.1 berikut :

Tabel 2.1. Model referensi OSI


 
8

2.2 Aplikasi Multimedia Networking


Aplikasi multimedia networking mengirimkan paket data yang
memuat data audio atau video. Aplikasi multimedia networking juga
disebut continues-media applications, karena pengirimannya yang
secara real-time dan terus menerus. Aplikasi multimedia networking
sangatlah sensitif terhadap delay, dimana delay harus tidak melebihi 400
milidetik. Secara khusus, aplikasi multimedia networking toleransi
terhadap loss (loss tolerant). Suatu ketika loss akan terjadi meskipun itu
menyebabkan gangguan pada pemutaran audio/video dan sering kali
loss menghilangkan sebagian atau seluruh data. Ketentuan aplikasi
multimedia sangatlah bertentangan dengan aplikasi static-content yang
mengirimkan data berupa teks dan gambar. Jika aplikasi multimedia
sensitif terhadap delay dan ada toleransi terhadap loss sedangkan
aplikasi static-content masih toleransi terhadap delay namun tidak ada
toleransi terhadap loss.

2.2.1 Contoh Aplikasi Multimedia Networking


Pada jaringan internet menawarkan banyak jenis dari aplikasi
multimedia yang menarik. Aplikasi multimedia didefinisikan menjadi
tiga jenis yang meliputi:
1. Streaming stored audio/video : Pada aplikasi jenis ini client
melakukan request on-demand terhadap file audio atau video
terkompresi yang telah tersimpan pada server. Untuk audio,
biasanya file yang distreamingkan berupa lagu-lagu, orkestra,
arsip rekaman radio yang terkenal, serta arsip rekaman sejarah.
Untuk video, biasanya file yang distreamingkan dapat berupa
video panduan pendidikan, film laga, rekaman acara televisi,
film dokumenter, arsip video dari suatu peristiwa sejarah, video
rekaman pertandingan olahraga, kartun serta video klip musik.
Kapan saja client dapat meminta file audio/video dari server.
Umumnya pada aplikasi stored audio/video, setelah delay
beberapa detik client baru bisa memulai untuk memainkan data
audio/video yang dimintanya dan pada saat itu juga client
menerima data dari server secara terus-menerus (continues).
Sepanjang pemutaran audio/video disaat client menerima data
inilah yang disebut streaming. Banyak aplikasi yang telah
menyediakan fitur user interactive, contoh: pause/resume dan
forward/rewind dalam pemutaran data streaming. Secara ideal
delay saat client meminta (request on-demand) file audio/video
hingga client menerima data (dapat mendengarkan/memainkan
9

file audio/video) seharusnya pada 1 sampai 10 detik.


Persyaratan paket delay dan jitter tidak sebegitu ketat seperti
aplikasi real-time yang ada pada internet telephony dan video
conferencing real-time. Sudah banyak aplikasi Streaming
stored audio and video, meliputi RealPlayer dari RealNetwork
dan NetShoe dari Microsoft.
2. Streaming live audio/video: Pada aplikasi jenis ini mirip
dengan penyiaran radio dan televisi, kecuali transmisi melalui
jaringan internet. Pada aplikasi ini user diijinkan untuk
menerima transmisi radio dan televisi yang dipancarkan dari
penjuru bumi. Biasanya, ada banyak user yang secara
bersamaan menerima audio/video secara real-time. Aplikasi
dari jenis ini tidaklah interaktif : seorang client tidak dapat
mengontrol server dalam mengirimkan data. Seperti dengan
Streaming stored audio and video, persyaratan untuk paket
delay dan jitter tidaklah seketat seperti internet telephony dan
video conferencing secara real-time. Nilai toleransi delay
sampai 10 detik dari saat user meminta sampai audio/video
mulai diputar.
3. Real-time interactive audio/video : Pada aplikasi jenis ini
mengijinkan client menggunakan audio/video untuk
berkomunikasi dengan setiap client yang lain secara real-time.
Audio interaktif banyak digunakan pada intenet telephony
(VoIP), sejak pengguna memandang bahwa VoIP mirip dengan
layanan telepon tradisional yang menggunakan circuit-
switched. Internet phone menawarkan harga yang lebih murah.
Internet phone dapat juga memfasilitasi pengintegrasian antara
komputer dengan telepon (disebut CTI), komunikasi group
real-time, identifikasi pemanggil, penyaringan pemanggil, dll.
Banyak produk internet telephony yang ada saat ini, contoh :
skype. Dengan video interaktif, juga disebut video
conferencing, setiap client dapat berkomunikasi visual maupun
secara lisan. Selama dalam group pertemuan, seorang user
dapat membuka window untuk setiap user lain yang sedang
berpartisipasi. Banyak produk audio dan video interaktif yang
ada pada internet, meliputi Microsoft Netmeeting. Sebagai
catatan bahwa pada aplikasi audio/video interaktif, seorang
user dapat berbicara atau bergerak kapanpun. Delay dari saat
seorang user berbicara atau bergerak sampai tindakan itu
terdengar atau terlihat pada host yang menerimanya seharusnya
10

tidek lebih dari beberapa ratus milidetik. Untuk voice, delay


lebih kecil dari 150 milidetik karena ini tidak akan dirasakan
oleh pendengaran manusia, delay antara 150 sampai 400
milidetik masih dapat diterima namun delay diatas 400 tidaklah
ideal. Delay diatas 400 milidetik akan dirasakan oleh
pendengaran manusia.

2.3 Konsep Streaming


Sistem streaming tersusun dari kombinasi server, player,
transmisi dan metode encoding yang digunakan. Gambar 2.1 adalah
bagan hubungan setiap komponen penyusun sistem streaming.

Gambar 2.1 Komponen sistem penyusun streaming

1. Encoder adalah program yang digunakan untuk mengubah


sumber media ke format yang sesuai untuk streaming. Biasanya
memiliki kompresi yang cukup tinggi untuk mengatasi
keterbatasan bandwith jaringan.
2. Media Server digunakan untuk mendistribusikan on-demand
atau webcast suatu content multimedia ke client. Juga
bertanggung jawab untuk mencatat semua aktivitas streaming,
yang nantinya digunakan untuk statistik.
Implementasinya dapat menggunakan web server (HTTP
Streaming) atau streaming server (True streaming).
3. Media Player dibutuhkan untuk menampilkan atau
mempresentasikan content multimedia (data stream) yang
diterima dari media server. File-file khusus yang disebut
metafile digunakan untuk mengaktifkan player dari halaman
sebuah web. Metafile berisi keterangan dari content
multimedia. Browser web men-download dan meneruskan ke
player yang tepat untuk mempresentasikannya.
11

2.3.1 Proses Transmisi pada Proses Video Streaming


1. Unicast, bersifat end-to-end, di mana setiap client mendapatkan
stream data yang berbeda dari client yang lain, meskipun
pengiriman dilakukan secara simultan. Dengan menggunakan
server yang sama, model koneksi unicast akan membutuhkan
jumlah link koneksi sama sama dengan banyaknya jumlah
client, seperti terlihat di Gambar 2.2.

Gambar 2.2. Sistem transmisi unicast

2. Multicast, server hanya mengirimkan satu jenis data stream


saja yang kemudian diduplikasi oleh router khusus sebelum
dikirim melalui jaringan ke client-client. Secara teknis, model
koneksi multicast hanya bersifat komunikasi satu arah yang
tidak jauh berbeda dengan sistem broadcast pada penyiaran
televisi, sehingga fasilitas on-demand hampir tidak mungkin
dilakukan. Sistem transmisi multicast dapat digambarkan
seperti Gambar 2.3.
12

Gambar 2.3. Sistem transmisi multicast

3. Broadcasting, Server mengirim data ke semua client yang ada


meskipun tidak semua client meminta/membutuhkan data yang
dikirim oleh server.

2.3.2 Pengaksesan Data Streaming dari Web Server


Bagaimana cara sebuah media streaming dapat dikirimkan ke
client? Salah satu pendekatan adalah dengan mengalirkan media dari
sebuah web server standar yang menggunakan hypertext transport
protocol (HTTP). Protokol tersebut digunakan untuk megirim dokumen
dari sebuah web server. Biasanya, client menggunakan sebuah media
player, seperi QuickTime, RealPlayer, atau Windows Media Player,
untuk memutar kembali media yang dialirkan oleh streaming server.
Sebuah koneksi langsung TCP antara server dan media player diperoleh
dengan langkah-langkah (Gambar 2.4) sebagai berikut:
1. Pengguna/client mengklik hyperlink untuk file audio/video.
2. Hyperlink tidak menunjuk langsung ke file audio/video,
melainkan pada metafile. Metafile berisi URL yang sebenarnya
dari file audio/video. HTTP response message
mengenkapsulasi metafile, termasuk content-type: aplikasi
baris header yang menunjukkan secara spesifik
audio/video.
3. Browser pada client akan memeriksa baris header content-type
sebagai pesan respon (response message) yang diterimanya,
kemudian browser menjalankan media playernya, dan
meloloskan sekumpulan response message (contoh : metafile)
untuk diputar oleh media player.
13

4. Media Player akan mendirikan sebuah koneksi TCP langsung


dengan server HTTP. Media player mengirim HTTP request
message sebagai pesan HTTP untuk meminta file audio/video
ke dalam koneksi TCP.
5. File audio/video dikirim kedalam pesan respon HTTP (HTTP
response message) ke pemutar media (media player). Media
player memproses stream file audio/video.

Gambar 2.4. Proses pengiriman file audio/video dari web server ke


media player

2.3.3 Real Time Streaming Protokol (RTSP)


Masalah yang muncul pada pengiriman media streaming dari
sebuah web server adalah web server tidak dapat memelihara status
koneksi dengan client. Hal ini dapat terjadi karena HTTP merupakan
protokol yang stateless. Akibatnya, client akan mengalami kesulitan
pada saat ia melakukan pause selama pengiriman streaming media
masih berlangsung. Pelaksanaan pause akan menyebabkan web server
harus mengetahui status mana yang akan dimulai kembali ketika client
memutar ulang.
Strategi alternatif yang dapat dilakukan untuk menanggulangi
hal diatas adalah dengan menggunakan server streaming khusus yang
didesain untuk men-streaming media, yaitu real time streaming protocol
(RTSP). RTSP didesain untuk melakukan komunikasi antara server
yang melakukan streaming dengan media player. Keuntungan RTSP
adalah bahwa protokol ini menyediakan koneksi yang memiliki status
antara server dan client. Sehingga mempermudah client ketika ingin
melakukan pause atau mencari posisi random (melakukan
forward/rewind) ketika memutar kembali data.
14

RTSP message menggunakan nomor port yang berbeda dari


media streamnya. RTSP menggunakan nomor port 554. (Jika message
RTSP ada yang menggunakan nomor port yang sama sebagai media
stream, maka message RTSP akan dikatakan "interleaved" dengan
media streaming). RTSP menggunakan spesifikasi RFC 2326 yang
mengijinkan message RTSP dikirim baik secara TCP atau UDP.
RTSP memiliki empat buah perintah. Perintah ini dikirim dari client ke
sebuah server streaming RTSP. Keempat perintah tersebut adalah:

1. Setup. Server mengalokasikan sumber daya kepada sesi client.


2. Play. Server mengirim sebuah stream ke sesi client yang telah
dibangun dari perintah setup sebelumnya.
3. Pause. Server menunda pengiriman stream namun tetap
menjaga sumber daya yang telah dialokasikan.
4. Teardown. Server memutuskan koneksi dan membebas
tugaskan sumber daya yang sebelumnya telah digunakan.

Web server mengenkapsulasi gambaran file (metafile) dalam


dalam HTTP response message dan mengirim pesan ke browser. Ketika
browser menerima HTTP response message, browser akan memanggil
media player yang didasarkan pada content-type: isi pesan.
Penggambaran file menunjukkan keterangan media stream, dengan
menggunakan metode URL rtsp: / /, player dan server kemudian saling
mengirimkan serangkaian RTSP message. Player mengirimkan
permintaan SETUP RTSP, dan server mengirim respon SETUP RTSP.
Player mengirimkan permintaan PLAY RTSP, dan server akan
mengirimkan respon PLAY RTSP. Pada tahap ini, streaming server
mengirimkan media stream ke dalam band(channel) sendiri pada
saluran. Kemudian, media player mengirimkan permintaan PAUSE
RTSP, dan server meresponnya dengan respon PAUSE RTSP. Ketika
pengguna selesai, media player mengirimkan permintaan RTSP
TEARDOWN, dan server merespon dengan respon TEARDOWN
RTSP. Interaksi antra client dan server menggunakan protokol RTSP
dapat dijelaskan pada Gambar 2.5 sebagai berikut.
15

Gambar 2.5. Interaksi antara client dan server menggunakan


protokol RTSP

2.3.4 QoS Audio/Video Streaming


Parameter-parameter yang sering dihitung untuk mengetahui
kualitas audio/video streaming meliputi packet loss, excessive end-to-
end delay dan delay jitter. Pembahasan lebih detail untuk mengetahui
kualitas video streaming adalah sebagai berikut :
1. Packet Loss
Data streaming dikirim oleh server dengan format datagram
UDP. Segmen-segmen UDP dienkapsulasi dalam format datagram
IP, dan datagram IP akan membuat jalan menuju penerima. Ketika
datagram berjalan melalui jaringan, melewati buffer (untuk
maksud antrian) di router agar dapat mengakses link keluar. Ada
kemungkinan bahwa satu atau lebih dari buffer dalam rute dari
pengirim ke penerima sudah penuh dan bisa menolak datagram IP.
Dalam kasus ini, datagram IP tersebut akan dibuang dan menjadi
paket yang hilang (packet loss). Dan data streaming tidak sampai
dipenerima.
Loss dapat dihilangkan dengan mengirimkan paket melalui
TCP, karena TCP mentransmisikan kembali paket-paket yang
tidak sampai pada tujuan. Namun, mekanisme retransmisi ini
umumnya tidak dapat diterima untuk aplikasi interaktif streaming,
seperti internet telepon, video conference karena itu akan
16

meningkatkan end-to-end delay. Selanjutnya, karena TCP


congestion control yang menyebabkan setelah paket loss rate
transmisi akan berkurang kenilai rate yang lebih kecil dari nilai
drain rate. Ini dapat mengakibatkan efek buruk terhadap kualitas
streaming untuk dimengerti pada penerima. Untuk alasan ini,
hampir semua yang ada aplikasi internet telepon berjalan
menggunakan UDP yang tidak melakukan retransmisi paket
hilang. Tetapi paket loss yang masih ditoleransi antara 1% sampai
20%. Tabel 2.2 berikut adalah tabel tentang kategori packet loss :

Tabel 2.2. Kategori packet loss


KATEGORI DEGREDASI PACKET LOSS
Sangat bagus 0
Bagus 3%
Sedang 15 %
Jelek 25 %

2. End-to-End Delay
End-to-end delay adalah akumulasi pengolahan dan
keterlambatan queueing di router, delay propagasi, dan proses
delay end-system. Untuk aplikasi audio yang interaktif, seperti
telepon internet, end-to-end delay lebih kecil dari 150 milidetik.
Dengan delay kurang dari 150 milidetik maka tidak akan dirasakan
oleh pendengaran manusia. Delay antara 150 dan 400 milidetik
dapat masih diterima namun itu tidaklah ideal dan delay melebihi
400 milidetik menghasilkan suara percakapan yang terputus-putus.
Aplikasi penerima Internet telephony biasanya akan mengabaikan
semua paket tertunda yang lebih dari batasan tertentu, misalnya,
lebih dari 400 milidetik. Dengan demikian, paket-paket tertunda
lebih dari ambang batasnya secara efektif akan hilang. Tabel 2.3
adalah tabel tentang kategori delay :
17

Tabel 2.3. Kategori besar delay


KATEGORI LATENSI BESAR DELAY
Excellent < 150 ms
Good 150 s/d 300 ms
Poor 300 s/d 450 ms
Unacceptable > 450 ms

3. Delay jitter
Jitter merupakan variasi delay yang terjadi akibat adanya
selisih waktu atau interval antar kedatangan paket di penerima.
Salah satu komponen end-to-end delay adalah keterlambatan
queueing acak di router. Karena keterlambatan queueing acak
dalam jaringan ini, mengakibatkan waktu yang dibutuhan ketika
sebuah paket yang dihasilkan pada sumbernya untuk sampai
diterima di penerima dapat berfluktuasi dari paket satu ke paket
selanjutnya. Fenomena ini disebut jitter. Untuk mengatasi jitter
maka paket data yang datang dikumpulkan dulu dalam jitter buffer
selama waktu yang telah ditentukan sampai paket dapat diterima
pada sisi penerima dengan urutan yang benar.
Sebagai contoh, ketika 2 paket berturut-turut dikirim. Pengirim
mengirimkan paket kedua 20 milidetik setelah mengirim paket
pertama. Tetapi pada penerima selisih waktu paket-paket tersebut
dapat menjadi lebih besar dari 20 milidetik. Untuk membuktikan
ini, misalkan paket pertama tiba ke antrian yang kosong pada
sebuah router, tapi sebelum paket kedua tiba ke antrian ada
beberapa paket yang lain dari sumber tiba diantrian yang sama.
Karena paket kedua mengalami penundaan queueing besar, paket
pertama dan kedua selisih waktunya lebih dari 20 milidetik. (Pada
kenyataannya, jarak antara dua paket berturut-turut dapat menjadi
satu detik atau lebih). Jarak antara urutan paket juga dapat
menjadi kurang dari 20 milidetik. Pada Gambar 2.6 menjelaskan
bagaimana proses terjadiya delay jitter dan pada Tabel 2.4
merupakan kategori peak jitter.

Gambar 2.6. Proses terjadinya delay jitter


18

Tabel 2.4. Kategori peak jitter


KATEGORI DEGRADASI PEAK JITTER
Sangat bagus 0 ms
Bagus 0 s/d 75 ms
Sedang 76 s/d 125 ms
Jelek 125 s/d 225 ms

4. Throughput
Throughput, yaitu kecepatan (rate) transfer data efektif,
yang diukur dalam bps. Troughput merupakan jumlah total
kedatangan paket yang sukses yang diamati pada destination selama
interval waktu tertentu dibagi oleh durasi interval waktu tersebut.

2.3.5. Menghilangkan Delay Jitter


Playout buffer merupakan cara untuk mengatasi delay jitter.
Buffer ditambahkan pada decoder untuk kompensasi jitter. Cara kerja
playout buffer, seperti menambahkan offset ke playout untuk tiap paket.
1. Jika (delay paket < offset) maka OK
2. Paket sampai di buffer sebelum playout time-nya
3. Jika (delay paket > offset) maka problem
Playout buffer umumnya 5 sampai15 detik, sebagai kompensasi untuk
delay jitter maka dimungkinkan melakukan retransmisi terhadap paket
yang hilang. Pada Gambar 2.7 dijelaskan mengenai kondisi Packet
delivery,time-varying delay (jitter), dan playout delay terhadap waktu
penerimaan. Sedangkan pada Gambar 2.8 menjelaskan mengenai paket
yang diterima melebihi playout delay. Paket yang diterima yang
melebihi playout delay akan mengalami loss (dibuang).
19

Gambar 2.7. Packet delivery,time-varying delay (jitter), and


playout delay

Gambar 2.8. Delay per paket dan efek playout delay

Pada perancangan playout buffer harus merancang playout


strategi yang sesuai, untuk mendapatkan kualitas streaming yang
terbaik. Tradeoff antara playout delay dan loss (paket-paket yang
terlambat) adalah sebagai beikut :
1. Delay lebih panjang lebih sedikit paket yang
terlambat (loss)
2. Delay lebih pendek lebih banyak paket
terlambat (loss)
Streaming stored video dapat mentoleransi delay yang panjang
(misal : Real dan Microsoft menggunakan 5 sampai 15 detik).
Sedangkan real-time interactive video tidak dapat mentoleransi delay
panjang (hanya mentoleransi delay sekitar 150 ms). Ada 2 jenis playout
delay meliputi :
a. Fixed delay playout (playout delay tetap)
b. Adaptive delay playout
Dalam hal mengatasi delay jitter, adaptive delay playout lebih baik
daripada playout delay tetap, karena adaptive delay jitter lebih fleksibel
terhadap estimasi delay jitter.

2.3.6. Memperbaiki Packet Loss


Packet loss dapat diperbaiki dengan melakukan error control
pada sisi kanal dan penerima. Tujuan error control adalah untuk
mengatasi efek error seperti kehilangan paket (packet loss) pada jaringan
atau burst error pada link wireless. Tipe tipe error control meliputi :
a. Forward error control (FEC) Æ channel coding
20

Tujuan dari FEC adalah menambahkan bit-bit redundansi yang


dapat digunakan untuk recovery dari error.
b. Retransmisi Æ channel coding
Pendekatan dari retransmisi adalah penerima memberitahu
pengirim, paket mana yang diterima/hilang dan pengirim
mengirim ulang paket yang hilang.
c. Error Concealment Æ source coding
Tujuan dari Error Concealment adalah estimasi kehilangan
informasi supaya menutupi (conceal) error yang terjadi. Error
concealment dilaksanakan pada decoder.
d. Error-Resilent video Æ source coding
Tujuan dari error-resilent adalah disain algoritma kompresi
video dan deretan bit terkompres yang tahan terhadap error.

2.4 Protokol Streaming


Standar Real-Time Transport Protokol dikembangkan oleh
Audio-Video Transport Working Group yang mengacu pada Internet
Engineering Task Force (IETF). Standarnya didokumentasikan dalam
RCF 1889 dan RFC 1890. Untuk menggunakan layanan aplikasi real
time harus diimplementasikan 2 protokol yaitu:
1. RTP : menyediakan layanan transportasi paket data secara real
time.
2. RTCP : mengawasi kualitas layanan yang disediakan pada RTP
session yang sudah ada.
Versi terakhir untuk standar ini di publikasikan pada januari
1996. Standar-standar ini menjelaskan tentang fungsi-fungsi yang
diharapkan akan menjadi hal yang umum pada semua tipe aplikasi real-
time. Untuk mengakomodasi aplikasi real time yang baru, arsitektur
sebelumnya dengan sengaja tidak dikembangkan. Tidak seperti protokol
konvensional, RTP dibuat melalui modifikasi dan penambahan sesuai
kebutuhan. Ini menyebabkan protokol dengan mudah beradaptasi pada
standar audio dan video yang baru.
Semakin meningkatnya kemampuan proses pada desktop
komputer telah mendorong perkembangan berbagai macam aplikasi
multimedia. Aplikasi-aplikasi ini melibatkan infrastruktur jaringan yang
sudah ada untuk mengirim aplikasi yang berbasis video dan audio
kepada end user. Jaringan tidak lagi hanya semata-mata untuk
mendukung transmisi data tradisional
Aplikasi ini menyediakan kemampuan yang lebih untuk video
conferencing dua arah, audio broadcasting, whiteboard collaboration,
21

interactive training, dan IP telephony. Dengan aplikasi ini, video dan


audio ditransfer melalui jaringan, antar-peer atau antara client dan
server.
Protokol streaming menyediakan deskripsi tentang two peer
protocols. Protokol streaming dipakai untuk memfasilitasi aplikasi
streaming yaitu Real Time Transport Protocol (RTP) dan Real Time
Control Protocol (RCTP) yang digunakan untuk sinkronisasi dan
kontrol aliran trafik pada aplikasi multimedia. RTP OSI model dapat
diilustrasikan pada Gambar 2.9.

Gambar 2.9. RTP OSI model

2.4.1 RTP ( Real Time Protocol )


RTP menyediakan fungsi transport jaringan end-to-end yang
cocok untuk aplikasi transmisi data real-time, seperti audio dan video
melalui layanan jaringan multicast atau unicast. RTP tidak menjamin
quality-of-service dalam layananya, sehingga dalam pengirimn data
ditambah sebuah protokol kontrol (RTCP) untuk pemantauan
pengiriman data. RTP menggunakan transport UDP yang merupakan
conectionless protocol. RTP juga menambahkan format informasi yang
dibutuhkan oleh aplikasi seperti : sequence number, timestamp. Header-
header RTP lebih jelasnya dapat dilihat pada Gambar 2.10 berikut:
22

Gambar 2.10. RTP header

1) V, Version. 2 bits.
Versi dari RTP. Selalu diatur 2.
2) P, Padding. 1 bit.
Jika diatur adanya padding, maka paket ini berisi satu atau
lebih byte padding tambahan yang terletak di akhir tetapi bukan
bagian dari payload. Padding mungkin diperlukan oleh
beberapa algoritma enkripsi dengan ukuran blok tetap atau
pembawa paket RTP pada layer protokol yang lebih rendah.
3) X. Extensions. 1 bit.
Jika diatur adanya extensions, maka header diikuti dengan satu
ekstensi header tetap.
4) M, Marker. 1 bit.
Penafsiran marker didefinisikan oleh profil. Ini dimaksudkan
agar ada batas bingkai yang ditandai dalam aliran paket, Profil
dapat menentukan bit penanda tambahan (marker) atau
menetapkan tidak adanya marker dengan mengubah jumlah bit
dibidang jenis payload.
5) PT, Payload Type. 7 bits.
Mengidentifikasi format payload RTP dan menentukan
penafsiran oleh aplikasi. Secara default profil menentukan
pemetaan statis terhadap kode jenis payload untuk format
payload. Tambahan kode jenis payload kemungkinan
didefiisikan secara dinamis oleh non-RTP. Sebuah pengirim
RTP mengirimkan jenis single RTP payload pada waktu
tertentu; bidang ini dimaksudkan untuk multiplexing dengan
media stream yang terpisah.
6) Sequence Number. 16 bits.
Sequence number merupakan nomor urutan paket setiap data
paket RTP terkirim, dan dapat digunakan oleh penerima
sebagai pendeteksi packet loss dan untuk mengembalikan
urutan paket. Nilai awal nomor urutan paket adalah acak.
23

7) Timestamp. 32 bits.
Timestamp mencerminkan sampling dari octet pertama dalam
data paket RTP. Sampling harus berasal dari peningkatan jam
yang monoton dan linier untuk memungkinkan sinkronisasi dan
perhitungan jitter. Sebagai contoh, untuk audio fixed-rate
kemungkinan timestamp akan naik per satu untuk setiap
periode sampling. Jika suatu aplikasi audio yang membaca blok
mencakup periode sampling 160 dari input, timestamp akan
meningkat 160 untuk setiap blok tersebut.
8) SSRC, Synchronization source. 32 bits
Mengidentifikasi sumber sinkronisasi. Nilai dipilih secara acak,
dengan maksud bahwa tidak ada sumber kedua dalam sesi RTP
yang sama yang akan memiliki SSRC sama. Meskipun
kemungkinan berbagai sumber memilih identifier yang sama
rendah, semua implementasi RTP harus siap untuk mendeteksi
dan menyeleseikan collisions. Jika alamat transport sumber
berubah, SSRC juga harus memilih SSRC baru untuk
menghindari penafsiran sumber yang berulang.

2.4.2 RTCP ( Real Time Control Protocol )


RTCP mempunyai fungsi untuk mengatur pengiriman real
time. Saat ini banyak aplikasi membutuhkan feed back untuk
mendapatkan performa terbaik, maka fungsi ini disediakan oleh RTCP.
Protokolnya berdasar pada transmisi periodik dan kontrol paket untuk
semua partisipan dalam satu sesi. Fungsi utama dari RTCP adalah untuk
menyediakan feed back mengenai kualitas distribusi data RTP. Hal ini
dapat dibandingkan dengan fungsi control congestion dan flow yang
disediakan oleh protokol transport yang lain. Feed back yang disediakan
oleh setiap penerima berguna untuk mendiagnosa kegagalan distribusi.
Dengan mengirim feedback pada semua partisipan dalam satu session,
device dapat mengatasi masalah dalam pentransmisian. RTCP juga
mampu untuk mengatur sekumpulan network service provider yang
tidak siap untuk menerima informasi feedback dalam sesi. Network
provider bertindak sebagai pihak ketiga untuk mendiagnosa masalah
jaringan. RTCP menggunakan sebuah koneksi UDP untuk komunikasi.
Hal ini berbeda dengan koneksi UDP yang digunakan oleh protokol
RTP. Gambar 2.11. menunjukkan kerja sama dari protokol RTCP dan
RTP.
24

Gambar 2.11. Paket delivery RTP dan RTCP

2.5 De-enkapsulasi
De-enkapsulasi, terjadi saat client tujuan menerima paket data.
Data mengalir ke atas dari layer yang lebih rendah ke layer yang lebih
tinggi dari TCP/IP protocol. Setiap layer membuka header yang cocok
dan menggunakan informasi yang dikandungnya untuk disampaikan ke
layer di atasnya sampai pada layer tertinggi atau layer aplikasi
mendapatkan data dalam jaringan sesungguhnya.

Proses kerja de-enkapsulasi seperti ditunjukkan pada Gambar 2.12:


1. Pada tujuan, bit stream ini kemudian diubah menjadi FRAME.
2. FRAME-header kemudian dilepas dan dikirim ke layer-3
sebagai PAKET.
3. Paket selanjutnya melepas Header dan mengirim data tersebut
ke layer-4 sebagai SEGMENT.
25

4. SEGMENT kemudian melepas layer-4 header dan memberikan


data ke layer-5,6,7 yang akhirnya diterima oleh user sebagai
data.
5. Proses pelepasan header dari layer ke layer disebut sebagai De-
enkapsulasi.

Gambar 2.12. Blok diagram RTP de-encapsulation

2.6. Pemrograman Socket


Socket adalah mekanisme komunikasi yang memungkinkan
terjadinya pertukaran data antar program atau proses baik dalam satu
mesin maupun antar mesin. Gaya pemrograman socket sendiri berawal
dari sistem Unix BSD yang terkenal dengan kepeloporannya pada
bidang penanganan jaringan, sehingga sering disebut BSD Socket.
Socket pertama kali diperkenalkan di sistem Unix BSD versi 4.2 tahun
1983 sebagai kelanjutan dari implementasi protokol TCP/IP yang
muncul pertama kali pada sistem Unix BSD 4.1 pada akhir 1981.
Hampir setiap variant Unix dan Linux mengadopsi BSD Socket.
Linux menggunakan paradigma open-read-write-close. Sebagai
contoh, suatu aplikasi pertama harus memanggil open untuk menyiapkan
26

file yang akan diakses. Kemudian aplikasi tersebut memanggil read atau
write untuk membaca data dari pada file atau menuliskan data ke file.
Setelah itu close dijalankan untuk mengakhiri aplikasi yang digunakan.
Interface soket dalam berkomunikasi bisa dilihat pada gambar 2.17
berikut :

Gambar 2.13. Ilustrasi interface socket

Di dalam kotak menunjukkan system call/function yang dibutuhkan


untuk koneksi/komunikasi, misal socket(), bind(), listen(), connect(), dll.
Secara garis besar langkah – langkah yang dilakukan pada client dan
server adalah sebagai berikut :
1. Langkah – langkah dasar di client :
a) Membuka koneksi client ke server, yang di dalamnya adalah :
1. Membuat socket dengan perintah socket()
2. Melakukan pengalamatan ke server.
3. Menghubungi server dengan connect()
b) Melakukan komunikasi (mengirim dan menerima data), dengan
menggunakan perintah write() dan read()
c) Menutup hubungan dengan perintah close();
2. Langkah – langkah dasar di server :
a) Membuat socket dengan perintah socket()
b) Mengikatkan socket kepada sebuah alamat network dengan
perintah bind()
27

c) Menyiapkan socket untuk menerima koneksi yang masuk


dengan perintah listen()
d) Menerima koneksi yang masuk ke server dengan perintah
accept()
e) Melakukan komunikasi (mengirim dan menerima data), dengan
menggunakan perintah write() dan read()

Komunikasi antar program dapat berlangsung lewat


penggunaan deskriptor file standar Unix dengan bantuan socket. Semua
entitas yang ada pada Unix atau Linux selalu didefinisikan sebagai file.
Perangkat-perangkat dalam komputer, seperti hardisk, mouse, bahkan
perangkat I/O seperti Serial Port, Paralel Port, USB, selalu didefinisikan
sebagai file dalam sistem file Unix. Contohnya untuk port serial
mungkin akan didefinisikan sebagai file /dev/ttyS1. Secara konsep,
untuk dapat mengirimkan dan menerima data lewat port serial, Anda
harus membuka file /dev/ttyS1 dengan sebuah fungsi misalkan open()
yang akan menghasilkan sebuah nilai integer. Nilai integer ini akan
disimpan pada sebuah variable tertentu yang dikenal dengan deskriptor
file. Pengiriman dan penerimaan data dilakukan dengan bantuan
deskriptor file ini sebagai referensi tempat data tersebut dikirim dan
diterima. Anda dapat membuka referensi mengenai ini pada referensi
Unix/Linux.
Komunikasi antar proses dengan menggunakan socket ini
merupakan pengembangan lebih lanjut dari "teknologi pipes" di dalam
lingkungan Unix. Socket ini dapat digunakan seperti jika penggunaan
pipes di unix. Keunggulan dari penggunaan socket ini dibanding apabila
menggunakan pipes biasa adalah anda dapat melakukan komunikasi
antar proses/program melalui jaringan yang berbasis TCP/IP,sepanjang
program tersebut berbicara dalam protokol transfer yang sama. Fasilitas-
fasilitas yang disediakan oleh mesin unix seperti rlogin, ssh, ftp, dan
lain-lain menggunakan socket sebagai sarana komunikasi mereka.
Socket dibentuk dan digunakan dengan cara yang berbeda dengan proses
pipes di unix. Komunikasi socket terutama diciptakan untuk tujuan
menjembatani komunikasi antara dua buah program yang dijalankan
pada mesin yang berbeda. Kelebihan lain dari komunikasi socket adalah
mampu menangani banyak klien sekaligus (multiple clients).

2.6.1 Jenis-jenis Socket


Ada beberapa golongan socket di Unix dan yang paling umum
dipakai yaitu:
28

a. Socket Lokal atau AF_UNIX


Socket Lokal adalah socket yang melakukan komunikasi
dengan perantaraan sebuah file yang biasanya diletakkan pada
direktori /tmp atau /usr/tmp ataupun /var/tmp. Socket semacam
ini digunakan umumnya terbatas untuk komunikasi antar
aplikasi dalam satu mesin.
b. Socket Networking atau AF_INET
Socket Networking ditujukan untuk komunikasi antar aplikasi
antar mesin dalam lingkungan jaringan TCP/IP. Identifikasi
socket dilakukan dengan sebuah service identifier yaitu berupa
nomor port TCP/IP yang dapat di sambung oleh klien.
c. Socket Stream atau SOCK_STREAM
Socket Stream adalah socket komunikasi full-duplex berbasis
aliran (stream) data. Pada model komunikasi Socket Stream,
koneksi dua aplikasi harus dalam kondisi tersambung dengan
benar untuk dapat bertukar data. Ini dapat dianalogikan seperti
komunikasi telepon. Jika sambungan telepon di salah satu titik
putus, maka komunikasi tidak dapat terjadi. Koneksi model
seperti ini akan menjamin data dapat dipertukarkan dengan
baik, namun memiliki kelemahan dalam hal penggunaan jalur
data yang relatif besar dan tidak boleh terputus.
d. Socket Datagram atau SOCK_DGRAM
Socket Datagram berkomunikasi dengan cara yang berbeda.
Socket ini tidak membutuhkan koneksi yang tersambung
dengan benar untuk mengirimkan dan menerima data. Model
koneksi semacam ini tidak dapat menjamin data dapat
dipertukarkan dengan baik, namun memiliki keunggulan dalam
hal penggunaan jalur data yang minimal.

2.7 ORTP
ORTP merupakan library untuk Real-time Transport Protocol
(RTP,RFC3550). Fitur-fitur oRTP meliputi :
1. Pemrograman bahasa C yang bekerja dibawah Linux
(beberapa Unix) dan Windows.
2. Mengimplementasikan RFC 3550 (RTP).
3. Mendukung untuk multiple profile, secara default AV
profile menggunakan (RFC 3551).
4. Termasuk sebuah packet scheduler untuk mengirimkan
dan menerima paket secara “on time”, menurut
timestampnya.
29

5. Mendukung multiplexing IO, sehingga ribuan dari sesi


RTP dapat dijadwalkan oleh sebuah single thread.
6. Fitur algoritma adaptive jitter supaya penerima dapat
beradaptasi dengan clockrate pengirim.
7. Mendukung bagian dari RFC 2833 untuk telepon yang
berjalan menggunakan RTP.
8. API yang didokumentasikan oleh doxygen.
9. Dilesensi oleh Lesser Gnu Public License.
10. Pesan RTCP dikirimkan secara periodik.
11. Termasuk API untuk mengirimkan paket RTCP yang
datang.

Fungsi-fungsi library oRTP API meliputi :


a. RtpSession API : Objek RtpSession menyediakan kontrol pada sesi
RTP sebagaimana didefinisikan dalam RFC 1889.

1. RtpSession* rtp_session_new (int mode);

Membuat sebuah sesi RTP. Sesi untuk mengirimkan data adalah


(RTP_SESSIONS_SENDONLY or RTP_SESSION_SENDRECV),
kemudian sebuah nomor SSRC acak dipilih untuk outgoing stream.

mode : satu dari RtpSessionsMode flags.


Returns : sesi rtp yang baru dibuat.

2. void rtp_session_set_scheduling_mode (RtpSession *session, int


yesno);

Membuat modus penjadwalan dalam sesi RTP. Jika yesno berarti


TRUE, sesi RTP berada dalam modus penjadwalan, yang berarti
dapat menggunakan session_set_select () untuk pemblokiran data
hingga waktu penerimaan atau pengiriman menurut timestamp.
Pemblokiran data juga dapat menggunakan mode blocking yaitu
fungsi rtp_session_set_blocking_mode (), untuk blocking
penerimaan dan pengiriman secara langsung. Jika yesno adalah
FALSE, scheduler ortp tidak akan mengatur sesi-sesi, yang berarti
bahwa modus pemblokiran dan penggunaan session_set_select ()
untuk sesi ini adalah dinonaktifkan.

session : sebuah sesi rtp


30

yesno : Boolean untuk indikasi modus scheduling

3. void rtp_session_set_blocking_mode (RtpSession *session,int


yesno);

Dengan menggunakan fungsi ini menandakan bahwa sebelumnya


mengaktifkan mode scheduling( rtp_session_set_scheduling_mode
()). rtp_session_set_blocking_mode () mendefinisikan perilaku
fungsi rtp_session_recv_with_ts () dan rtp_session_send_with_ts ().
Jika yesno adalah TRUE, rtp_session_recv_with_ts () akan
memblokir sampai waktu untuk dapat menerima paket, sesuai
dengan timestampnya. Untuk rtp_session_send_with_ts (), akan
memblokir sampai waktu untuk dapat mengirimkan paket. Jika
yesno adalah FALSE, maka dua fungsi akan kembali segera.

session : sebuah sesi rtp


yesno : sebuah boolean

4. void rtp_session_set_profile (RtpSession *session,


RtpProfile *profile);

Mengatur profil RTP yang akan digunakan untuk sesi. Secara


default, semua sesi diciptakan oleh rtp_session_new () yang
diinisialisasi dengan profil AV, sebagaimana didefinisikan di RFC
3551. Aplikasi ini dapat mengatur beberapa profil lain.

session : sesi rtp


profile : rtp profile

5. RtpProfile* rtp_session_get_profile (RtpSession *session);

session : sesi rtp


Returns : profile yang sedang berjalan

6. int rtp_session_set_local_addr (RtpSession *session, const char


*addr, int port);

Menentukan local addr yang akan akan digunakan untuk menerima


paket RTP atau pengirim paket RTP berasal. Dalam kasus di mana
sesi RTP send-only, maka tidak diminta untuk memanggil fungsi
31

ini: saat pemanggilan rtp_session_set_remote_addr (), jika tidak


ada alamat lokal ditetapkan, maka alamat IP defaultnya
INADRR_ANY (0.0.0.0) dengan nomor port acak. Pemanggilan
rtp_sesession_set_local_addr () adalah wajib ketika sesi ini dalam
keadaan recv-only atau duplex.

session : sesi rtp yang baru saja dibuat


addr : alamat IP lokal dalam bentuk xxx.xxx.xxx.xxx
port : port lokal atau satu nomor port yang dipilih acak oleh
oRTP

Returns : 0 jika sukses

7. int rtp_session_set_remote_addr (RtpSession *session,const char


*addr, int port);

Menentukan remote address dari sesi RTP, yaitu alamat tujuan


dimana paket RTP dikirim. Jika sesi tersebut recv-only atau duplex,
tentukan pula asal paket RTP. Paket RTP yang tidak berasal dari
addr:port akan dibuang.

sessions : sesi rtp yang baru dibuat


addr : IP address local dalam bentuk xxx.xxx.xxx.xxx
port : port lokal

Returns : 0 jika sukses

8. int rtp_session_get_local_port (const RtpSession *session);

Fungsi ini berfungsi untuk mengambil port lokal yang dipilih


secara acak oleh rtp_session_set_remote_addr () ketika
rtp_session_set_local_addr () tidak dipanggil.

session : sesi RTP untuk rtp_session_set_local_addr () atau


rtp_session_set_remote_addr () yang telah dipanggil

Returns: port lokal yang digunakan untuk listen paket rtp, -1


jika tidak diatur
32

9. void rtp_session_set_jitter_compensation (RtpSession *session,


int milisec);
Mengatur interval waktu paket dalam buffer sebelum diterima oleh
aplikasi.

session : RtpSession
milisec : interval waktu dalam milisec untuk jitter yang dapat
dikompensasi

10. void rtp_session_set_ssrc (RtpSession *session, uint32_t ssrc);


Mengatur SSRC untuk outgoing stream. Jika tidak dipanggil, maka
random ssrc akan digunakan.

session : sesi rtp


ssrc : unsigned 32 bit integer yang menggambarkan
synchronization source identifier (SSRC)

11. void rtp_session_set_seq_number (RtpSession *session,


uint16_t seq);

Mengatur inisialisasi sequence number untuk setiap pengiriman


dalam suatu sesi.

session : sesi rtp yang baru dibuat


seq :

12. int rtp_session_set_send_payload_type (Rtpsession *session,


int paytype);

Mengatur jenis payload dalam suatu sesi RTP. Fungsi ini


menentukan jenis payload yang ditulis dalam header RTP untuk
outgoing stream, saat sesi ini SENDRECV atau SENDONLY.
Untuk jenis paket yang datang, aplikasi dapat diinformasikan oleh
registering untuk sinyal "payload_type_changed" , sehingga dapat
membuat perubahan yang diperlukan pada decoder downstream
yang berhubungan dengan payload dari paket.

session : sesi rtp


paytype : jenis payload
33

Returns : 0 jika sukses, -1 jika payload tidak didefenisikan

13. int rtp_session_set_recv_payload_type (Rtpsession *session, int pt);

Mengatur jenis payload untuk paket yang masuk. Jika jenis payload
paket yang masuk tidak sesuai harapan, maka akan mengirimkan
sinyal "payload_type_changed".

session : sesi rtp


pt :

Returns : 0 jika sukses, -1 jika payload tidak didefenisikan

14. int rtp_session_get_send_payload_type (const RtpSession


*session);

session : sesi rtp

Returns : jenis payload yang sedang digunakan untuk outgoing


paket rtp

15. int rtp_session_get_recv_payload_type (const RtpSession


*session);

session : sesi rtp

Returns : jenis payload yang sedang digunakan untuk incoming


paket rtp
16. int rtp_session_set_payload_type (RtpSession *session, int pt);

Mengatur jenis payload paket dating sesuai yang diharapkan. Jika


jenis payload yang masuk tidak sesuai maka mengirimkan sinyal
“payload_type_changed”.

session : sesi RTP


pt :

Returns : 0 jika sukses, -1 jika payload tidak didefinisikan


34

17. int rtp_session_signal_connect (RtpSession *session, const char


*signal, RtpCallback cb, unsigned long user_data);

Fungsi ini menyediakan cara bagi aplikasi untuk diberi informasi


tentang berbagai peristiwa yang mungkin terjadi selama sesi RTP.
Signal adalah string yang mengidentifikasi aktivitas tersebut, lalu
cb adalah fungsi yang diberikan untuk mengatasi atas proses situ.
Aplikasi dapat mendaftar callback sinyal yang sama, dalam batasan
RTP_CALLBACK_TABLE_MAX_ENTRIES. Berikut adalah
nama dan makna jenis sinyal yang didukung:

"ssrc_changed": SSRC dari incoming stream telah berubah.

"payload_type_changed": jenis payload dari incoming stream telah


berubah.

"telepon-event_packet": telephon – event paket rtp (RFC2833)


diterima.

"telepon-event": Cara pintas high level untuk "telepon-


event_packet".

"network_error": kesalahan jaringan yang terjadi pada socket.


Argument-argument dari fungsi callback adalah const char * yang
berarti kesalahan, int errno adalah kode kesalahan dan user_data
tersebut.

"timestamp_jump": saat menerima sebuah paket dengan timestamp


yang melompat jauh dibandingkan dengan timestamp terakhir
diterima. Maka diatur oleh rtp_sesssion_set_time_jump_limit ()
"rtcp_bye": yang mengirimkan paket RTCP bye. Argumen dari
fungsi callback adalah const char * yang berisikan alas an dan
user_data tersebut.

sessions : sesi rtp


signal : nama dari signal
cb : RtpCallback
Param4 :
35

Returns : 0 jika sukses, EOPNOTSUPP jika signal tidak ada, -1


jika tidak satupun callback dapat menandai jenis signal

18. int rtp_session_signal_disconect_by_callback (RtpSession


*session, const char *signal, RtpCallback cb);

Menghapus fungsi callback cb dari daftar callbacks dengan sinyal


signal

session : sesi rtp


signal : nama sinyal
cb : fungsi callback

Returns : 0 jika sukses, -ENOENT jika callback tidak ditemukan

19. int rtp_session_send_with_ts (RtpSession *session, const char


*buffer, int len, uint32_t userts);

Mengirim datagram RTP ke tujuan yang diatur oleh


rtp_session_set_remote_addr () yang berisi data dari buffer dengan
timestamp userts. Ini adalah fungsi tingkat tinggi yang
menggunakan rtp_session_create_packet() dan
rtp_session_sendm_with_ts () untuk mengirim data.

sessions : sesi RTP


buffer : buffer yang berisi data untuk dikirimkan dalam paket
RTP
len : panjang data dalam buffer, dalam bytes
userts : timestamp data yang dikirimkan.

Returns : jumlah bytes yang dikirimkan melalui jaringan

20. int rtp_session_recv_with_ts (RtpSession *session, char *buffer,


int len, uint32_t time, int *have_more);

Membaca byte incoming RTP stream yang berhubungan dengan


timestamp time. Dalam kasus dimana pengguna diberikan buffer
buffer yang tidak cukup besar untuk mendapatkan semua data yang
terkait dengan timestamp time, maka * (have_more) diset ke 1
untuk menunjukkan bahwa aplikasi seharusnya dapat memanggil
36

kembali fungsi dengan timestamp yang sama untuk mendapatkan


lebih banyak data.

Ketika sesi RTP dijadwalkan oleh


rtp_session_set_scheduling_mode (), dan mode memblokir oleh
rtp_session_set_blocking_mode lihat (), maka komunikasi ditunda
sampai timestamp yang diberikan sebagai argumen berakhir,
meskipun paket diterima sesuai dengan permintaan atau tidak.

Catatan penting: sudah jelas bahwa aplikasi tidak dapat mengetahui


informasi waktu dari paket pertama dari incoming stream, karena
bisa acak. Waktu timestamp yang digunakan oleh fungsi adalah
relatif untuk timestamp pertama. Secara sederhana, 0 adalah nilai
yang baik untuk mulai memanggil fungsi ini.

Fungsi rtp_session_recvm_with_ts () yang berfungsi untuk


mendapatkan paket RTP. Isi dari paket ini kemudian disalin ke
dalam buffer pengguna yang telah disediakan. Fungsi memperoleh
ukuran buffer dari timestamp yang diberikan dalam argumen.
Menggunakan fungsi ini kemungkinan digunakan untuk membaca
data audio kontinyu (misalnya pcma, pcmu ...), untuk contoh buffer
standar ukuran 160 dengan timestamp incrementing 160 sementara
stream yang masuk memiliki ukuran paket yang berbeda.
 
session : sesi rtp
buffer : buffer client yang diberikan untuk menulis data
len : panjang bytes di buffer client
time : timestamp yan diinginkan
have_more : alamat dari integer untuk menunjukkan bahwa masih
ada data yang diberi timestamp

Returns : jika paket itu ada dengan timestamp yang sesuai


diberikan pada argumen, maka jumlah byte yang
ditulis dalam buffer yang diberikan pengguna
dikembalikan. Jika tidak ada paket, yang disebabkan
pengirim belum mulai mengirimkan stream atau
karena tidak adanya paket yang dikirimkan ataupun
karena paket hilang selama transmisi, maka fungsi
kembali 0.
37

 
21. mblk_t* rtp_session_recvm_with_ts (RtpSession *session,
uint32_t user_ts);

Mendapatkan paket RTP yang disajikan sebagai struktur mblk_t


dari sesi RTP. Parameter user_ts adalah untuk timestamp relatif
pertama dari incoming stream. Dengan kata lain, aplikasi tidak
perlu mengetahui timestamp pertama dari stream, secara mudah
panggilan untuk pertama kali fungsi ini dengan user_ts = 0, dan
kemudian dinaikkan seperti yang diinginkan. RtpSession yang
bertanggung jawab atas sinkronisasi antara timestamp pengirim dan
timestamp pengguna.

session : sesi rtp


user_ts : timestamp

Returns : paket rtp yang disimbolkan sebagai mblk_t

22. mblk_t* rtp_session_create_packet (RtpSession *session, int


header_size, const char *payload, int payload_size);

Mengalokasikan paket RTP baru. Pada header, ssrc dan


payload_type menurut konteks sesi itu. Timestamp dan seq number
tidak ditetapkan, tetapi akan ada yang mengatur kapan paket akan
dikirim dengan rtp_session_sendm_with_ts (). Jika payload_size
adalah nol, sehingga paket kosong (hanya header RTP)
dikembalikan.

session : sesi rtp


header_size : ukuran rtp header. Untuk ukuran standar
(tanpa Ekstensi), adalah
RTP_FIXED_HEADER_SIZE
payload : data untuk disalin ke paket RTP
payload_size : ukuran data yang dibawa oleh paket RTP

Returns : paket RTP dalam struktur mblk_t (pesan


block)
38

23. mblk_t* rtp_session_create_packet_with_data (RtpSession


*session, char *payload, int payload_size, void (*freefn) (void*));

Membuat paket RTP baru menggunakan buffer payload yang


diberikan (bukan menyalin). Header akan dialokasikan secara
terpisah. Pada header, ssrc dan payload_type menurut konteks sesi
itu. Timestamp dan seq number tidak ditetapkan, tetapi akan ada
yang mengatur kapan paket akan dikirim dengan
rtp_session_sendm_with_ts ().

session : sesi rtp


payload : data yang dikirim
payload size: ukuran dari data
freefn : fungsi yang dipanggil saat payload buffer
tidak dibutuhkan

Returns : paket RTP dalam struktur mblk_t (pesan


block)

24. int rtp_session_sendm_with_ts (RtpSession *session, mblk_t


*mp, uint32_t userts);

Mengirimkan datagram RTP mp ke tujuan yang diatur oleh


rtp_session_set_remote_addr () dengan timestamp timestamp.
Untuk data audio, timestamp adalah angka dari sampel pertama
yang dihasilkan oleh data terkirim. Secara detail dapat dilihat pada
rfc 1889. Paket (mp) dikosongkan setelah pengiriman selesei.

session : sesi RTP


mp : paket RTP yang disimbolkan sebagai mblk_t
userts :

Returns : sejumlah bytes yang dikirimkan melalui jaringan

25. uint32_t rtp_session_get_current_send_ts (RtpSession *session);


39

Ketika sesi RTP dijadwalkan dan telah mulai mengirimkan paket,


fungsi ini menghitung timestamp yang cocok untuk digunakan pada
saat itu. Dengan menggunakan fungsi ini dapat berguna bila
mengirim aliran diskontinu. Dalam rangka untuk mendapatkan
timestamp yang valid untuk lolos ke # rtp_session_send_with_ts ()
atau # rtp_session_sendm_with_ts (), aplikasi dapat menggunakan
rtp_session_get_current_send_ts ().

session : sesi RTP

Returns : timestamp kirim pada saat sesi RTP

26. void rtp_session_flush_sockets (RtpSession *session);

Socket flushes dipakai bila ada paket masuk yang tertunda. Hal ini
dapat berguna jika penerima tidak dapat menerima stream
sementara ingin mulai menerima lagi.

session : sesi RTP

27. void rtp_session_set_time_jump_limit (RtpSession *session, int


milisecons);

oRTP memiliki kemungkinan untuk menginformasikan aplikasi


melalui callback terdaftar dengan rtp_session_signal_connect
tentang incoming RTP yang melompat dari timestamp N ke N+.
Hal ini memungkinkan kesempatan untuk aplikasi untuk mengatur
ulang untuk resynchronize, atau tindakan lain seperti menghentikan
komunikasi dan pelaporan error.

session : sesi RTP


milliseconds :
40

28. void rtp_session_set_recv_buf_size (RtpSession *session, int


bufsize);

Nilai default adalah 65535 bytes, nilai yang besar untuk dikerjakan.
Namun jika aplikasi dapat membuat asumsi tentang MTU, dapat
diatur ke nilai yang lebih rendah untuk menghemat memori.

session : sesi RTP


bufsize : ukuran buffer dalam bytes untuk menerima paket

29. void rtp_session_reset (RtpSession *session);


Sesi reset: alamat lokal dan remote dipertahankan tetapi antrian
internal untuk pemesanan dan buffering paket dihapus, sehingga
sesi siap untuk disinkronkan kembali masuk ke stream.

session : sesi RTP

30. void rtp_session_set_data (RtpSession *session, void *data);

Penyimpanan data kedalam sesi oleh aplikasi tertentu, sehingga


secara mudah untuk mengambilnya kembali dari signal callback
menggunakna rtp_session_get_data ().

session : sesi RTP


data : sebuah pointer untuk disimpan dalam sesi

31. void* rtp_session_get data (const RtpSession *session);

session : sesi RTP

Returns : void pointer sebelum diatur menggunakan


rtp_session_set_data ()
 
b. RTP payloads dan profiles : Bagian ini menjelaskan cara oRTP
mengelola tumpukan RTP profile dan jenis payload.
41

1. void rtp_profile_clear_all (RtpProfile *prof);

Menginisialisasi profile ke profile yang masih kosong.

prof :

2. #define rtp_profile_get_name (profile) (const char*) ((profile) =>


name)

profile : obyek profile RTP (RtpProfile)

3. void rtp_profile_set_name (RtpProfile *prof, const char *name);

Mengatur nama untuk profile RTP

prof :
name :

4. void rtp_session_set_payload (RtpProfile *prof, int index,


PayloadType *pt);

Menetapkan nomor jenis payload dengan index yang diisikan


dalam pt untuk profil RTP profiel.

prof :
index : nomor jenis payload
pt: gambaran jenis payload (obyek PayloadType)
 
5. #define rtp_profile_clear_payload (profile, index)
rtp_profile_set_payload (profile, index,NULL)

Mengatur nomor jenis payload index yang belum digunakan dalam


profile profile.

profile : RTP profile (RtpProfile object)


index : nomor jenis payloads
42

c. Multiplexing sessions : SessionsSet API mengijinkan aplikasi untuk


membuat I/O pada sesi multiple RTP tanpa membuat pemblokan
I/O, tetapi menjaga proses utama tersinkronisasi.

1. SessionSet* session_set_new ();

Pengaturan alokasi dan inisilisasi sesi baru.

Returns : pengaturan sesi

2. #define session_set_init (ss) ORTP_FD_ZERO(&(ss)=>rtpset)

Pengaturan inisialisasi sesi. Fungsi ini dipanggil jika sesi tidak


dibutuhkan, sehingga objek dikembalikan oleh session_set_new ().

ss : SessionSet tetap yang telah dialokasikan

3. define session_set_set (ss,rtpsession) ORTP_FD_SET((rtpsession)


=>mask_pos, &(ss)=>rtpset)

Penambahan makroRTP session _session untuk pengaturan _set.

ss: set (obyek SessionSet)


rtpsession : sesi RTP

4. #define session_set_is_set_set (ss,rtpsession) ORTP_FD_ISSET


((rtpsession)=>mask_pos, & (ss)=>rtpset)

Makro test jika _session adalah bagian dari _set. 1 jika true, 0 false.

ss : set (Session object)


rtpsession : sesi RTP

5. #define session_set_clr (ss, rtpsession) ORTP_FD_CLR


((rtpsession)=>mask_pos, & (ss)=>rtpset)

Mengahapus _session dari _set

ss : pengaturan sesi
rtpsession : sesi RTP
43

6. int session_set_select (SessionSet *recvs, SessionSet


*sends, SessionSet *errors);

Fungsi ini mirip sebagai libc fungsi select (), tetapi dilakukan pada
RtpSession bukan file descriptor. Session_set_select () menunda
proses komunikasi sampai beberapa peristiwa terjadi di salah satu
dari tiga set argumen. Dua set dapat NULL. Argumen pertama recvs
diartikan sebagai kumpulan RtpSession yang menunggu untuk
menerima peristiwa: buffer baru (mungkin kosong) ada pada satu
atau lebih pengaturan sesi, atau menerima operasi terakhir dengan
rtp_session_recv_with_ts () akan selesai jika berada dalam modus
blocking. Argumen kedua ditafsirkan sebagai satu pengaturan
RtpSession yang menunggu untuk mengirim peristiwa, contoh
komunikasi terakhir rtp_session_send_with_ts () pada sesi itu akan
selesai jika berada dalam modus blocking.

Ketika beberapa peristiwa terjadi pada beberapa pengaturan,


kemudian kembali ke fungsi dan pengaturan berubah untuk
menunjukkan sesi di mana peristiwa terjadi. Sesi dapat ditambahkan
ke pengaturan menggunakan session_set_set (), sesi harus diuji
untuk menjadi bagian dari serangkaian menggunakan
session_set_is_set ().

7. voidsession_set_destroy (SessionSet *set);

set : pengaturan sesi SessionSet Destroys

d. Telephone events (RFC2833).

2.8 Demultiplexing
Pada jaringan protokol biasanya memerlukan demultiplexing
hirarkis untuk mengirimkan paket sampai ke tujuan. Sebagai contoh,
ketika sebuah paket tiba di adapter ethernet, maka ethernet akan
menentukan apakah jenis paket ini, misalnya paket IP atau sebuah
paket ARP. Jika sebuah paket IP, maka perlu mencari lagi header apa
yang di tambahkan pada paket tersebut, untuk menentukan apakah
sebuah paket tersebut UDP atau TCP dan seterusnya. Penggolongan
paket (classifier paket) dapat dilustrasikan pada Gambar 2.14.
44

Gambar 2.14. Classifier paket

Ethernet (ETH) mempekerjakan sebuah classifier untuk


memutuskan apakah sebuah paket harus diproses menggunakan jalur p1,
p2 atau p3. Sehingga classifier bukanlah suatu driver khusus untuk
jaringan, tetapi sebalinya adalah suatu mekanisme yang dapat digunakan
oleh setiap modul yang perlu membuat keputusan routing dinamis
berdasarkan isi data dalam suatu komunikasi.

Demultiplexer mengambil data dari sebuah input kanal dan


membagi data tersebut menjadi beberapa output, dimana pada setiap
output yang akan ditransferkan ditentukan oleh informasi yang
dikandung oleh paket tersebut atau dapat diilustrasikan seperti Gambar
2.15. Data yang dikeluarkan di output sama seperti urutan yang
diterima oleh input, terlepas dari saluran, paket, frame atau sinyal yang
lain.

Gambar 2.15. Demultiplexer


 

BAB III
PERANCANGAN SISTEM
Pada bab perencanaan sistem ini, akan dijelaskan tentang
langkah pembuatan sistem, bahan dan alat yang diperlukan, cara kerja
sistem, installasi, tempat dan waktu pengerjaan.

3.1 Deskripsi Umum Sistem


Secara umum proyek akhir ini dibuat sesuai dengan Gambar 3.1.
Setelah data diterima oleh ethernet, proses de-encapsulasi dilakukan
oleh library oRTP. Proses demultiplexing dilakukan pada RTP de-
encapsulasi. Demultiplexing dilakukan untuk memisahkan bagian dari
satu video ke video yang lain dengan cara melihat timestamp yang telah
ditambahkan oleh library oRTP dibagian multiplexer-nya.

C 3.3
C 3.2
C 3.1

C 2.3
C 2.2
C 2.1

C 1.3
C 1.2
C 1.1
C 4.3
C 4.2
C 4.1

 
Gambar 3.1 Blok diagram de-encapsulator

3.1.1 Tahap Perencanaan Flowchart


Pembuatan proyek akhir ini dimulai dari pemrograman untuk
mendesain algoritma yang diimplementasikan untuk proses de-

45 
 
46

enkapsulasi paket RTP. Pada tujuan, bit stream ini kemudian diubah
menjadi frame. Header frame kemudian dilepas (de-enkapsulasi ethernet
frame) dan dikirim ke layer-3 sebagai paket. Paket selanjutnya melepas
IP header (De-enkapsulai IP header) dan mengirim data tersebut ke
layer-4 sebagai segment. Segment kemudian melepas header (de-
enkapsulasi UDP header) dan memberikan data ke layer-5,6,7 sebagai
paket RTP. Paket RTP yang diterima akan dipisah-pisah menurut video
sumbernya. Flowchart sistem ditunjukan pada Gambar 3.2.

 
 
Gambar 3.2 Flowchart sistem
47

3.2 Perencanaan Perangkat Pendukung


Pembuatan proyek akhir ini menggunakan sistem multi-source data
streaming video, dalam pembuatanya dibutuhkan beberapa peralatan
pendukung meliputi :
1. Perancangan perangkat keras (Hardware)
2. Perancangan perangkat lunak (Software)

3.2.1 Perancangan Perangkat Keras (Hardware)


Peralatan hardware yang akan digunakan adalah 3 komputer,
yang digunakan sebagai multiplexer, demultiplexer dan displayer serta
kabel RJ 45.

1) PC Multiplexer
Menggabungkan dan mengenkapsulasi data streaming multi
source menjadi paket RTP.
2) PC Demultiplexer
Mendekapsulasi dan memisahkan data streaming multi source
menurut bagian-bagian video yang sesuai, yang kemudian
dikirim ke terminal access (displayer).
3) PC terminal access (Displayer)
Menampilkan data video.
4) Kabel RJ45
Kabel RJ 45 / UTP digunakan untuk menghubungkan satu
komputer dengan komputer yang lain.

3.2.2 Perancangan Perangkat Lunak (Software)


Selain peralatan hardware, diperlukan juga peralatan software
yang mendukung pembuatan sistem diantaranya adalah :

a) Sistem Operasi Linux Debian


Sistem operasi yang digunakan untuk transmisi data streaming.
b) oRTP yang digunakan sebagai library protokol RTP.
c) Wireshark digunakan sebagai tool untuk mengamati, meng-
capture dan menganalisa paket streaming yang dikirimkan
multiplexer maupun demultiplexer.

3.3 Implementasi Sistem


Pada implementasi transmisi paket RTP ini dilakukan proses
instalasi perangkat pendukung yang terbagi menjadi dua yaitu :
1. Instalasi perangkat keras (hardware)
48

Merupakan proses penyusunan komponen – komponen


multiplexer, demultiplexer dan terminal access.
2. Instalasi perangkat lunak (software)
Merupakan proses penginstalan software yang dibutuhkan pada
komputer multiplexer, demultiplexer dan terminal access untuk
mendukung terbentuknya sistem secara keseluruhan.

3.3.1 Instalasi Perangkat Keras (Hardware)


Topologi transmisi paket RTP dibangun sebuah multiplexer
RTP yang terhubung dengan demultiplexer. Pada multiplexer dan
demultiplexer diinstall library RTP yaitu ortp-0.16.3.tar.gz. Selanjutnya
demultiplexer terhubung pada terminal access yang diinstall Java Media
Framework Desain sistem seperti ditunjukkan pada Gambar 3.3.

 
Gambar 3.3 Desain sistem

3.3.2 Instalasi perangkat lunak (software)


Pada proyek akhir ini, instalasi perangkat lunak diperlukan
untuk mendukung aplikasi sistem transmisi paket RTP yang dibuat.

3.3.2.1 Instalasi ortp-0.16.3


oRTP merupakan library yang digunakan untuk
mentransmisikan paket Real Time Protocol (RFC 3550) yang dijalankan
di debian kernel 2.6.26-2-686. Library ortp-0.16.3 dapat didownload di
alamat http://ftp.twaren.net/Unix/NonGNU/linphone/ortp/sources/.

1. Ekstrak ortp-0.16.3.tar.gz
# tar -xvf ortp-0.16.3.tar.gz

2. Pindah direktori ke ortp-0.16.3


# cd ortp-0.16.3
49

3. Konfigurasi paket pada sistem. Hasil setelah konfigurasi paket


akan tampak seperti Gambar 3.4.
# ./configure 

Gambar 3.4 Konfigurasi oRTP 0.16.3


4. Kompile paket. Hasil setelah kompile paket akan tampak
seperti Gambar 3.5.
#make 

Gambar 3.5 Kompile paket oRTP 0.16.3


50

5. Menjalankan contoh program di dalam ortp-0.16.3 oleh ortp.


Hasil setelah menjalankan contoh program dalam ortp-0.16.3
akan tampak seperti Gambar 3.6.

# make check 

 
 
Gambar 3.6 Menjalankan contoh program oRTP 0.16.3

6. Install program dan beberapa file data pendukung. Hasil


installasi program dan file pendukungnya akan tampak seperti
Gambar 3.7.

# make install 
51

Gambar 3.7 Install program dan file pendukung oRTP 0.16.3

3.3.2.2 Instalasi dan Konfigurasi Wireshark


Penggunaan Wireshark pada proyek akhir ini diperuntukan
untuk menganalisa jenis dan cara komunikasi protokol real-time paket
stream. Berikut adalah cara instalasi dan konfigurasinya :

1. Download dan install paket wireshark dengan perintah :


# apt-get install wireshark.

2. Buka wireshark. Tampilan wireshark seperti Gambar 3.8 :

Gambar 3.8 Wireshark


52

3. Pilih device capture interfaces yang digunakan. Tampilan menu


capture interface seperti Gambar 3.9.

Gambar 3.9. Menu capture interface

4. Hasil packet capture yang dilakukan oleh wireshark. Tampilan


capture oleh wireshark seperti Gambar 3.10 dan Gambar 3.11.

Gambar 3.10. Analisa protokol streaming menggunakan


wireshark
53

Gambar 3.11. Hasil packet capture oleh wireshark

3.3.2.3 Kompile dan Jalankan oRTP 0.16.3

1) Kompile source code


# gcc -o myprogram `pkg-config --
cflags ortp` myprogram.c \ `pkg-
config --libs ortp`

2) Jalankan program
# ./rtprecv4 9999

Keterangan :
9999 adalah nomor yang digunakan untuk menerima paket
RTP yang dikirimkan oleh multiplexer.

3.4 Tempat dan Waktu Pelaksanaan


Perancangan dan pembuatan implementasi RTP packet-chunk de-
encapsulator data AV stream format RTP sebagai terminal access multi-
ource yang telah dibuat, dilakukan pada:
54

Tempat :Laboratorium Dasar Telekomunikasi Politeknik Elektronika


Negeri Surabaya (PENS-ITS)
Waktu : Maret 2010 - Juli 2010

3.5 Metode Pengukuran Parameter QoS


Pada perancangan sistem ini dimulai dengan analisa kualitas video
yang dikirimkan oleh multiplexer yang nantinya diterima oleh
demultiplexer. Pengambilan data dilakukan dengan langkah sebagai
berikut :
1. Multiplexer mingirimkan paket RTP yang kemudian diterima
demultiplexer.
2. Demultiplexer menerima paket RTP dari multiplexer yang
kemudian mengirimkan kembali paket RTP yang telah di
demultiplexing ke displayer.
3. Pengujian real-time protokol dilakukan dengan menganalisa
proses kerja protokol saat pengiriman stream video dengan tool
wireshark.

Parameter QoS yang diukur untuk transmisi paket RTP meliputi


delay, jitter, throughput, dan packet loss.
Alat pemantau trafik jaringan RTP yang digunakan untuk
mengukur parameter QoS diatas adalah software wireshark yang
berjalan di atas linux. Software ini dipasang di sisi demultiplexer untuk
melihat trafik paket yang diterima oleh demultiplxer yang nantinya akan
dijadikan dasar analisa penelitian ini.
 

BAB IV
IMPLEMENTASI DAN PENGUJIAN

Pengujian merupakan salah satu langkah penting yang harus


dilakukan untuk mengetahui apakah sistem yang dibuat telah sesuai
dengan apa yang direncanakan. Hal ini dapat dilihat dari hasil-hasil yang
dicapai selama pengujian sistem.

4.1 Pengujian Demultiplexing Pengiriman Packet RTP


Pada pengujian demultiplexing ini, multiplexer mengirimkan 4
paket RTP secara berurutan yang berasal dari video yang berbeda-beda.
Setelah keempat video diterima oleh demultiplexer maka keempat paket
tersebut dipisah dan dikirimkan lagi ke displayer dengan nomor port
berbeda-beda. Analisa dalam pengujian ini menggunakan tool wireshark
untuk melihat apakah paket yang diterima dengan paket yang dikirim
memiliki ujung-ujung yang sama. Gambar 4.1 sampai 4.8 adalah hasil
capture oleh wireshark :

1. Paket pertama yang diterima oleh demultiplexer :

Gambar 4.1 Capture paket pertama yang diterima demultiplexer

Paket yang dikirimkan kembali ke terminal access

Gambar 4.2 Capture paket pertama yang dikirim demultiplexer

55 
 
56

2. Paket kedua yang diterima oleh demultiplexer :

Gambar 4.3 Capture paket kedua yang diterima demultiplexer

Paket yang dikirimkan kembali ke terminal access

Gambar 4.4 Capture paket kedua yang dikirim demultiplexer

3. Paket ketiga yang diterima oleh demultiplexer :

Gambar 4.5 Capture paket ketiga yang diterima demultiplexer


57

Paket yang dikirimkan kembali ke terminal access

Gambar 4.6 Capture paket ketiga yang dikirim demultiplexer

4. Paket ketiga yang diterima oleh demultiplexer :

Gambar 4.7 Capture paket keempat yang diterima demultiplexer

Paket yang dikirimkan kembali ke terminal access

Gambar 4.8 Capture paket keempat yang dikirim demultiplexer

Dengan melihat Gambar 4.1 sampai 4.8 diatas maka demultiplexer


paket bisa berjalan dengan baik, karena demultiplexer dapat
memisahkan ujung-ujung dari payload tanpa mengurangi isi payload itu
58

sendiri. Hal ini dapat dibuktikan dengan melihat ujung yang dilingkari
garis merah dari payload, disini terlihat bahwa ujung akhir dari setiap
payload saat diterima maupun dikirim selalu sama. Sedangkan untuk
ujung atas yang tidak dilingkari garis merah terlihat berbeda. Perubahan
ini terjadi karena header paket yang ditambahkan oleh multiplexer
dihapus dan diganti dengan yang baru oleh demultiplexer (diisi dengan
timestamp dan sequence number yang berbeda).

4.2 Analisa MTU dan Penambahan RTP Header


Pengujian ini bertujuan untuk mengetahui data/payload maksimal
yang dapat dikirimkan supaya diterima dengan baik sesampainya di
tujuan. Maximum Transmission Unit (MTU) untuk paket RTP adalah
data/payload ditambah 12 bytes untuk RTP header. Analisa MTU bisa
dilakukan dengan mengubah-ubah ukuran buffer, karena dengan
mengubah ukuran buffer maka paket yang dikirimkan juga ikut berubah.

Tabel 4.1 Pengaruh ukuran data, RTP header dan paket yang dikirimkan
terhadap kondisi video
Ukuran Ukuran Data RTP header Paket kirim
Kondisi Video
Buffer (Bytes) (Bytes) (Bytes)
160 160 12 172 Baik
320 320 12 332 Baik
480 480 12 492 Baik
640 640 12 652 Baik
800 800 12 812 Baik
960 960 12 972 Baik
1120 1120 12 1132 Baik
1280 1280 12 1292 Baik
1440 1440 12 1452 Baik
1488 1488 12 1500 Baik
1489 1489 12 1501 Rusak
1600 1600 12 1612 Rusak

Data Tabel 4.1 diatas menunjukkan bahwa pada jaringan berbasis


teknologi ethernet, ukuran MTU maksimum adalah 1500 byte. Dari
1500 byte tersebut terdiri dari 1488 byte payload serta penambahan 12
byte untuk RTP header. Jika paket yang dikirimkan melebihi MTU
maka data yang diterima oleh client akan mengalami kerusakan
meskipun itu lebih 1 byte saja.
59

Menentukan ukuran buffer yang digunakan tergantung pada ukuran


file video yang dirimkan. Semakin besar ukuran file video atau semakin
besar resolusi video tersebut maka ukuran buffer yang digunakan harus
semakin besar. Hal ini dilakukan untuk mengatasi efek video terputus-
putus sesampainya diterima di displayer.

Gambar 4.9 Video dengan ukuran paket kirim 172 bytes


Gambar 4.9 menunjukkan gambar video yang dikirimkan dengan
ukuran buffer 160 bytes, karena ditambah header RTP sebesar 12 bytes
maka paket yang dikirimkan menjadi 172 bytes.

Gambar 4.10 Video dengan ukuran paket kirim 332 bytes


60

Gambar 4.10 menunjukkan gambar video yang dikirimkan dengan


ukuran buffer 320 bytes, karena ditambah header RTP sebesar 12 bytes
maka paket yang dikirimkan menjadi 332 bytes.

Gambar 4.11 Video dengan ukuran paket kirim 492 bytes

Gambar 4.11 menunjukkan gambar video yang dikirimkan dengan


ukuran buffer 480 bytes, karena ditambah header RTP sebesar 12 bytes
maka paket yang dikirimkan menjadi 492 bytes.

Gambar 4.12 Video dengan ukuran paket kirim 652 bytes


61

Gambar 4.12 menunjukkan gambar video yang dikirimkan dengan


ukuran buffer 640 bytes, karena ditambah header RTP sebesar 12 bytes
maka paket yang dikirimkan menjadi 652 bytes.

Gambar 4.13 Video dengan ukuran paket kirim 812 bytes

Gambar 4.13 menunjukkan gambar video yang dikirimkan dengan


ukuran buffer 800 bytes, karena ditambah header RTP sebesar 12 bytes
maka paket yang dikirimkan menjadi 812 bytes.

Gambar 4.14 Video dengan ukuran paket kirim 972 bytes


62

Gambar 4.14 menunjukkan gambar video yang dikirimkan dengan


ukuran buffer 960 bytes, karena ditambah header RTP sebesar 12 bytes
maka paket yang dikirimkan menjadi 972 bytes.

Gambar 4.15 Video dengan ukuran paket kirim 1132 bytes

Gambar 4.15 menunjukkan gambar video yang dikirimkan dengan


ukuran buffer 1120 bytes, karena ditambah header RTP sebesar 12 bytes
maka paket yang dikirimkan menjadi 1132 bytes.

Gambar 4.16 Video dengan ukuran paket kirim 1292 bytes


63

Gambar 4.16 menunjukkan gambar video yang dikirimkan dengan


ukuran buffer 1280 bytes, karena ditambah header RTP sebesar 12 bytes
maka paket yang dikirimkan menjadi 1292 bytes.

Gambar 4.17 Video dengan ukuran paket kirim 1452 bytes

Gambar 4.17 menunjukkan gambar video yang dikirimkan dengan


ukuran buffer 1440 bytes, karena ditambah header RTP sebesar 12 bytes
maka paket yang dikirimkan menjadi 1452 bytes.

Gambar 4.18 Video dengan ukuran paket kirim 1500 bytes

Gambar 4.18 menunjukkan gambar video yang dikirimkan dengan


ukuran buffer 1488 bytes, karena ditambah header RTP sebesar 12 bytes
maka paket yang dikirimkan menjadi 1500 bytes.
64

Gambar 4.19 Video dengan ukuran paket kirim 1501 bytes

Gambar 4.19 menunjukkan gambar video yang dikirimkan dengan


ukuran buffer 1489 bytes, karena ditambah header RTP sebesar 12 bytes
maka paket yang dikirimkan menjadi 1501 bytes.

4.3 Pengukuran Time Eksekusi Demultiplexer


Time eksekusi merupakan sesuatu yang penting dan sangat
dipertimbangkan dalam penyusunan suatu algoritma yang digunakan
dalam suatu program. Algoritma yang tercepat dan tepat merupakan
pilihan yang tepat dalam perancangan suatu program. Sehingga dalam
program perancangan demultiplexer ini, time eksekusi merupakan faktor
yang sangat diperhitungkan untuk mendapatkan transmisi data yang
benar-benar real time. Tabel 4.2 adalah hasil dari time eksekusi
demultiplexer dalam durasi 1 menit:

Tabel 4.2 Time eksekusi pada demultiplexer


Di Terima Kirim Pada
Pengukuran Time Eksekusi
Detik ke- Detik ke-
1 3.154258 3.206803 0.052545
2 4.154334 4.205787 0.051453
3 5.154363 5.205804 0.051441
4 6.154438 6.205822 0.051384
5 7.154465 7.206817 0.052352
6 8.154569 8.205768 0.051199
7 9.154585 9.205753 0.051168
65

Tabel 4.2 Time eksekusi pada demultiplexer (lanjutan)


Di Terima Kirim Pada
Pengukuran Time Eksekusi
Detik ke- Detik ke-
8 10.154657 10.206798 0.052141
9 11.154695 11.206803 0.052108
10 12.154757 12.202815 0.048058
11 13.154809 13.205782 0.050973
12 14.154837 14.206632 0.051795
13 15.154942 15.205809 0.050867
14 16.154917 16.206208 0.051291
15 17.155017 17.205797 0.05078
16 18.155054 18.206619 0.051565
17 19.155128 19.20682 0.051692
18 20.15517 20.206802 0.051632
19 21.155239 21.206843 0.051604
20 22.155278 22.205624 0.050346
21 23.155344 23.205782 0.050438
22 24.155369 24.215352 0.059983
23 25.155436 25.218847 0.063411
24 26.155455 26.226191 0.070736
25 27.155509 27.198611 0.043102
26 28.168605 28.198847 0.030242
27 29.155661 29.198837 0.043176
28 30.155717 30.20682 0.051103
29 31.155811 31.20681 0.050999
30 32.155819 32.205783 0.049964
31 33.155875 33.205766 0.049891
32 34.155914 34.206825 0.050911
33 35.155983 35.205754 0.049771
34 36.156635 36.206835 0.0502
35 37.156074 37.206802 0.050728
36 38.156138 38.20579 0.049652
37 39.156196 39.205769 0.049573
38 40.156217 40.206599 0.050382
39 41.156285 41.205818 0.049533
66

Tabel 4.2 Time eksekusi pada demultiplexer (lanjutan)


Di Terima Kirim Pada
Pengukuran Time Eksekusi
Detik ke- Detik ke-
40 42.156342 42.209624 0.053282
41 43.156406 43.205751 0.049345
42 44.156446 44.205756 0.04931
43 45.1565 45.205771 0.049271
44 46.156566 46.206825 0.050259
45 47.156621 47.205757 0.049136
46 48.156688 48.20584 0.049152
47 49.156725 49.205815 0.04909
48 50.156768 50.205819 0.049051
49 51.156835 51.205771 0.048936
50 52.156875 52.205757 0.048882
51 53.156931 53.205773 0.048842
52 54.156989 54.206872 0.049883
53 55.157044 55.205822 0.048778
54 56.157078 56.206801 0.049723
55 57.157133 57.206805 0.049672
56 58.157223 58.205736 0.048513
57 59.157263 59.205819 0.048556
58 60.160352 60.206821 0.046469
59 61.15737 61.206826 0.049456
60 62.157407 62.205706 0.048299
rata -rata 0.050401567

Dari data Tabel 4.2 maka dapat dibuat grafik seperti Gambar 4.20.
Dari kedua data tersebut diperoleh informasi bahwa maksimal waktu
yang dibutuhkan untuk melakukan demultiplexing adalah 0.070736
milidetik, sedangkan waktu minimal yang dibutuhkan adalah 0.030242
milidetik. Sedangkan rata-rata time eksekusi dalam interval 1 menit
adalah 0.050401567 milidetik. Karena time eksekusi masih di bawah 150
milidetik yang merupakan delay maksimal untuk QoS audio/video
streaming, maka algoritma yang digunakan sudah memenuhi untuk QoS
Audio/Video Streaming.
67

Gambar 4.20 Grafik nilai time eksekusi pada demultiplexer

4.4 Pengukuran QoS Audio/Video Streaming


Pengukuran pada pengiriman paket RTP jaringan multi-source ini
merupakan penjabaran dari nilai parameter QoS hasil pengukuran dari
paket yang diterima dari multiplexer maupun paket yang dikirimkan
demultiplexer ke displayer. Parameter-parameter QoS yang diukur
meliputi nilai packet loss, delay, jitter dan throughput untuk sesi
komunikasi peer to peer dan jaringan student PENS. Topologi
komunikasi peer to peer ditunjukkan pada Gambar 4.21 sedangkan
topologi komunikasi jaringan student PENS ditunjukkan pada Gambar
4.22.

Terminal Access
Multiplexer Demultiplexer
 
Gambar 4.21 Topologi sesi komunikasi peer to peer
68

Server Student
PENS

Network

Demultiplexer Terminal Access

Gambar 4.22 Topologi sesi komunikasi student PENS

4.4.1 Packet Loss


a. Komunikasi Peer to Peer
Packet loss merupakan hilangnya paket data dalam transmisi data.
Pengukuran dilakukan dengan mengambil data pada sesi komunikasi
antara demultiplexer dengan multiplexer pada port 9999 dan komunikasi
antara demultiplexer dengan displayer pada port 5000, port 5001, port
5002 dan port 5003. Pada komunikasi tersebut data yang diperoleh
sesuai dengan Tabel 4.3 :

Tabel 4.3 Packet loss pada demultiplexer untuk sesi komunikasi peer to
peer
Pengukur- Port Port Port Port Port
an 9999(%) 5000(%) 5001(%) 5002(%) 5003(%)
1 0 0 0 0 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
69

Tabel 4.3 Packet loss pada demultiplexer untuk sesi komunikasi peer
to peer (lanjutan)
Pengukur- Port Port Port Port Port
an 9999(%) 5000(%) 5001(%) 5002(%) 5003(%)
6 0 0 0 0 0
7 0 0 0 0 0
8 0 0 0 0 0
9 0 0 0 0 0
10 0 0 0 0 0
rata - rata 0 0 0 0 0

Gambar 4.23 Grafik nilai packet loss pada demultiplexer untuk


komunikasi peer to peer

Berdasarkan Tabel 4.3 dan Gambar 4.23, packet loss dalam


komunikasi peer to peer dapat dikategorikan komunikasi yang sangat
bagus. Dapat dikategorikan sangat bagus apabila packet loss yang terjadi
0%. Hal ini terlihat pada data diatas, pada masing – masing port terjadi
packet loss 0%. Packet loss 0% bisa terjadi karena jalur yang digunakan
dalam komunikasi dalam status tidak sibuk atau dengan kata lain tidak
ada pembebanan paket data yang tinggi.
70

b. Komunikasi Jaringan Student PENS


Sama seperti pengukuran – pengukuran sebelumnya, pengukuran
pada komunikasi antar server juga dilakukan pengamatan nilai packet
loss yang terjadi.

Tabel 4.4 Packet loss pada demultiplexer untuk sesi komunikasi


jaringan student PENS
Pengukur- Port Port Port Port Port
an 9999(%) 5000(%) 5001(%) 5002(%) 5003(%)
1 0 0 0 0 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
8 0 0 0 0 0
9 0 0 0 0 0
10 0 0 0 0 0
rata - rata 0 0 0 0 0

Gambar 4.24 Grafik nilai packet loss pada demultiplexer untuk


komunikasi student PENS
71

Berdasarkan Tabel 4.4 maka dapat dibuat grafik seperti Gambar


4.24, yang dapat disimpulkan bahwa nilai packet loss pada komunikasi
jaringan student PENS masih memenuhi standar ITU-T
Recommendation G.1010, karena packet loss yang terjadi sebesar 0%.
Hal ini dapat terjadi karena dalam komunikasi UDP satu arah (one way),
sangat kecil kemungkinan terjadinya collision dan antrian paket yang
mengakibatkan ada paket yang hilang.

4.4.2 Delay
a. Komunikasi Peer to Peer
Komunikasi pada port 9999 merupakan pengiriman paket RTP yang
dilakukan oleh multiplexer dan kemudian diterima oleh demultiplexer.
Paket yang dikirimkan oleh multiplexer ini merupakan paket RTP yang
telah di-multiplexing. Sedangkan komunikasi pada port 5000 merupakan
pengiriman paket RTP ke displayer oleh demultiplexer setelah paket
dilakukan demultiplexing.

Tabel 4.5 Delay paket RTP menuju port 5000 untuk sesi komunikasi
peer to peer
Delay Port Delay Port Total Delay ke Port
Pengukuran
9999 (ms) 5000 (ms) 5000 (ms)
1 10.00041 39.98681 49.98722
2 10.00004 39.98636 49.9864
3 9.999704 39.98631 49.986014
4 10.00003 39.98432 49.98435
5 9.999869 39.98634 49.986209
6 10.00009 39.98804 49.98813
7 9.999857 39.98808 49.987937
8 10.00007 39.98641 49.98648
9 9.998864 39.98025 49.979114
10 10.00033 39.98643 49.98676
rata - rata 9.9999264 39.985935 49.9858614
72

Gambar 4.25 Grafik nilai delay paket RTP menuju port 5000 untuk
komunikasi peer to peer
Dari Tabel 4.5 maka dapat dibuat grafik seperti Gambar 4.25 yang,
menampilkan delay paket yang dikirimkan menuju displayer dari video
pertama.

Tabel 4.6 Delay paket RTP menuju port 5001 untuk sesi komunikasi
peer to peer
Delay Port Delay Port Total Delay ke Port
Pengukuran
9999 (ms) 5001 (ms) 5001 (ms)
1 10.00041 39.98643 49.98684
2 10.00004 39.98636 49.9864
3 9.999704 39.98636 49.986064
4 10.00003 39.98636 49.98639
5 9.999869 39.98771 49.987579
6 10.00009 39.98681 49.9869
7 9.999857 39.98648 49.986337
8 10.00007 39.98777 49.98784
9 9.998864 39.98407 49.982934
10 10.00033 39.98648 49.98681
rata - rata 9.9999264 39.986483 49.9864094
73

Gambar 4.26 Grafik nilai delay paket RTP menuju port 5001 untuk
komunikasi Peer to Peer
Dari Tabel 4.6 maka dapat dibuat grafik seperti Gambar 4.26 yang,
menampilkan delay paket yang dikirimkan menuju displayer dari video
kedua.
Tabel 4.7 Delay paket RTP menuju port 5002 untuk sesi komunikasi
peer to peer
Delay Port Delay Port Total Delay ke Port
Pengukuran
9999 (ms) 5002 (ms) 5002 (ms)
1 10.00041 39.98636 49.98677
2 10.00004 39.98108 49.98112
3 9.999704 39.98674 49.986444
4 10.00003 39.9866 49.98663
5 9.999869 39.98654 49.986409
6 10.00009 39.9868 49.98689
7 9.999857 39.98809 49.987947
8 10.00007 39.98647 49.98654
9 9.998864 39.98684 49.985704
10 10.00033 39.98635 49.98668
rata - rata 9.9999264 39.986187 49.986113
74

Gambar 4.27 Grafik nilai delay paket RTP menuju Port 5002 untuk
komunikasi peer to peer

Dari Tabel 4.7 maka dapat dibuat grafik seperti Gambar 4.27 yang,
menampilkan delay paket yang dikirimkan menuju displayer dari video
ketiga.
Tabel 4.8 Delay paket RTP menuju port 5003 untuk sesi komunikasi
peer to peer
Delay Port Delay Port Total Delay ke Port
Pengukuran
9999 (ms) 5003 (ms) 5003 (ms)
1 10.00041 39.98638 49.98679
2 10.00004 39.98504 49.98508
3 9.999704 39.98628 49.985984
4 10.00003 39.9803 49.98033
5 9.999869 39.98682 49.986689
6 10.00009 39.98653 49.98662
7 9.999857 39.98645 49.986307
8 10.00007 39.98781 49.98788
9 9.998864 39.98677 49.985634
10 10.00033 39.9865 49.98683
rata - rata 9.9999264 39.985888 49.985814
75

Gambar 4.28 Grafik nilai delay paket RTP menuju port 5003 untuk
komunikasi peer to peer

Dari Tabel 4.8 maka dapat dibuat grafik seperti Gambar 4.28 yang
menampilkan delay paket yang dikirimkan menuju displayer dari video
keempat.
Nilai delay yang jadi bahan analisa ini merupakan rata-rata selisih
waktu saat paket mulai dikirimkan hingga diterima client dalam durasi
pengukuran 2 menit.
Pengukuran yang dilakukan dalam proses komunikasi ini
menggunakan software wireshark yang diletakkan pada demultiplexer
(penerima). Berdasarkan data diatas dapat diamati bahwa total delay
tertinggi berada pada pengukuran keenam pada port 5000, sebesar
49.98813 milidetik sedangkan total delay terendah pada pengukuran
kesembilan pada port 5000 sebesar 49.979114 milidetik. Sehingga pada
sistem pengiriman paket RTP multi-source ini, waktu yang dibutuhkan
dari multiplexer mengirimkan paket sampai diterima oleh displayer
adalah nilai total delay dalam setiap port ditambah dengan time eksekusi
yang dilakukan demultiplexer untuk memecah video sesuai sumber
video. Berikut adalah rata-rata waktu yang dibutuhkan sejak multiplexer
mengirimkan paket untuk RTP untuk sampai di displayer di setiap port :
76

Port 5000 :

X = Total Delay + Time Eksekusi

= 49.9858614 + 0.050401567 = 50.036263 milidetik

Port 5001 :

X = Total Delay + Time Eksekusi

= 49.9864094 + 0.050401567 = 50.036811 milidetik

Port 5002 :

X = Total Delay + Time Eksekusi

= 49.986113 + 0.050401567 = 50.036515 milidetik

Port 5003 :

X = Total Delay + Time Eksekusi

= 49.985814 + 0.050401567 = 50.036216 milidetik

Keterangan :

X = Waktu yang dibutuhkan untuk mengirimkan paket RTP, sejak


multiplexer mengirimkan paket untuk sampai ke displayer.

Standarisasi delay streaming video satu arah (one way) menurut


ITU-T G.1010 adalah lebih kecil 150 milidetik. Pada perhitungan diatas,
terlihat jelas bahwa pada sistem ini rata-rata delay yang terjadi sebesar
50 milidetik. Karena rata-rata delay yang terjadi sebesar 50 milidetik,
maka pada sistem ini dapat dikatakan masih layak.

b. Komunikasi Jaringan Student PENS


Pengukuran delay juga dilakukan pada sesi komunikasi jaringan
student PENS. Dalam sesi ini komunikasi ini, paket yang dikirimkan ke
77

displayer dilewatkan melalui jaringan student PENS yang mempunyai


trafik yang tinggi. Karena dalam jaringan ini bukan penulis saja yang
menggunakan jalur ini, tetapi juga mahasiswa-mahasiswa PENS yang
lain.

Tabel 4.9 Delay paket RTP menuju port 5000 untuk sesi komunikasi
jaringan student PENS
Delay Port Delay Port Total Delay ke Port
Pengukuran
9999 (ms) 5000 (ms) 5000 (ms)
1 9.999196 40.23982 50.239016
2 9.999133 39.33962 49.338753
3 9.998967 40.93987 50.938837
4 9.999037 40.03992 50.038957
5 9.999074 40.23982 50.238894
6 9.999396 40.22983 50.229226
7 9.99945 40.75984 50.75929
8 9.999196 40.33882 50.338016
9 10.01456 40.29882 50.31338
10 10.02498 40.98978 51.01476
rata - rata 10.003299 40.341614 50.344913
78

Gambar 4.29 Grafik nilai delay paket RTP menuju port 5000 untuk
komunikasi jaringan student PENS
Dari Tabel 4.9 maka dapat dibuat grafik seperti Gambar 4.29, yang
menampilkan delay paket yang dikirimkan menuju displayer dari video
pertama.
Tabel 4.10 Delay paket RTP menuju port 5001 untuk sesi komunikasi
jaringan student PENS
Delay Port Delay Port Total Delay ke Port
Pengukuran
9999 (ms) 5001 (ms) 5001 (ms)
1 9.999196 40.82029 50.819486
2 9.999133 40.77115 50.770283
3 9.998967 40.37782 50.376787
4 9.999037 40.77314 50.772177
5 9.999074 40.37125 50.370324
6 9.999396 39.77335 49.772746
7 9.99945 40.27125 50.2707
8 9.999196 40.76216 50.761356
9 10.01456 40.74114 50.7557
10 10.02498 39.86308 49.88806
rata - rata 10.003299 40.452463 50.455762
79

Gambar 4.30 Grafik nilai delay paket RTP menuju port 5001 untuk
komunikasi jaringan student PENS
Dari Tabel 4.10 maka dapat dibuat grafik seperti Gambar 4.30, yang
menampilkan delay paket yang dikirimkan menuju displayer dari video
kedua.
Tabel 4.11 Delay paket RTP menuju port 5002 untuk sesi komunikasi
jaringan student PENS
Delay Port Delay Port Total Delay ke Port
Pengukuran 9999 (ms) 5002 (ms) 5002 (ms)
1 9.999196 40.65059 50.649786
2 9.999133 40.55153 50.550663
3 9.998967 40.45152 50.450487
4 9.999037 40.75152 50.750557
5 9.999074 40.45153 50.450604
6 9.999396 40.35154 50.350936
7 9.99945 40.35257 50.35202
8 9.999196 40.45151 50.450706
9 10.01456 40.45019 50.46475
10 10.02498 40.23241 50.25739
rata - rata 10.003299 40.469491 50.47279
80

Gambar 4.31 Grafik nilai delay paket RTP menuju port 5002 untuk
komunikasi jaringan student PENS
Dari Tabel 4.11 maka dapat dibuat grafik seperti Gambar 4.31, yang
menampilkan delay paket yang dikirimkan menuju displayer dari video
ketiga.
Tabel 4.12 Delay paket RTP menuju port 5003 untuk sesi komunikasi
jaringan student PENS
Delay Port Delay Port Total Delay ke Port
Pengukuran
9999 (ms) 5003 (ms) 5003 (ms)
1 9.999196 41.55021 51.549406
2 9.999133 40.16122 50.160353
3 9.998967 40.34024 50.339207
4 9.999037 40.96026 50.959297
5 9.999074 41.86081 51.859884
6 9.999396 41.36323 51.362626
7 9.99945 41.46122 51.46067
8 9.999196 41.16222 51.161416
9 10.01456 40.26132 50.27588
10 10.02498 40.62012 50.6451
rata - rata 10.003299 40.974085 50.977384
81

Gambar 4.32 Grafik nilai delay paket RTP menuju port 5003 untuk
komunikasi jaringan student PENS
Dari Tabel 4.12 maka dapat dibuat grafik seperti Gambar 4.32, yang
menampilkan delay paket yang dikirimkan menuju displayer dari video
keempat.
Data yang diperoleh dari pengukuran delay pada jaringan student
PENS, delay yang diperoleh tidak beda jauh dengan delay pada jaringan
peer to peer.

4.4.3 Jitter
a. Komunikasi Peer to Peer
Pengukuran jitter yang dilakukan tidak berbeda dengan pengukuran
delay, karena pengukuran dilakukan secara bersama – sama. Pada saat
uji coba jitter yang diukur merupakan rata-rata jitter beberapa paket
video yang ter-capture pada wireshark. Hasil pengukuran jitter adalah
pada Tabel 4.13 sebagai berikut :
82

Tabel 4.13 Perbandingan jitter pada masing-masing port untuk


komunikasi peer to peer
Port Port Port Port Port
Pengukuran
9999(ms) 5000(ms) 5001(ms) 5002(ms) 5003(ms)
1 2.078 0.678 0.294 0.739 0.413
2 2.061 0.430 0.912 0.285 0.800
3 2.013 0.633 0.776 0.419 1.161
4 2.014 0.600 0.776 0.625 0.361
5 2.026 0.437 1.034 0.439 0.911
6 2.130 0.688 0.454 0.734 0.614
7 2.101 1.043 0.604 1.005 0.363
8 2.045 0.387 1.058 0.413 0.910
9 2.079 0.438 0.653 0.271 0.966
10 2.036 0.662 0.353 0.630 0.535
rata - rata 2.058 0.600 0.692 0.556 0.703

 
 
Gambar 4.33 Grafik nilai jitter pada demultiplexer untuk komunikasi
peer to peer.
83

Berdasarkan Tabel 4.13 dan gambar Grafik 4.33 dapat diketahui


bahwa nilai jitter pada port 9999 lebih besar dibandingkan ke 4 port
yang lain. Hal ini disebabkan karena pada port 9999 memiliki
pembebanan paket RTP 4 kali lebih besar dibanding dengan 4 port yang
lain. Pada port 9999 mengirimkan paket RTP yang yang berasal dari 4
sumber video, sedangkan port yang lain hanya mengirimkan paket RTP
dari 1 sumber video saja.

b. Komunikasi Jaringan Student PENS


Pengukuran jitter juga dilakukan pada sesi komunikasi jaringan
student PENS, data terdapat pada tabel 4.14.

Tabel 4.14 Perbandingan jitter pada masing-masing port untuk


komunikasi jaringan student PENS
Port Port Port Port Port
Pengukuran 9999(ms) 5000(ms) 5001(ms) 5002(ms) 5003(ms)
1 2.021 0.535 1.509 0.703 0.513
2 2.005 0.595 1.545 1.205 0.658
3 2.027 0.535 1.244 1.013 0.513
4 2.012 0.52 1.245 1.019 0.534
5 2.045 0.505 1.145 1.403 0.523
6 2.055 0.515 1.346 1.359 0.896
7 2.145 0.513 1.448 1.202 0.545
8 2.045 0.513 1.548 0.81 0.522
9 2.045 0.525 1.15 1.029 0.531
10 2.039 0.525 0.501 0.5 0.586
rata - rata 2.044 0.528 1.268 1.0242 0.582
84

Gambar 4.34 Grafik nilai jitter pada demultiplexer untuk komunikasi


jaringan student PENS.

Berdasarkan Tabel 4.14 dan grafik Gambar 4.34, nilai jitter pada
sesi komunikasi jaringan student PENS lebih fluktuatif dibandingkan
dengan sesi komunikasi jaringan peer to peer. Hal ini terjadi karena
pada jaringan student PENS, ada trafik paket data selain sistem ini.
Tinggi rendahnya trafik paket data dalam jaringan tersebut berpengaruh
pada nilai jitter dalam pengiriman paket RTP.

4.4.4 Throughput
a. Komunikasi Peer to Peer
Pada pengukuran throughput ini, data pengukuran diambil dari
paket-paket video yang dibawa oleh protokol RTP melalui UDP.
Dibawah ini merupakan data hasil pengukuran throughput pada
demultiplexer jaringan komunikasi peer to peer :

Tabel 4.15 Perbandingan throughput pada masing-masing port untuk


komunikasi peer to peer
Port Port Port Port Port
Pengukuran 9999 5000 5001 5002 5003
(kbps) (kbps) (kbps) (kbps) (kbps)
1 1187.52 302.51 302.74 302.64 302.57
2 1187.82 302.61 302.7 302.72 302.76
3 1187.49 302.69 302.7 302.79 302.79
85

Tabel 4.15 Perbandingan throughput pada masing-masing port


untuk komunikasi peer to peer (lanjutan)
Port Port Port Port Port
Pengukuran 9999 5000 5001 5002 5003
(kbps) (kbps) (kbps) (kbps) (kbps)
4 1187.54 302.89 302.7 302.76 302.63
5 1187.56 302.81 302.86 302.87 302.78
6 1187.49 302.85 302.60 302.92 302.71
7 1187.51 302.8 302.77 302.79 302.79
8 1187.54 302.76 302.82 302.87 302.76
9 1187.44 302.83 302.8 302.86 302.70
10 1187.4 302.71 302.64 302.71 302.73
rata - rata 1187.53 302.75 302.73 302.79 302.72

Gambar 4.35 Grafik nilai throughput pada demultiplexer untuk


komunikasi peer to peer.

Dari Tabel 4.15 maka dapat dibuat grafik seperti Gambar 4.35, dari
kedua informasi tersebut terlihat bahwa besar throughput untuk paket
video berada pada range 1187.53 kbps pada port 9999, range 302.75
pada port 5000, range 302.73 pada port 5001, range 302.79 pada port
5002 dan 302.72 pada port 5003. Perbedaan mencolok throughput pada
port 9999 dengan port yang lain disebabkan karena pada port 9999 tidak
mengalami pembagian bandwidth dalam satu kanal. Sebaliknya dengan
86

port 5000, port 5001, port 5002 dan port 5003 yang mengalami
pembagian bandwidth dalam satu kanal. Karena ada pembagian kanal
untuk 4 port, mengakibatkan throughput yang diperoleh 4 kali lebih
kecil. Tetapi jumlah nilai throughput dari keempat port tersebut akan
lebih besar dibandingkan dengan nilai throughput port 9999. Hal ini
dikarenakan adanya penambahan header dibawah layer RTP disetiap
port untuk pengiriman paket RTP.

b. Komunikasi Jaringan Student PENS


Pengukuran throughput juga dilakukan untuk sesi komunikasi
jaringan student PENS. Hasil dari pengukuran terdapat pada Tabel 4.16
dan grafik Gambar 4.36.

Tabel 4.16 Perbandingan throughput pada masing-masing port untuk


komunikasi jaringan student PENS
Port Port Port Port Port
Pengukuran 9999 5000 5001 5002 5003
(kbps) (kbps) (kbps) (kbps) (kbps)
1 1195.30 36.74 29.45 37.01 32.51
2 1195.93 32.75 32.68 39.025 34.13
3 1193.61 37.35 32.38 40.01 36.52
4 1193.57 36.73 34.64 35.18 31.12
5 1193.10 35.73 31.64 40.02 31.25
6 1219.19 35.73 34.76 40.01 34.53
7 1193.90 32.65 32.64 40.08 31.12
8 1196 33.35 32.58 40.013 31.15
9 1219.77 33.55 31.64 40.02 31.15
10 1223.6 35.76 34.52 36.50 38.25
rata - rata 1202.48 35.04 32.69 38.79 33.17
87

Gambar 4.36 Grafik nilai throughput pada demultiplexer untuk


komunikasi jaringan student PENS.

Dari Tabel 4.16 dan grafik Gambar 4.36, terlihat bahwa besar
throughput untuk paket video berada pada range 1202.48 kbps pada port
9999, range 35.04 pada port 5000, range 32.69 pada port 5001, range
38.79 pada port 5002 dan 33.17 pada port 5003. Dengan hasil
pengukuran diatas maka dapat disimpulkan bahwa trafik jaringan sangat
berpengaruh pada nilai throughput yang diperoleh. Pada jaringan peer to
peer, throughput yang diperoleh masih layak untuk mengirimkan paket
video streaming sedangkan pada jaringan student PENS pada port 5000,
5001, 5002 dan 5003 yang digunakan untuk komunikasi antara
demultiplexer dan displayer tidak layak untuk mengirimkan paket video
streaming. Hal ini dikarenakan untuk komunikasi antara demultiplexer
dan displayer pada port tersebut memperoleh throughput yang sangat
kecil. Sehingga tidak memungkinkan untuk mengirimkan paket video
dengan kualitas yang baik. Perolehan throughput yang kecil ini,
disebabkan oleh adanya bandwidth limiter yang ditanamkan pada
jaringan student PENS.
88

====Halaman ini sengaja dikosongkan====


 

BAB V
PENUTUP

5.1 Kesimpulan
Setelah dilakukan pengujian sistem ini, maka diperoleh kesimpulan
dan yang diharapkan berguna untuk perbendaharaan ilmu dan teknologi
serta bagi kelanjutan dalam penyempurnaan sistem ini.
Dari hasil pengujian dan analisa diperoleh beberapa kesimpulan
sebagai berikut :
1. Proses demultiplexer bisa dilakukan dengan cara pemisahan
setiap blok paket data dengan ukuran buffer yang sama antara
pengirim dan penerima..
2. Paket yang dikirmkan melebihi MTU sebesar 1500 byte akan
mengalami kerusakan saat diterima receiver.
3. Rata-rata packet loss yang terjadi pada jaringan peer to peer
dan jaringan student PENS adalah 0% yang sudah memenuhi
standar ITU-T Recommendation G.1010 yaitu dibawah 1%.
4. Rata-rata nilai delay yang terukur pada jaringan peer to peer
dan jaringan student PENS adalah 50 milidetik, sehingga sudah
memenuhi standar ITU-T Recommendation G.1010 yaitu
dibawah 150 milidetik.
5. Rata–rata nilai jitter pada jaringan peer to peer dan jaringan
student PENS untuk komunikasi antara multiplexer dan
demultiplexer sebesar 2 milidetik sedangkan komunikasi antara
demultiplexer dan displayer lebih kecil, yaitu sebesar 0.7
milidetik. Dengan nilai jitter yang diperoleh maka masih dalam
kategori bagus, seperti yang dicantumkan pada Tabel 2.4
6. Rata–rata nilai throughput pada jaringan peer to peer untuk
komunikasi antara multiplexer dan demultiplexer sebesar 1187
kbps sedangkan komunikasi antara demultiplexer dan displayer
lebih kecil, yaitu sebesar 302 kbps. Nilai throughput pada
jaringan student PENS untuk komunikasi antara multiplexer
dan demultiplexer sebesar 1202 kbps sedangkan komunikasi
antara demultiplexer dan displayer lebih kecil, yaitu sebesar 35
kbps.

89 
 
90

5.2 Saran
Karena adanya kelemahan pada sistem demultiplexer pada proyek
akhir ini, maka diperlukan pengembangan lebih lanjut. Dan saran-saran
untuk proyek akhir ini adalah :
1. Menggunakan IPv6 sebagai sistem alamat IP yang bekerja pada
jaringan streaming yang dibuat. Mengingat di masa yang akan
datang IPv6 akan menjadi standar umum penggunaan alamat
IP.
2. Proses demultiplexer multi-source video streaming sebaiknya
menggunakan adaptive jitter, sehingga keterlambatan paket
bisa ditangani dan mengurangi packet loss.
3. Proses demultiplexer multi-source video streaming sebaiknya
menggunakan error checking untuk mengurangi kerusakan
video.
 

DAFTAR PUSTAKA

[1] F.Kurose, James dan W. Ross, Keith , “Computer


Networking”, Addison-Wesley , 1999-2000.
[2] Taweewit Pensawat, “ Real-Time Ethernet Networks
Simulation Model”, Journal Halmstad University, December
21, 2006.
[3] “oRTP Reference Manual”
http://www.grogy.com/local_doc/share/doc/ortp/ortpapi.html
[4] “Demultiplexing”
http://www.cs.arizona.edu/projects/scout/Papers/mosberger/doc
023.html
[5] “RTP, Real-Time Transport Protocol”
http://www.networksorcery.com/enp/protocol/rtp.htm
[6] Firmansyah, Rizal Aulia, ”Aplikasi Video Switch Berbasis
Web pada EEPIS I-Studio”, Proyek Akhir PENS-ITS, Juli
2008.
[7] Bilton, Fin Tho’at, ” Rancang Bangun IPTV Set Top Box pada
EEPIS I-Studio”, Proyek Akhir PENS-ITS, Juli 2008.

91 
 
92

====Halaman ini sengaja dikosongkan====


93

LAMPIRAN

Lampiran 1 Listing program terima paket RTP

#include <ortp/ortp.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/time.h>

//Kendali program terima


int cond=1;

void stop_handler(int signum)


{
cond=0;
}

//Kendali program kirim


int runcond=1;

void stophandler(int signum)


{
runcond=0;
}

void ssrc_cb(RtpSession *session)


{
printf("hey, the ssrc has changed !\n");
}
//deklarasi program kirim
char buffer_send1[1450];
int prog1();
char buffer_send2[1450];
int prog2();
char buffer_send3[1450];
int prog3();
94

char buffer_send4[1450];
int prog4();
uint32_t user_ts=0;
RtpSession *session1;
RtpSession *session2;
RtpSession *session3;
RtpSession *session4;

int main(int argc, char*argv[])


{
RtpSession *session;
unsigned char buffer[1450];
int err;
uint32_t ts=0;
int stream_received=0;
int local_port;
int have_more;
int i,a;
int jittcomp=40;
bool_t adapt=TRUE;

ortp_init();
ortp_scheduler_init();
ortp_set_log_level_mask(ORTP_DEBUG|ORTP_ME
SSAGE|ORTP_WARNING|ORTP_ERROR);
signal(SIGINT,stop_handler);
session=rtp_session_new(RTP_SESSION_RECVON
LY);

rtp_session_set_scheduling_mode(session,1)
;
rtp_session_set_blocking_mode(session,1);
rtp_session_set_local_addr(session,"0.0.0.
0",atoi(argv[5]));
rtp_session_set_connected_mode(session,TRU
E);
rtp_session_set_symmetric_rtp(session,TRUE
);
rtp_session_enable_adaptive_jitter_compens
ation(session,adapt);
95

rtp_session_set_jitter_compensation(sessio
n,jittcomp);
rtp_session_set_payload_type(session,0);
rtp_session_signal_connect(session,"ssrc_c
hanged",(RtpCallback)ssrc_cb,0);
rtp_session_signal_connect(session,"ssrc_c
hanged",(RtpCallback)rtp_session_reset,0);

a=1;
//sesi program kirim
session1=rtp_session_new(RTP_SESSION_SENDO
NLY);
session2=rtp_session_new(RTP_SESSION_SENDO
NLY);
session3=rtp_session_new(RTP_SESSION_SENDO
NLY);
session4=rtp_session_new(RTP_SESSION_SENDO
NLY);
while(cond)
{
have_more=1;
while (have_more){
if (a==5) a=1;

err=rtp_session_recv_with_ts(session,buffe
r,1450,ts,&have_more);
if (err>0) stream_received=1;
if ((stream_received) && (err>0));

if (a==1){

memmove(buffer_send1,buffer,1450);
prog1();
}
if (a==2){

memmove(buffer_send2,buffer,1450);
prog2();
}
96

if (a==3){

memmove(buffer_send3,buffer,1450);
prog3();
}
if (a==4){

memmove(buffer_send4,buffer,1450);
prog4();
}
a+=1;
}
ts+=80;
}

rtp_session_destroy(session);
ortp_exit();

ortp_global_stats_display();

return 0;
}

int prog1(int argc, char *argv[])


{
unsigned char buffer[1450];
int i;
char *ssrc;
int clockslide=0;
int jitter=0;
memmove(buffer,buffer_send1,1450);
argv[2]="127.0.0.1";
argv[3]="5000";

ortp_init();
ortp_scheduler_init();
ortp_set_log_level_mask(ORTP_MESSAGE|ORTP_
WARNING|ORTP_ERROR);
97

rtp_session_set_scheduling_mode(session1,1
);
rtp_session_set_blocking_mode(session1,1);
rtp_session_set_connected_mode(session1,TR
UE);
rtp_session_set_remote_addr(session1,argv[
2],atoi(argv[3]));
rtp_session_set_payload_type(session1,0);

ssrc=getenv("SSRC");
if (ssrc!=NULL) {
printf("using
SSRC=%i.\n",atoi(ssrc));

rtp_session_set_ssrc(session1,atoi(ssrc));
}

signal(SIGINT,stophandler);
if( ((i=strlen(buffer))>0) && (runcond) )
{

rtp_session_send_with_ts(session1,buffer,i
,user_ts);
user_ts+=80;

if (clockslide!=0 &&
user_ts%(80*50)==0){
ortp_message("Clock sliding of
%i miliseconds now",clockslide);

rtp_session_make_time_distorsion(session1,
clockslide);
}
/*this will simulate a burst of late
packets */
if (jitter && (user_ts%(8000)==0)) {
struct timespec pausetime,
remtime;
ortp_message("Simulating late
packets now (%i milliseconds)",jitter);
98

pausetime.tv_sec=jitter/1000;

pausetime.tv_nsec=(jitter%1000)*1000000;

while(nanosleep(&pausetime,&remtime)==-1
&& errno==EINTR){
pausetime=remtime;
}
}
}

printf("Program send 1 ts= %d\n",user_ts);


printf("Kirim %d byte ke %s port %d\n",
strlen (buffer),argv[2],atoi(argv[3]));
//rtp_session_destroy(session1);
//ortp_exit();
//ortp_global_stats_display();
//return 0;

int prog2(int argc, char *argv[])


{
unsigned char buffer[1450];
int i;
char *ssrc;
int clockslide=0;
int jitter=0;
memmove(buffer,buffer_send2,1450);
argv[2]="127.0.0.1";
argv[3]="5001";

ortp_init();
ortp_scheduler_init();
ortp_set_log_level_mask(ORTP_MESSAGE|ORTP_
WARNING|ORTP_ERROR);

rtp_session_set_scheduling_mode(session2,1
);
rtp_session_set_blocking_mode(session2,1);
99

rtp_session_set_connected_mode(session2,TR
UE);
rtp_session_set_remote_addr(session2,argv[
2],atoi(argv[3]));
rtp_session_set_payload_type(session2,0);

ssrc=getenv("SSRC");
if (ssrc!=NULL) {
printf("using
SSRC=%i.\n",atoi(ssrc));

rtp_session_set_ssrc(session2,atoi(ssrc));
}

signal(SIGINT,stophandler);
if( ((i=strlen(buffer))>0) && (runcond) )
{

rtp_session_send_with_ts(session2,buffer,i
,user_ts);
user_ts+=80;

if (clockslide!=0 &&
user_ts%(80*50)==0){
ortp_message("Clock sliding of
%i miliseconds now",clockslide);

rtp_session_make_time_distorsion(session2,
clockslide);
}
/*this will simulate a burst of late
packets */
if (jitter && (user_ts%(8000)==0)) {
struct timespec pausetime,
remtime;
ortp_message("Simulating late
packets now (%i milliseconds)",jitter);
pausetime.tv_sec=jitter/1000;

pausetime.tv_nsec=(jitter%1000)*1000000;
100

while(nanosleep(&pausetime,&remtime)==-1
&& errno==EINTR){
pausetime=remtime;
}
}
}
printf("Program send 2 ts= %d\n",
user_ts);
printf("Kirim %d byte ke %s port %d\n",
strlen (buffer),argv[2],atoi(argv[3]));
//rtp_session_destroy(session2);
//ortp_exit();
//ortp_global_stats_display();
//return 0;
}

int prog3(int argc, char *argv[])


{
unsigned char buffer[1450];
int i;
char *ssrc;
int clockslide=0;
int jitter=0;
memmove(buffer,buffer_send3,1450);
argv[2]="127.0.0.1";
argv[3]="5002";

ortp_init();
ortp_scheduler_init();
ortp_set_log_level_mask(ORTP_MESSAGE|ORTP_
WARNING|ORTP_ERROR);

rtp_session_set_scheduling_mode(session3,1
);
rtp_session_set_blocking_mode(session3,1);
rtp_session_set_connected_mode(session3,TR
UE);
rtp_session_set_remote_addr(session3,argv[
2],atoi(argv[3]));
101

rtp_session_set_payload_type(session3,0);

ssrc=getenv("SSRC");
if (ssrc!=NULL) {
printf("using
SSRC=%i.\n",atoi(ssrc));

rtp_session_set_ssrc(session3,atoi(ssrc));
}

signal(SIGINT,stophandler);
if( ((i=strlen(buffer))>0) && (runcond) )
{

rtp_session_send_with_ts(session3,buffer,i
,user_ts);
user_ts+=80;

if (clockslide!=0 &&
user_ts%(80*50)==0){
ortp_message("Clock sliding of
%i miliseconds now",clockslide);

rtp_session_make_time_distorsion(session3,
clockslide);
}
/*this will simulate a burst of late
packets */
if (jitter && (user_ts%(8000)==0)) {
struct timespec pausetime,
remtime;
ortp_message("Simulating late
packets now (%i milliseconds)",jitter);
pausetime.tv_sec=jitter/1000;

pausetime.tv_nsec=(jitter%1000)*1000000;

while(nanosleep(&pausetime,&remtime)==-1
&& errno==EINTR){
pausetime=remtime;
102

}
}
}
printf("Program send 3 ts= %d\n",
user_ts);
printf("Kirim %d byte ke %s port %d\n",
strlen (buffer),argv[2],atoi(argv[3]));
//rtp_session_destroy(session3);
//ortp_exit();
//ortp_global_stats_display();
//return 0;
}

int prog4(int argc, char *argv[])


{
unsigned char buffer[1450];
int i;
char *ssrc;
int clockslide=0;
int jitter=0;
memmove(buffer,buffer_send4,1450);
argv[2]="127.0.0.1";
argv[3]="5003";

ortp_init();
ortp_scheduler_init();
ortp_set_log_level_mask(ORTP_MESSAGE|ORTP_
WARNING|ORTP_ERROR);

rtp_session_set_scheduling_mode(session4,1
);
rtp_session_set_blocking_mode(session4,1);
rtp_session_set_connected_mode(session4,TR
UE);
rtp_session_set_remote_addr(session4,argv[
2],atoi(argv[3]));
rtp_session_set_payload_type(session4,0);

ssrc=getenv("SSRC");
if (ssrc!=NULL) {
103

printf("using
SSRC=%i.\n",atoi(ssrc));

rtp_session_set_ssrc(session4,atoi(ssrc));
}

signal(SIGINT,stophandler);
if( ((i=strlen(buffer))>0) && (runcond) )
{

rtp_session_send_with_ts(session4,buffer,i
,user_ts);
user_ts+=80;

if (clockslide!=0 &&
user_ts%(80*50)==0){
ortp_message("Clock sliding of
%i miliseconds now",clockslide);

rtp_session_make_time_distorsion(session4,
clockslide);
}
/*this will simulate a burst of late
packets */
if (jitter && (user_ts%(8000)==0)) {
struct timespec pausetime,
remtime;
ortp_message("Simulating late
packets now (%i milliseconds)",jitter);
pausetime.tv_sec=jitter/1000;

pausetime.tv_nsec=(jitter%1000)*1000000;

while(nanosleep(&pausetime,&remtime)==-1
&& errno==EINTR){
pausetime=remtime;
}
}
}
104

printf("Program send 4 ts= %d\n",


user_ts);
printf("Kirim %d byte ke %s port %d\n",
strlen (buffer),argv[2],atoi(argv[3]));
//rtp_session_destroy(session4);
//ortp_exit();
//ortp_global_stats_display();
//return 0;
}

Lampiran 2 Tabel payload type pada RTP (Real-time Transport


Protokol)
105

Lampiran 3 Parameter Kualitas Layanan Standar ITU-T


Recommendation G.1010
106
 

...:::BIODATA PENULIS:::…

Nama : AHMAD BUDI SETIYAWAN


TTL : Blitar, 9 Maret 1988
Alamat : Kalipucung RT/RT 03/01 SananKulon - Blitar
HP : 085646417648
Email : ahbuset@yahoo.com
Hobby : - Gym
- Game Travian yang mengisi waktuku dalam pengerjaan
Tugas Akhir
- Maen Poker
Motto : Kebijaksanaan bukan merupakan produk dari sekolah, tapi dari
usaha seumur hidup untuk mendapatkannya.

RIWAYAT PENDIDIKAN
Tahun Pendidikan
1994 – 2000 SDN 2 Kalipucung - Blitar
2000 – 2003 SMPN 9 Blitar
2003 – 2006 SMAN 1 Srengat – Blitar
2006 – 2010 Politeknik Elektronika Negeri Surabaya- ITS

You might also like