IP Phone pada dasarnya memiliki kemampuan tertentu saja. Misal IP Phone murah haya bisa codec g729, sedangkan IP Phone yang mahal bisa semua jenis codec. Bagaimana cara lawan tahu kemampuuan kita? Disinilah berperan SDP. Info tentang bagimana media di kirim ke kita, kita kirimkan ke lawan bicara melewati SDP yang disispkan waktu signalling awal yaitu:
o Saat caller memulai inisiasi INVITE, atau
o Jika inisiasi INVITE awal dari caller tidak berisi SDP, maka recipient yang mengirimkan lewat signal ACK, dan nanti caller akan info SDP dia lewat signal OK.
Perhatikan gambar diatas, pemantauan dilakukan di output server kiri menuju server kanan:
o=origin
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>
o=CiscoSystemCCM-SIP 2000 1 IN IP4 10.10.199.250
c=connection data
c=<nettype> <addrtype> <connection-address>
c=IN IP4 10.10.199.130
c=menjelaskan item diatasnya (dalam hal ini o=). Dalam contoh diatas item diatasnya adalah session, maka c= berarti session ini di initiate oleh IP 10.10.199.130.
m=media
m=audio 16444 RTP/AVP 18 101
menjelaskan bahwa media yang diangkut adalah audio, dimana akan di bawa oleh RTP menggunakan UDP port 16444 (destination port) dengan codec 18 yaitu g729, dan telephone even nomer 101
selanjutnya adalah detail tentang audio nya.
a=audio
a=rtpmap: 18 g729/8000
a=ptime:20
ptime (packetize time) 20 ms, artinya dalam 1 detik ada 5 paket (1000ms/20ms).
Jik SDP dari IP Phone sebelah kiri (IP Phone A) sampai di IP Phone sebelah kanan (IP Phone B), maka B akan membacanya begini:
o Untuk signaling ke arah IP Phone A, maka B ke IP (o=) I10.10.199.250
o Untuk media ke arah IP Phone A, maka B akan konta ke IP (c=) 10.10.199.130
System yang lebih kompleks:
Berikut ini simulasi LAB menggunakan Cisco UCM yang melakukan Trunk ke CUBE dan Trunk ke PSTN.
CUBE adalah Unified Border Router dari Cisco yang bisa acting sebagai SBC (Session Border Control). SBC biasanya berfungsi untuk menyembunyikan detail bentuk jaringan SIP di network Internal. SBC sangar diperlukan jika terhubung ke operator lain yang tidak kita ijinkan untuk terhubug langsung dengan sistem SIP internal. Disamping itu SIP internal apabila hendak terhubung ke Internet wajib melewati SBC.
SIGNALLING SIP
Signalling akan terjadi seperti gambar berikut:
Signal Pertama: INVITE (UCM/CUCM --> CUBE)
INVITE sip:+15236599965@10.15.0.110:5060 SIP/2.0
SIP Phone mencoba kirim INVITE signal ke nomer tujuan +15236599965. CUCM melempar signal ini ke CUBE 10.15.0.110
Via: SIP/2.0/TCP 10.1.5.15:5060; branch=<global unique id>
Via maksudnya memberitahu CUBE agar respon terhadap signal ini hendaklah dikirim ke 10.1.5.15 (CUCM), branch=<global unique id> masudnya adalah nomer unik yang dipakai oleh CUCM untuk mengidentifikasi panggilan ini.
From: "Jane White" <sip:2002@10.1.5.15>; tag=<tag id>
Kata-kata "Jane White" adalah field Caller ID yang di-daftarkan di CUCM. Pada saat SIP Phone 2002 dial dengan sgnal INVITE ke CUCM, maka CUCM mengerti call tsb datang dari 2002. CUCM akan kirim signal INVITE ini ke CUBE dengan memberikan info From: "Jane White" <sip@2002@10.1.5.15> yang artinya ext 2002 yang terdaftar di CUCM 10.1.5.15.
To: <sip:+15236599965@10.15.0.110>; tag = masih kosong
Informasi To ini menginformasikan bahwa call di-initiate oleh ext 2002 dengan tujuan +15236599965 di server CUBE 10.15.0.110. Lihat bahwa tag masih kosong karena +15236599965 belum membalas signal INVITE ini.
Min-SE: 1800
Maksudnya timeout terhadap session ini adalah 1800 detik (30 menit)
User-Agent: Cisco-CUCM10.5
Maksudnya SIGNAL ini dikirim oleh User-Agent yang ada di CUCM.
Signal Kedua: Trying (CUBE --> UCM/CUCM)
Setelah menerima signal INVITE dari CUCM, maka CUBE membalas dengan signal TRYING ke arah CUCM.
SIP/2.0 100 Trying
Via:
From:
To:
CUBE mengirim signal balasan TRYING ke CUCM, dan informasi Via: From: To akan di copy, alias akan selalu sama info nya selama signaling ini terjadi. Jadi jangan bingung sewaktu membaca To: <sip:+15236599965@10.15.0.110>, kenapa CUBE mengirim To ke diri dia sendiri. Karena Via: From: To dicopy dari signal awal INVITE.
Signal ketiga: INVITE (CUBE --> PSTN/Media GW)
Via:
From:
To:
Tetap dicopy dari signal awal. Namun CUBE tidak mengirim P-Asserted-Identity: dikarenakan PSTN adalah untrusted network.
PENJELASAN FIELD SDP
Protokol SIP mendefinisikan bahwa informasi tentang Media dikirim via informasi SDP yang dikirim saat SIP Signalling. Informasi SDP ini bisa di kirim saat signal INVITE awal. Namun, apabila pada signal INVITE awal (yaitu SIP Phone 2002) tidak mengirimkan SDP, berarti si penerima yaitu +15236599965 di PSTN/Media Gateway yang harus menjelaskan SDP dia. Setelah itu CUCM akan merespon SDP yang bisa di handle oleh SIP Phone 2002.
Jika dilihat dalam debug datas, terlihat bahwa signal awal INVITE tidak menyertakan SDP, maka SDP pertama kali di info oleh recipient yaitu PSTN/Media GE.
Terlihat bahwa source media yaitu dari SIP Phone IP 10.20.21.2 tidak terlihat pada bagian "c=" baik "c=" untuk session "o=" ataupun "c=" untuk menjelaskan "m=".
Karena pada prinsipnya apabila paket SIP berisi data SDP ini melewati sebuah SIP yang berfungsi sebagai Trunk, maka data SDP nya akan diubah. Kecuali memang SIP Server di setting tidak mengoverwrite informasi ini. Biasanya network yang berada di dalam serperti SIP Server UCM diatas berada di dalam, maka UCM tidak mengubah data "c=IN" ini.
Perhatikan signalling dari Call Manager CCM atau sering disingkat juga sebagai CUCM ke arah CUBE
Terlihat bahwa CCM tidak mengbah source media nya "c=IN IP4 10.20.21.2", artinya saat two way media communication berlangsung server CUBE akan langsung mengarahkan traffic ke IP Phone 10.20.21.1, dan tidak melewati CUCM (atau CCM) lagi. Karena CCM/CUCM pada dasarnya memang diperuntukkan untuk menangani signalling saja. Apabila sudah terjadi two way media communication, maka CUCM/CCM tidak mau terlibat.
Ref: https://www.youtube.com/watch?v=LcZXqe7RZDA
No comments:
Post a Comment