31
BAB IV PENGUJIAN SISTEM 4.1
Pengujian Sistem Dalam penelitian ini, dibangun 2 buah server IP-PBX dengan software
Asterisk yang diumpamakan bahwa masing-masing server terletak di kantor pusat dan kantor cabang. Pengujian ini dilakukan dengan tujuan : a) Membuktikan bahwa sistem IP-PBx yang dibangun bisa bekerja. b) Membuktikan teori call flow SIP session yang terjadi antar UA baik yang berada dalam domain yang sama maupun berbeda. c) Mengamati besarnya konsumsi bandwidth pada sebuah call session dan hubunganya dengan penggunaan audio codec yang berbeda.
4.2
Pengujian Sistem IP-PBx Setelah proses instalasi dan konfigurasi Asterisk di kedua sisi selesai, maka
pada dashboard Asterisk GUI akan muncul indikasi yang menunjukan bahwa konfigurasi sudah benar. Dalam penelitian ini, konfigurasi utama yang dibuat pada Asterisk adalah SIP Trunk, DialPlan, dan users. Di bawah ini adalah tampilan pada dashboard Asterisk GUI.
32
Gambar 4.1 Dashboard Asterisk pada kantor pusat (atas) dan kantor cabang (bawah) Pada gambar diatas terlihat bahwa konfigurasi SIP Trunk berhasil dengan indikasi di masing-masing Asterisk tertera keterangan Registered. Pada bagian Extensions, terlihat pula jumlah user yang sudah dibuat pada Asterisk dan juga jumlah user yang berhasil register ke dalam Asterisk dengan indikasi bulatan hijau.
33
4.3
Pengamatan Call Flow Pada Sebuah SIP Session Setelah user berhasil register ke dalam Asterisk, pengujian berikutnya adalah
melakukan panggilan dari kantor cabang ke kantor pusat. User yang melakukan panggilan dari kantor pusat adalah Sri dengan extension 6201, sedangkan user di kantor pusat adalah Mr. Smith dengan extension 6003. Pengaturan dialplan untuk melakukan panggilan dari kantor cabang ke kantor pusat adalah dengan menekan angka 87 sebelum menekan extension yang dituju, contoh : 876003. Dibawah ini adalah tampilan pada aplikasi X-lite ketika melakukan panggilan.
Gambar 4.2 Panggilan menggunakan aplikasi X-lite Setelah Asterisk di kantor pusat menerima permintaan panggilan, Asterisk yang berada di kantor cabang akan meroute panggilan ke Asterisk yang berada di kantor pusat dan kemudian meneruskan panggilan ke extension tujuan, yaitu 6003.
34
Gambar 4.3 SIP session yang termonitor menggunakan aplikasi Wireshark Gambar di atas mejelaskan bagaimana SIP session terjadi antara extension 6201 dan extension 6003. Extension 6201 (192.168.0.2) memulai panggilan dengan mengirimkan SIP request “INVITE” kepada extension 6003 (192.168.0.3), yang dalam prosesnya melewati Asterisk kantor cabang (192.168.0.223) dan Asterisk kantor pusat (192.168.0.222). “INVITE” yang diterima oleh Asterisk kantor cabang diterima, diolah, dan diteruskan ke tujuan selanjutnya yaitu Asterisk kantor pusat dan dalam waktu yang bersamaan Asterisk kantor cabang mengirimkan SIP response atau pada aplikasi wireshark disebut sebagai SIP status “100 Trying”. Pesan ini diteruskan kembali oleh Asterisk kantor pusat hingga mencapai extension 6003. Setelah extension 6003 menerima SIP request “INVITE” tersebut, dengan segera UA 6003 akan mengirimkan SIP response “180 Ringing” dan user pada extension 6201 akan mendengar nada sambung yang berbunyi tut. Saat pengguna extension 6003 menerima panggilan dengan mengirimkan SIP response “200 OK”, dengan seketika Asterisk kantor cabang akan meminta persetujuan untuk menjalin komunikasi dengan mengirimkan SIP request “ACK” dan setelah sampai pada UA
35
6003, barulah komunikasi terjalin antara extension 6201 dan 6003. Seperti yang telah disebutkan di awal laporan penelitian ini, pada gambar terlihat bahwa informasi yang dikirmkan diambil alih oleh protokol RTP. Barulah ketika salah satu extension, dalam contoh diatas adalah 6003, mengakiri panggilan dengan mengirimkan SIP request “BYE”, SIP kembali bekerja. Asterisk kantor pusat meneruskan SIP request “BYE” hingga mencapai extension 6201. Dan sebagai balasannya, extension 6201 mengirimkan SIP reponse “200 OK” yang menandakan bahwa SIP session secara resmi berakhir.
4.4
Pengamatan Konsumsi Bandwidth dan Hubungannya Dengan Delay Pada Sebuah Call Session Menggunakan G.711 Pada BAB II telah disebutkan bahwa besarnya konsumsi bandwidth per satu
sesi panggilan menggunakan audio codec G.711 adalah 87,2 Kbps. Namun angka tersebut hanya merupakan sebuah pendekatan karena konstanta – konstanta yang dipakai juga merupakan pendekatan. Pada bagian ini, diamati konsumsi bandwidth per satu sesi panggilan yang menggunakan
G.711
sebagai
audio
codecnya.
Pengamatan
dilakukan
menggunakan software wireshark dan komponen yang diamati selain konsumsi bandwidth adalah jitter dan delay. Data pengamatan hubungan konsumsi bandwidth dan delay diambil dari data rata – rata total paket yang ditransmisikan pada saat pengetesan. Sedangkan data pengamatan hubungan delay dengan jitter menggunakan data asli sebanyak jumlah paket yang ditransmisikan pada saat
36
pengamatan. Hal ini dilakukan supaya pengamatan yang dilakukan dapat lebih tepat sasaran sehingga kesimpulan yang diambil sesuai dengan data pengetesan tersebut.
IP BW (Kbps) 81.20 81.00 80.80 80.60 80.40 80.20 80.00 79.80 79.60 79.40 79.20 79.00 0
2
4
6
8
10
12
14
16
18
Lamanya Pengamatan (menit)
Gambar 4.4 Konsumsi bandwidth pada satu sesi panggilan menggunakan audio codec G.711 Pada hasil pengukuran diatas, tampak bahwa konsumsi bandwidth rata – rata pada satu sesi panggilan menggunakan audio codec G.711 adalah sekitar 81 Kbps, selisih 6,2 Kbps dari perhitungan pada BAB II. Hal ini antara lain dikarenakan pada sesi panggilan yang diamati diatas, dilakukan perubahan intensitas pengiriman data dengan cara mematikan microphone pada masing – masing UA selama enam menit untuk melihat pengaruhnya terhadap konsumsi bandwidth. Terlihat pada gambar diatas, memang terjadi fluktuasi konsumsi bandwidth namun tidak terlalu besar. Data diatas disusun dari 50987 buah paket RTP. Banyaknya paket = 50987 buah, dengan jumlah PPS = 50 Lama pengamatan =
Jumlah paket per menit =
∶ 60 = 16,995 = 2999,23 ≈ 2999
≈ 17
37
Sedangkan hasil pengamatan delay yang terjadi pada saat pengetesan digambarkan pada grafik dibawah ini.
Delay (ms) 20.30 20.25 20.20 20.15 20.10 20.05 20.00 19.95 0
2
4
6
8
10
12
14
16
18
Lamanya Pengamatan (menit)
Gambar 4.5 delay pada pengetesan panggilan menggunakan audio codec G.711 Delay adalah waktu yang dibutuhkan sebuah paket informasi untuk dikirimkan dari sisi pengirim ke penerima. Pada grafik diatas terlihat dalam pengetesan terjadi delay yang cukup konstan pada besaran 20 ms. Sedangkan apabila diperhatikan dengan lebih seksama, besarnya delay yang terjadi berbanding terbalik dengan konsumsi bandwidth. Pada grafik terlihat pada saat konsumsi bandwidth tinggi, delay lebih rendah dan pada saat konsumsi bandwidth rendah, delay menjadi lebih tinggi. Hal ini sesuai dengan hukum Hartley yang menyebutkan bahwa besarnya data yang ditransmisikan sesuai dengan besarnya lebar frekuensi yang digunakan pada saat transmisi tersebut. Dengan analogi bandwidth adalah jalan untuk melewatkan data, maka semakin besar jalan yang tersedia maka semakin cepat pula waktu yang dibutuhkan untuk melewatkan data tersebut.
38
4.5
Pengamatan Terjadinya Jitter dan Hubungannya Dengan Delay Pada Sebuah Call Session Menggunakan G.711 Seperti yang telah disebutkan sebelumnya, pada pengamatan hubungan jitter
dan delay data yang ditampilkan adalah data asli yang berupa 50987 buah paket RTP dengan rata – rata jumlah paket per menit (PPM) adalah 2999 dan lama pengamatan 17 menit.
Jitter (ms) 40 35 30 25 20 15 10 5 0 0
10000
20000
30000
40000
50000
60000
40000
50000
60000
Delay (ms) 400 350 300 250 200 150 100 50 0 -50 0
10000
20000
30000
Gambar 4.6 Pengamatan hubungan jitter dan delay pada pengetesan panggilan menggunakan G.711 Tampak pada grafik diatas pada saat nilai jitter tinggi maka delay pun ikut tinggi. Hal ini berhubungan karena salah satu penyebab jitter adalah terjadinya
39
selisih waktu yang tinggi antara paket data yang ditansmisikan dalam sebuah media transmisi dari sisi pengirim ke sisi penerima (delay). Selisih waktu yang tinggi terlihat dengan delay yang meninggi, hal ini berhubungan lurus dengan nilai jitter yang tinggi juga.
4.6
Pengamatan Sebuah Call Session Menggunakan Audio Codec iLBC30 Sebagai pembanding data diatas, dilakukan sebuah pengamatan lain
menggunakan iLBC30 sebagai audio codec. Pemilihan codec tersebut dikarenakan UA yang digunakan dalam pengetesan tidak memiliki codec lainnya selain G.711 dan iLBC30.
IP (Kbps) 25 24.5 24 23.5 23 0
2
4
6
8
10
12
14
16
18
20
14
16
18
20
Lamanya Pengamatan (menit)
Delay (ms) 32 31.5 31 30.5 30 29.5 0
2
4
6
8
10
12
Lamanya Pengamatan (menit)
Gambar 4.7 Pengamatan konsumsi bandwidth dan hubungannya dengan delay menggunakan iLBC30
40
Terlihat pada grafik diatas bahwa tidak ada perbedaan yang mecolok antara hubungan konsumsi bandwidth dengan delay menggunakan codec G.711 dan iLBC30. Hasil pengamatan keduanya menunjukkan bahwa ketika konsumsi bandwidth meninggi, maka delay yang dihasilkan kecil. Perbedaannya adalah besarnya konsumsi bandwidth dengan menggunakan codec iLBC30 yang rataratanya sebesar 24 Kbps, selisih 4,8 Kbps dari perhitungan di BAB II. Pada pengamatan ini, dilakukan juga perubahan instensitas data yang ditransmisikan dengan cara mematikan microphone di kedua sisi selama 4 menit yang pada grafik diatas, tampak terjadinya fluktuasi konsumsi bandwidth pada saat microphone pada kedua sisi dimatikan. Dari pengamatan tersebut diperoleh 34129 buah paket RTP. Dengan perhitungan seperti pada pengamatan sebelumnya maka akan diperoleh : Banyaknya paket = 34129 buah, dengan jumlah PPS = 30 ∶ 60 = 18,96
Lama pengamatan =
≈ 19
= 1796,26 ≈ 1796
Jumlah paket per menit =
Dan untuk hasil pengamatan hubungan jitter dan delay pada pengamatan ini seperti tampak pada gambar di bawah.
Jitter (ms) 50 40 30 20 10 0 0
5000
10000
15000
20000
25000
30000
35000
40000
41
Delay (ms) 600 500 400 300 200 100 0 -100
0
5000
10000
15000
20000
25000
30000
35000
40000
Gambar 4.8 Pengamatan hubungan jitter dan delay pada pengetesan panggilan menggunakan iLBC30
Dari gambar di atas, terlihat bahwa hasil pengamatan pengetesan panggilan menggunakan codec iLBC30 mirip dengan hasil pengamatan menggunakan codec G.711. Dimana pada saat nilai jitter meninggi maka berbanding lurus dengan delay yang terjadi dalam proses transmisi data. Sedangkan untuk besarnya nilai jitter dan delay yang terjadi pada kedua pengetesan ini tidaklah jauh berbeda walaupun menggunakan audio codec yang sama. Dengan demikian, penggunaan audio codec yang berbeda hanya berpengaruh langsung terhadap konsumsi bandwidth.
