54308633-7206040045

i

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

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

ii

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 :

ENGESAHAN

ABSTRAK

Dosen Pembimbing :

1. A Subhan KH, ST

NIP. 19770120 200801 1010

Mengetahui, Ketua Jurusan Teknik Telekomunikasi

Arifin, ST. MT NIP. 19600503 198803 1004

Tim Penguji Proyek Akhir :

1. Tri Budi Santoso, ST, MT NIP. 19700105 199502 1001

2. Reni Soelistijorini, B.Eng, MT NIP. 19710428 199903 2002

3. Moh. Agus Zainudin, ST, MT NIP. 19780812 200801 1015

iii

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

iv

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

v

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

vi

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”.

vii

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.

viii

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

ix

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

x

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

xi

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

xii

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.15 Video dengan ukuran paket kirim 1132 bytes ............. 62



xiii



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


komunikasi student PENS ........................................... 70

Gambar 4.25 Grafik nilai delay paket RTP menuju port 5000

untuk komunikasi peer to peer ..................................... 72








untuk komunikasi jaringan student PENS ................... 78







xiv

Gambar 4.33 Grafik nilai jitter pada demultiplexer untuk


Gambar 4.34 Grafik nilai jitter pada demultiplexer untuk

komunikasi jaringan student PENS ............................. 84

Gambar 4.35 Grafik nilai throughput pada demultiplexer untuk



komunikasi jaringan student PENS ............................. 87

xv

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


jaringan student PENS ...................................................... 70

Tabel 4.5 Delay paket RTP menuju port 5000 untuk sesi komunikasi

peer to peer ........................................................................ 71


peer to peer ........................................................................ 72


peer to peer ........................................................................ 73


peer to peer ........................................................................ 74





xvi





Tabel 4.13 Perbandingan jitter pada masing-masing port untuk

komunikasi peer to peer .................................................... 82


komunikasi jaringan student PENS ................................... 83

Tabel 4.15 Perbandingan throughput pada masing-masing port untuk

komunikasi peer to peer .................................................... 84


komunikasi jaringan student PENS ................................... 86

1

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 2.1

C 2.3

C 2.2

C 3.1

C 3.3

C 3.2

C 4.1

C 4.3

C 4.2

C 1.1

C 1.3

C 1.2

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====

7

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. void session_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

45

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 2.1

C 2.3

C 2.2

C 3.1

C 3.3

C 3.2

C 4.1

C 4.3

C 4.2

C 1.1

C 1.3

C 1.2

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-

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

2. Pindah direktori ke ortp-0.16.3

# tar -xvf ortp-0.16.3.tar.gz

# cd ortp-0.16.3

49

3. Konfigurasi paket pada sistem. Hasil setelah konfigurasi paket akan tampak seperti Gambar 3.4.

Gambar 3.4 Konfigurasi oRTP 0.16.3

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

Gambar 3.5 Kompile paket oRTP 0.16.3

# ./configure

#make

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.

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 check

# 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 :

2. Buka wireshark. Tampilan wireshark seperti Gambar 3.8 :

Gambar 3.8 Wireshark

# apt-get install 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

2) Jalankan program

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:

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

# ./rtprecv4 9999

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.

55

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

56

2. Paket kedua yang diterima oleh demultiplexer :

Gambar 4.3 Capture paket kedua yang diterima demultiplexer


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


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


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 Buffer

Ukuran Data (Bytes)

RTP header (Bytes)

Paket kirim (Bytes) Kondisi Video

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.


60





61





62





63






64



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

Pengukuran Di Terima Detik ke-

Kirim Pada Detik ke- Time Eksekusi

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)



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)



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.

Multiplexer Demultiplexer Terminal Access

Gambar 4.21 Topologi sesi komunikasi peer to peer

68

Demultiplexer Terminal Access

Network

Server Student PENS

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-

an Port

9999(%) Port

5000(%)Port

5001(%)Port

5002(%)Port

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-

an Port

9999(%)Port

5000(%)Port

5001(%)Port

5002(%) Port

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


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.


jaringan student PENS Pengukur-

an Port

9999(%) Port

5000(%) Port

5001(%) Port

5002(%) Port

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


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.


peer to peer

Pengukuran Delay Port 9999 (ms)

Delay Port 5000 (ms)

Total Delay ke Port 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




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.





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


Dari Tabel 4.7 maka dapat dibuat grafik seperti Gambar 4.27 yang, menampilkan delay paket yang dikirimkan menuju displayer dari video ketiga.





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 :


= 49.9864094 + 0.050401567 = 50.036811 milidetik

Port 5002 :


= 49.986113 + 0.050401567 = 50.036515 milidetik

Port 5003 :


= 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




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.





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


Dari Tabel 4.10 maka dapat dibuat grafik seperti Gambar 4.30, yang menampilkan delay paket yang dikirimkan menuju displayer dari video kedua.


Pengukuran




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


Dari Tabel 4.11 maka dapat dibuat grafik seperti Gambar 4.31, yang menampilkan delay paket yang dikirimkan menuju displayer dari video ketiga.





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


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 Pengukuran Port

9999(ms) Port

5000(ms) Port

5001(ms) Port

5002(ms) Port

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.


komunikasi jaringan student PENS

Pengukuran Port

9999(ms) Port

5000(ms) Port

5001(ms) Port

5002(ms) Port

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 :



Pengukuran Port 9999

(kbps)

Port 5000

(kbps)

Port 5001

(kbps)

Port 5002

(kbps)

Port 5003

(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)


(kbps)

Port 5000

(kbps)

Port 5001

(kbps)

Port 5002

(kbps)

Port 5003

(kbps) 4 1187.54 302.89 302.7 302.76 302.635 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.798 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


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.


komunikasi jaringan student PENS


(kbps)

Port 5000

(kbps)

Port 5001

(kbps)

Port 5002

(kbps)

Port 5003

(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


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


89

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.

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.

91

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/doc023.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.

92


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_MESSAGE|ORTP_WARNING|ORTP_ERROR); signal(SIGINT,stop_handler); session=rtp_session_new(RTP_SESSION_RECVONLY); 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,TRUE); rtp_session_set_symmetric_rtp(session,TRUE); rtp_session_enable_adaptive_jitter_compensation(session,adapt);

95 rtp_session_set_jitter_compensation(session,jittcomp); rtp_session_set_payload_type(session,0); rtp_session_signal_connect(session,"ssrc_changed",(RtpCallback)ssrc_cb,0); rtp_session_signal_connect(session,"ssrc_changed",(RtpCallback)rtp_session_reset,0); a=1; //sesi program kirim session1=rtp_session_new(RTP_SESSION_SENDONLY); session2=rtp_session_new(RTP_SESSION_SENDONLY); session3=rtp_session_new(RTP_SESSION_SENDONLY); session4=rtp_session_new(RTP_SESSION_SENDONLY); while(cond) { have_more=1; while (have_more){ if (a==5) a=1; err=rtp_session_recv_with_ts(session,buffer,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,TRUE); 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,TRUE); 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,TRUE); 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,TRUE); 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

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

Nama : AHMAD BUDI SETIYAWAN TTL : Blitar, 9 Maret 1988 Alamat : Kalipucung RT/RT 03/01 SananKulon - Blitar HP : 085646417648 Email : [email protected] 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

54308633-7206040045

Documents

Transcript of 54308633-7206040045