SIP - Panduan Cepat
Session Initiation Protocol (SIP) adalah salah satu protokol yang paling umum digunakan dalam teknologi VoIP. Ini adalah protokol lapisan aplikasi yang bekerja bersama dengan protokol lapisan aplikasi lain untuk mengontrol sesi komunikasi multimedia melalui Internet.
Teknologi VoIP
Sebelum melangkah lebih jauh, mari kita pahami dulu beberapa poin tentang VoIP.
VOIP adalah teknologi yang memungkinkan Anda mengirimkan konten suara dan multimedia (video, gambar) melalui Internet. Ini adalah salah satu cara termurah untuk berkomunikasi kapan pun, di mana pun dengan ketersediaan Internet.
Beberapa keuntungan VOIP meliputi -
Biaya rendah
Portability
Tidak ada kabel tambahan
Flexibility
Konferensi video
Untuk panggilan VOIP, yang Anda butuhkan hanyalah komputer / laptop / ponsel dengan konektivitas internet. Gambar berikut menggambarkan bagaimana panggilan VoIP dilakukan.
Dengan hal mendasar ini, mari kita kembali ke SIP.
SIP - Ikhtisar
Diberikan di bawah ini adalah beberapa hal yang perlu diperhatikan tentang SIP -
SIP adalah protokol pensinyalan yang digunakan untuk membuat, memodifikasi, dan mengakhiri sesi multimedia melalui Protokol Internet. Sesi tidak lain adalah panggilan sederhana antara dua titik akhir. Endpoint bisa berupa smartphone, laptop, atau perangkat apa pun yang dapat menerima dan mengirim konten multimedia melalui Internet.
SIP adalah protokol lapisan aplikasi yang ditentukan oleh standar IETF (Internet Engineering Task Force). Ini didefinisikan dalamRFC 3261.
SIP mewujudkan arsitektur klien-server dan penggunaan URL dan URI dari HTTP dan skema pengkodean teks dan gaya tajuk dari SMTP.
SIP mengambil bantuan SDP (Session Description Protocol) yang menjelaskan sesi dan RTP (Real Time Transport Protocol) yang digunakan untuk mengirimkan suara dan video melalui jaringan IP.
SIP dapat digunakan untuk sesi dua pihak (unicast) atau multiparty (multicast).
Aplikasi SIP lainnya termasuk transfer file, pesan instan, konferensi video, permainan online, dan distribusi multimedia yang mengepul.
Di Mana SIP Cocok?
Pada dasarnya SIP adalah protokol lapisan aplikasi. Ini adalah protokol pensinyalan jaringan sederhana untuk membuat dan mengakhiri sesi dengan satu atau lebih peserta. Protokol SIP dirancang untuk tidak bergantung pada protokol transport yang mendasarinya, sehingga aplikasi SIP dapat berjalan di TCP, UDP, atau protokol jaringan lapisan bawah lainnya.
Ilustrasi berikut menggambarkan di mana SIP cocok dalam skema umum hal -
Biasanya, protokol SIP digunakan untuk telepon internet dan distribusi multimedia antara dua atau lebih titik akhir. Misalnya, satu orang dapat memulai panggilan telepon ke orang lain menggunakan SIP, atau seseorang dapat membuat panggilan konferensi dengan banyak peserta.
Protokol SIP dirancang untuk menjadi sangat sederhana, dengan sekumpulan perintah terbatas. Ini juga berbasis teks, sehingga siapa pun dapat membaca pesan SIP yang diteruskan antara titik akhir dalam sesi SIP.
Ada beberapa entitas yang membantu SIP dalam membuat jaringannya. Dalam SIP, setiap elemen jaringan diidentifikasi oleh aSIP URI(Uniform Resource Identifier) yang seperti sebuah alamat. Berikut adalah elemen jaringan -
- Agen pengguna
- Server proxy
- Server Registrar
- Alihkan Server
- Server Lokasi
Agen pengguna
Ini adalah titik akhir dan salah satu elemen jaringan terpenting dari jaringan SIP. Titik akhir dapat memulai, mengubah, atau menghentikan sesi. Agen pengguna adalah perangkat atau elemen jaringan paling cerdas dari jaringan SIP. Bisa jadi softphone, ponsel, atau laptop.
Agen pengguna secara logis dibagi menjadi dua bagian -
User Agent Client (UAC) - Entitas yang mengirimkan permintaan dan menerima respons.
User Agent Server (UAS) - Entitas yang menerima permintaan dan mengirimkan tanggapan.
SIP didasarkan pada arsitektur client-server dimana telepon pemanggil bertindak sebagai klien yang memulai panggilan dan telepon callee bertindak sebagai server yang merespon panggilan tersebut.
Server proxy
Ini adalah elemen jaringan yang menerima permintaan dari agen pengguna dan meneruskannya ke pengguna lain.
Pada dasarnya peran dari server proxy sangat mirip dengan sebuah router.
Ia memiliki beberapa kecerdasan untuk memahami permintaan SIP dan mengirimkannya ke depan dengan bantuan URI.
Sebuah server proxy berada di antara dua agen pengguna.
Maksimal 70 server proxy di antara sumber dan tujuan.
Ada dua jenis server proxy -
Stateless Proxy Server- Ini hanya meneruskan pesan yang diterima. Jenis server ini tidak menyimpan informasi panggilan atau transaksi apa pun.
Stateful Proxy Server- Jenis server proxy ini melacak setiap permintaan dan respons yang diterima dan dapat menggunakannya di masa mendatang jika diperlukan. Itu dapat mengirimkan ulang permintaan, jika tidak ada tanggapan dari sisi lain pada waktunya.
Server Registrar
Server registrar menerima permintaan registrasi dari agen pengguna. Ini membantu pengguna untuk mengotentikasi diri mereka sendiri di dalam jaringan. Ini menyimpan URI dan lokasi pengguna dalam database untuk membantu server SIP lain dalam domain yang sama.
Perhatikan contoh berikut yang menunjukkan proses Pendaftaran SIP.
Di sini penelepon ingin mendaftar dengan domain TMC. Jadi ia mengirimkan permintaan REGISTER ke server Registrar TMC dan server mengembalikan respons 200 OK saat mengotorisasi klien.
Alihkan Server
Server pengalihan menerima permintaan dan mencari penerima permintaan yang dituju di database lokasi yang dibuat oleh pencatat.
Server redirect menggunakan database untuk mendapatkan informasi lokasi dan merespon dengan 3xx (Redirect response) ke pengguna. Kami akan membahas kode respons nanti di tutorial ini.
Server Lokasi
Server lokasi memberikan informasi tentang kemungkinan lokasi pemanggil ke pengalihan dan server proxy.
Hanya server proxy atau server pengalihan yang dapat menghubungi server lokasi.
Gambar berikut menggambarkan peran yang dimainkan oleh masing-masing elemen jaringan dalam membuat sesi.
SIP - Arsitektur Sistem
SIP disusun sebagai protokol berlapis, yang berarti perilakunya dijelaskan dalam bentuk serangkaian tahapan pemrosesan yang cukup independen dengan hanya kopling longgar di antara setiap tahap.
Lapisan SIP terendah adalah miliknya syntax and encoding. Pengkodeannya ditentukan menggunakan augmentedBackus-Naur Form grammar (BNF).
Di tingkat kedua adalah transport layer. Ini menentukan bagaimana Klien mengirim permintaan dan menerima tanggapan dan bagaimana Server menerima permintaan dan mengirim tanggapan melalui jaringan. Semua elemen SIP mengandung lapisan transport.
Berikutnya adalah transaction layer. Transaksi adalah permintaan yang dikirim oleh transaksi Klien (menggunakan lapisan transport) ke transaksi Server, bersama dengan semua tanggapan atas permintaan yang dikirim dari transaksi server kembali ke klien. Setiap tugas yang diselesaikan oleh klien agen pengguna (UAC) berlangsung menggunakan serangkaian transaksi.Stateless proxies tidak mengandung lapisan transaksi.
Lapisan di atas transaction layerdisebut pengguna transaksi. Masing-masing entitas SIP, kecualiStateless proxies, adalah pengguna transaksi.
Gambar berikut menunjukkan aliran panggilan dasar dari sesi SIP.
Diberikan di bawah ini adalah penjelasan langkah demi langkah dari aliran panggilan di atas -
Permintaan UNDANGAN yang dikirim ke server proxy bertanggung jawab untuk memulai sesi.
Server proxy sendsa 100 Trying respon segera ke pemanggil (Alice) untuk menghentikan transmisi ulang permintaan INVITE.
Server proxy mencari alamat Bob di server lokasi. Setelah mendapatkan alamat, itu meneruskan permintaan INVITE lebih lanjut.
Kemudian, 180 Ringing (Respons sementara) yang dihasilkan oleh Bob dikembalikan ke Alice.
SEBUAH 200 OK tanggapan dibuat segera setelah Bob mengangkat telepon.
Bob menerima ACK dari Alice, setelah mendapatkannya 200 OK.
Pada saat yang sama, sesi ditetapkan dan paket RTP (percakapan) mulai mengalir dari kedua ujungnya.
Setelah percakapan, setiap peserta (Alice atau Bob) dapat mengirim file BYE permintaan untuk menghentikan sesi.
BYE menjangkau langsung dari Alice ke Bob dengan melewati server proxy.
Akhirnya, Bob mengirimkan file 200 OK respon untuk mengkonfirmasi BYE dan sesi diakhiri.
Dalam aliran panggilan dasar di atas, tiga transactions adalah (ditandai sebagai 1, 2, 3) tersedia.
Panggilan lengkap (dari INVITE ke 200 OK) dikenal sebagai Dialog.
SIP Trapesium
Bagaimana proxy membantu menghubungkan satu pengguna dengan pengguna lainnya? Mari kita cari tahu dengan bantuan diagram berikut.
Topologi yang ditunjukkan pada diagram dikenal sebagai trapesium SIP. Prosesnya berlangsung sebagai berikut -
Saat penelepon memulai panggilan, pesan UNDANG dikirim ke server proxy. Setelah menerima UNDANGAN, server proxy mencoba untuk menyelesaikan alamat callee dengan bantuan server DNS.
Setelah mendapatkan rute berikutnya, server proxy penelepon (Proxy 1, juga dikenal sebagai server proxy keluar) meneruskan permintaan UNDANG ke server proxy callee yang bertindak sebagai server proxy masuk (Proxy 2) untuk callee.
Server proxy masuk menghubungi server lokasi untuk mendapatkan informasi tentang alamat callee tempat pengguna mendaftar.
Setelah mendapatkan informasi dari server lokasi, itu meneruskan panggilan ke tujuannya.
Setelah agen pengguna mengetahui alamat mereka, mereka dapat melewati panggilan tersebut, yaitu percakapan lewat secara langsung.
Pesan SIP terdiri dari dua jenis - requests dan responses.
Baris pembuka permintaan berisi metode yang mendefinisikan permintaan, dan Request-URI yang menentukan ke mana permintaan akan dikirim.
Demikian pula, baris pembuka respons berisi kode respons.
Metode Permintaan
SIP requestsadalah kode yang digunakan untuk menjalin komunikasi. Untuk melengkapi mereka, adaSIP responses yang biasanya menunjukkan apakah permintaan berhasil atau gagal.
Permintaan SIP ini yang dikenal sebagai METODE membuat pesan SIP bisa diterapkan.
METODE dapat dianggap sebagai permintaan SIP, karena mereka meminta tindakan tertentu untuk diambil oleh agen pengguna atau server lain.
METODE dibedakan menjadi dua jenis -
Metode Inti
Metode Ekstensi
Metode Inti
Ada enam metode inti seperti yang dibahas di bawah ini.
UNDANG
INVITE digunakan untuk memulai sesi dengan agen pengguna. Dengan kata lain, metode INVITE digunakan untuk membuat sesi media antara agen pengguna.
UNDANGAN dapat berisi informasi media penelepon di badan pesan.
Sesi dianggap ditetapkan jika INVITE telah menerima respons sukses (2xx) atau ACK telah dikirim.
Permintaan UNDANGAN yang berhasil membuat a dialog antara dua agen pengguna yang berlanjut hingga BYE dikirim untuk mengakhiri sesi.
UNDANGAN yang dikirim dalam dialog yang mapan dikenal sebagai a re-INVITE.
INVITE ulang digunakan untuk mengubah karakteristik sesi atau menyegarkan status dialog.
UNDANG Contoh
Kode berikut menunjukkan bagaimana INVITE digunakan.
INVITE sips:[email protected] SIP/2.0
Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9
Max-Forwards: 70
From: Alice<sips:[email protected]>;tag = 1234567
To: Bob<sips:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sips:[email protected]>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: ...
v = 0
o = Alice 2890844526 2890844526 IN IP4 client.ANC.com
s = Session SDP
c = IN IP4 client.ANC.com
t = 3034423619 0
m = audio 49170 RTP/AVP 0
a = rtpmap:0 PCMU/8000
Sampai jumpa
BYE adalah metode yang digunakan untuk mengakhiri sesi yang telah ditetapkan. Ini adalah permintaan SIP yang dapat dikirim oleh pemanggil atau penerima untuk mengakhiri sesi.
Itu tidak dapat dikirim oleh server proxy.
Permintaan BYE biasanya merutekan ujung ke ujung, melewati server proxy.
BYE tidak dapat dikirim ke UNDANGAN yang tertunda atau sesi yang tidak ditetapkan.
DAFTAR
Permintaan REGISTER melakukan pendaftaran agen pengguna. Permintaan ini dikirim oleh agen pengguna ke server registrar.
Permintaan REGISTER dapat diteruskan atau di-proxy-kan hingga mencapai registrar resmi dari domain yang ditentukan.
Itu membawa AOR (Address of Record) di To header pengguna yang sedang didaftarkan.
Permintaan DAFTAR berisi periode waktu (3600sec).
Satu agen pengguna dapat mengirim permintaan DAFTAR atas nama agen pengguna lain. Ini dikenal sebagaithird-party registration. Di siniFrom tag berisi URI pihak yang mengirimkan pendaftaran atas nama pihak yang diidentifikasi di To header.
MEMBATALKAN
BATAL digunakan untuk mengakhiri sesi yang tidak dibuat. Agen pengguna menggunakan permintaan ini untuk membatalkan upaya panggilan tertunda yang dimulai lebih awal.
Ini dapat dikirim baik oleh agen pengguna atau server proxy.
BATAL adalah a hop by hop request, yaitu, melewati elemen antara agen pengguna dan menerima respons yang dihasilkan oleh elemen stateful berikutnya.
ACK
ACK digunakan untuk mengakui tanggapan akhir untuk metode UNDANGAN. ACK selalu mengarah ke INVITE.ACK mungkin berisi badan SDP (karakteristik media), jika tidak tersedia di INVITE.
ACK tidak boleh digunakan untuk mengubah deskripsi media yang telah dikirim di INVITE awal.
Proksi stateful yang menerima ACK harus menentukan apakah ACK harus diteruskan ke hilir atau tidak ke proxy atau agen pengguna lain.
Untuk respons 2xx, ACK bersifat ujung ke ujung, tetapi untuk semua respons akhir lainnya, ACK bekerja secara hop by hop ketika proxy stateful terlibat.
PILIHAN
Metode OPTIONS digunakan untuk menanyakan agen pengguna atau server proxy tentang kemampuannya dan menemukan ketersediaannya saat ini. Respons terhadap permintaan mencantumkan kemampuan agen pengguna atau server. Proksi tidak pernah menghasilkan permintaan OPTIONS.
Metode Ekstensi
Langganan
SUBSCRIBE digunakan oleh agen pengguna untuk membuat langganan dengan tujuan mendapatkan pemberitahuan tentang peristiwa tertentu.
Ini berisi Expires kolom header yang menunjukkan durasi langganan.
Setelah jangka waktu berlalu, langganan akan dihentikan secara otomatis.
Langganan membuat dialog antara agen pengguna.
Anda dapat kembali berlangganan dengan mengirim BERLANGGANAN lagi dalam dialog sebelum waktu kedaluwarsa.
200 OK akan diterima untuk langganan dari Pengguna.
Pengguna dapat berhenti berlangganan dengan mengirimkan metode BERLANGGANAN lain dengan nilai Kedaluwarsa 0 (nol).
MEMBERITAHU
NOTIFY digunakan oleh agen pengguna untuk mendapatkan terjadinya peristiwa tertentu. Biasanya NOTIFY akan memicu dalam dialog ketika ada langganan antara pelanggan dan pemberi notifikasi.
Setiap NOTIFY akan mendapatkan 200 respon OK jika diterima oleh notifier.
NOTIFY berisi Event bidang header yang menunjukkan acara dan a subscriptionstate kolom header yang menunjukkan status langganan saat ini.
PEMBERITAHUAN selalu dikirim di awal dan penghentian langganan.
MENERBITKAN
PUBLIKASIKAN digunakan oleh agen pengguna untuk mengirim informasi status acara ke server.
PUBLIKASIKAN sebagian besar berguna ketika ada banyak sumber informasi acara.
Permintaan PUBLISH mirip dengan NOTIFY, kecuali bahwa itu tidak dikirim dalam dialog.
Permintaan PUBLIKASIKAN harus berisi Expires bidang header dan a Min-Expires bidang header.
LIHAT
REFER digunakan oleh agen pengguna untuk merujuk agen pengguna lain untuk mengakses URI dialog.
REFER harus mengandung a Refer-Toheader. Ini adalah header wajib untuk REFER.
REFER dapat dikirim di dalam atau di luar dialog.
SEBUAH 202 Accepted akan memicu permintaan REFER yang menunjukkan bahwa agen pengguna lain telah menerima referensi.
INFO
INFO digunakan oleh agen pengguna untuk mengirim informasi pensinyalan panggilan ke agen pengguna lain yang telah membuat sesi medianya.
Ini adalah permintaan ujung ke ujung.
Proksi akan selalu meneruskan permintaan INFO.
MEMPERBARUI
UPDATE digunakan untuk mengubah status sesi jika sesi tidak dibuat. Pengguna dapat mengubah codec dengan UPDATE.
JIKA sesi dibuat, Undangan ulang digunakan untuk mengubah / memperbarui sesi.
PRACK
PRACK digunakan untuk mengakui penerimaan transfer respons sementara yang andal (1XX).
Umumnya PRACK dibuat oleh klien ketika menerima respons sementara yang berisi file RSeq nomor urut yang dapat diandalkan dan a supported:100rel header.
PRACK berisi nilai (RSeq + CSeq) di rack header.
Metode PRACK berlaku untuk semua respons sementara kecuali respons 100 Mencoba, yang tidak pernah dikirimkan dengan andal.
PRACK mungkin berisi badan pesan; ini dapat digunakan untuk pertukaran penawaran / jawaban.
PESAN
Ini digunakan untuk mengirim pesan instan menggunakan SIP. IM biasanya terdiri dari pesan singkat yang dipertukarkan secara real time oleh peserta yang terlibat dalam percakapan teks.
PESAN dapat dikirim dalam dialog atau di luar dialog.
Isi PESAN dibawa dalam badan pesan sebagai MIME lampiran.
SEBUAH 200 OK respon biasanya diterima untuk menunjukkan bahwa pesan telah dikirim ke tujuannya.
Respons SIP adalah pesan yang dibuat oleh server agen pengguna (UAS) atau server SIP untuk membalas permintaan yang dibuat oleh klien. Ini bisa menjadi pengakuan formal untuk mencegah pengiriman ulang permintaan oleh UAC.
Respons mungkin berisi beberapa bidang header tambahan dari info yang dibutuhkan oleh UAC.
SIP memiliki enam tanggapan.
1xx hingga 5xx telah dipinjam dari HTTP dan 6xx diperkenalkan di SIP.
1xx dianggap sebagai provisional respon dan sisanya final tanggapan.
S.No. | Deskripsi fungsi |
---|---|
1 | 1xx: Tanggapan Sementara / Informasi Tanggapan informasional digunakan untuk menunjukkan call progress. Biasanya tanggapannya ujung ke ujung (kecuali 100 Mencoba). |
2 | 2xx: Tanggapan Sukses Kelas tanggapan ini dimaksudkan untuk menunjukkan bahwa permintaan telah diterima. |
3 | 3xx: Mengalihkan Tanggapan Umumnya tanggapan kelas ini dikirim oleh server pengalihan sebagai tanggapan atas INVITE. Mereka juga dikenal sebagai tanggapan kelas pengalihan. |
4 | 4xx: Tanggapan Kegagalan Klien Respons kesalahan klien menunjukkan bahwa permintaan tidak dapat dipenuhi karena beberapa kesalahan diidentifikasi dari sisi UAC. |
5 | 5xx: Respons Kegagalan Server Respon kelas ini digunakan untuk menunjukkan bahwa permintaan tidak dapat diproses karena kesalahan dengan server. |
6 | 6xx: Respons Kegagalan Global Kelas respons ini menunjukkan bahwa server mengetahui bahwa permintaan akan gagal di mana pun ia mencoba. Akibatnya, permintaan tersebut tidak boleh dikirim ke lokasi lain. |
Header adalah komponen pesan SIP yang menyampaikan informasi tentang pesan tersebut. Ini disusun sebagai urutan bidang tajuk.
Bidang header SIP dalam banyak kasus mengikuti aturan yang sama seperti bidang header HTTP. Bidang tajuk didefinisikan sebagaiHeader: field, di mana Header digunakan untuk mewakili nama bidang header, dan bidang adalah sekumpulan token yang berisi informasi. Setiap bidang terdiri dari nama bidang diikuti oleh titik dua (":") dan nilai bidang (yaitu,field-name: field-value).
Header SIP - Bentuk Ringkas
Banyak bidang tajuk SIP yang umum memiliki bentuk ringkas di mana nama bidang tajuk dilambangkan dengan satu karakter huruf kecil. Beberapa contoh diberikan di bawah ini -
Header | Bentuk Kompak |
---|---|
Untuk | T |
Melalui | V. |
Call-ID | saya |
Kontak | M |
Dari | F |
Subyek | S |
Panjang Konten | saya |
Format Header SIP
Gambar berikut menunjukkan struktur header SIP yang khas.
Header dikategorikan sebagai berikut tergantung pada penggunaannya di SIP -
- Permintaan dan Tanggapan
- Permintaan Saja
- Respon Saja
- Badan Pesan
SDP adalah singkatan dari Session Description Protocol. Ini digunakan untuk mendeskripsikan sesi multimedia dalam format yang dipahami oleh peserta melalui jaringan. Bergantung pada deskripsi ini, salah satu pihak memutuskan apakah akan bergabung dengan konferensi atau kapan atau bagaimana cara bergabung dengan konferensi.
Pemilik konferensi mengiklankannya melalui jaringan dengan mengirimkan pesan multicast yang berisi deskripsi sesi misalnya nama pemilik, nama sesi, pengkodean, waktu, dll. Tergantung pada informasi ini, penerima iklan mengambil keputusan tentang partisipasi dalam sesi tersebut.
SDP umumnya terdapat pada body bagian Session Initiation Protocol yang populer disebut SIP.
SDP didefinisikan dalam RFC 2327. Pesan SDP terdiri dari serangkaian baris, yang disebut bidang, yang namanya disingkat dengan satu huruf kecil, dan dalam urutan yang diperlukan untuk menyederhanakan penguraian.
Tujuan SDP
Tujuan SDP adalah untuk menyampaikan informasi tentang aliran media dalam sesi multimedia untuk membantu peserta bergabung atau mengumpulkan info dari sesi tertentu.
SDP adalah deskripsi tekstual terstruktur singkat.
Ini menyampaikan nama dan tujuan sesi, media, protokol, format codec, waktu dan informasi transportasi.
Seorang peserta tentatif memeriksa informasi ini dan memutuskan apakah akan bergabung dengan sesi dan bagaimana dan kapan bergabung dengan sesi jika memutuskan untuk melakukannya.
Format tersebut memiliki entri dalam bentuk <type> = <value>, dengan <type> mendefinisikan parameter sesi unik dan <value> memberikan nilai spesifik untuk parameter tersebut.
Bentuk umum dari pesan SDP adalah -
x = parameter1 parameter2 ... parameterN
Baris dimulai dengan satu huruf kecil, misalnya x. Tidak pernah ada spasi di antara huruf dan =, dan tepat ada satu spasi di antara setiap parameter. Setiap bidang memiliki jumlah parameter yang ditentukan.
Parameter Deskripsi Sesi
Deskripsi sesi (* menunjukkan opsional)
- v = (versi protokol)
- o = (pemilik / pembuat dan pengidentifikasi sesi)
- s = (nama sesi)
- i = * (informasi sesi)
- u = * (URI deskripsi)
- e = * (alamat email)
- p = * (nomor telepon)
- c = * (informasi koneksi - tidak diperlukan jika disertakan di semua media)
- b = * (informasi bandwidth)
- z = * (penyesuaian zona waktu)
- k = * (kunci enkripsi)
- a = * (nol atau lebih baris atribut sesi)
Versi Protokol
Bidang v = berisi nomor versi SDP. Karena versi SDP saat ini adalah 0, pesan SDP yang valid akan selalu dimulai dengan v = 0.
Asal
Kolom o = berisi informasi tentang pembuat sesi dan pengidentifikasi sesi. Bidang ini digunakan untuk mengidentifikasi sesi secara unik.
Bidang berisi -
o = <username> <session-id> <version> <network-type> <address-type>
Itu username parameter berisi login atau host pembuatnya.
Itu session-id parameter adalah stempel waktu Network Time Protocol (NTP) atau nomor acak yang digunakan untuk memastikan keunikan.
Itu version adalah bidang numerik yang ditingkatkan untuk setiap perubahan pada sesi, juga direkomendasikan untuk menjadi stempel waktu NTP.
Itu network-typeselalu IN untuk Internet. Parameter tipe alamat adalah IP4 atau IP6 untuk alamat IPv4 atau IPv6 baik dalam bentuk desimal bertitik atau nama host yang memenuhi syarat.
Nama dan Informasi Sesi
Bidang s = berisi nama untuk sesi tersebut. Ini dapat berisi jumlah karakter bukan nol. Bidang opsional i = berisi informasi tentang sesi. Itu dapat berisi sejumlah karakter.
URI
Bidang u = opsional berisi indikator sumber daya seragam (URI) dengan lebih banyak informasi tentang sesi
Alamat E-Mail dan Nomor Telepon
Kolom opsional e = berisi alamat email dari host sesi. Bidang opsional p = berisi nomor telepon.
Data Koneksi
Kolom c = berisi informasi tentang koneksi media.
Bidang berisi -
c = <jenis-jaringan> <jenis- alamat> <jenis- alamat>
Itu network-type parameter didefinisikan sebagai IN untuk Internet.
Itu address-type didefinisikan sebagai IP4 untuk alamat IPv4 dan IP6 untuk alamat IPv6.
Itu connection-address adalah alamat IP atau host yang akan mengirimkan paket media, yang dapat berupa multicast atau unicast.
Jika multicast, bidang alamat koneksi berisi -
connection-address = base-multicast-address / ttl / jumlah-alamat
dimana ttl adalah nilai time-to-live, dan jumlah-alamat menunjukkan berapa banyak alamat multicast yang berdekatan disertakan mulai dengan alamat base-multicast.
Bandwidth
Kolom opsional b = berisi informasi tentang bandwidth yang diperlukan. Ini dalam bentuk -
b = pengubah: bandwidth - nilai
Waktu, Waktu Pengulangan, dan Zona Waktu
Kolom t = berisi waktu mulai dan waktu berhenti sesi.
t = waktu berhenti waktu mulai
Kolom opsional r = berisi informasi tentang waktu pengulangan yang dapat ditentukan baik dalam NTP atau dalam hari ( d ), jam ( h ), atau menit ( m ).
Bidang opsional z = berisi informasi tentang offset zona waktu. Bidang ini digunakan jika sesi yang terjadi mencakup perubahan dari pergeseran waktu siang hari ke waktu standar, atau sebaliknya.
Pengumuman Media
Bidang opsional m = berisi informasi tentang jenis sesi media. Bidang berisi -
m = daftar format transportasi port media
Parameter media dapat berupa audio, video, teks, aplikasi, pesan, gambar, atau kontrol. Parameter port berisi nomor port.
Parameter transport berisi protokol transport atau profil RTP yang digunakan.
Format-list berisi lebih banyak informasi tentang media. Biasanya, ini berisi jenis muatan media yang ditentukan dalam profil video audio RTP.
Example:
m = audio 49430 RTP/AVP 0 6 8 99
Salah satu dari tiga codec ini dapat digunakan untuk sesi media audio. Jika tujuannya adalah untuk membuat tiga saluran audio, tiga bidang media terpisah akan digunakan.
Atribut
Bidang opsional a = berisi atribut sesi media sebelumnya. Bidang ini bisa digunakan untukextend SDP to provide more information about the media. Jika tidak sepenuhnya dipahami oleh pengguna SDP, kolom atribut dapat diabaikan. Mungkin ada satu atau beberapa bidang atribut untuk setiap jenis muatan media yang tercantum di bidang media.
Atribut di SDP bisa berupa
- tingkat sesi, atau
- tingkat media.
Tingkat sesi berarti bahwa atribut dicantumkan sebelum baris media pertama di SDP. Jika ini masalahnya, atribut berlaku untuk semua baris media di bawahnya.
Level media berarti itu terdaftar setelah garis media. Dalam kasus ini, atribut hanya berlaku untuk aliran media khusus ini.
SDP dapat menyertakan atribut level sesi dan level media. Jika atribut yang sama muncul sebagai keduanya, atribut tingkat media menggantikan atribut tingkat sesi untuk aliran media tersebut. Perhatikan bahwa bidang data koneksi juga bisa berupa tingkat sesi atau tingkat media.
Contoh SDP
Diberikan di bawah ini adalah contoh deskripsi sesi, diambil dari RFC 2327 -
v = 0
o = mhandley2890844526 2890842807 IN IP4 126.16.64.4
s = SDP Seminar
i = A Seminar on the session description protocol
u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e = [email protected](Mark Handley)
c = IN IP4 224.2.17.12/127
t = 2873397496 2873404696
a = recvonly
m = audio 49170 RTP/AVP 0
m = video 51372 RTP/AVP 31
m = application 32416udp wb
a = orient:portrait
Penggunaan SDP dengan SIP diberikan dalam jawaban tawaran SDP RFC 3264. Jenis isi pesan default di SIP adalah application/sdp.
Pihak pemanggil mencantumkan kemampuan media yang ingin mereka terima di SDP, biasanya dalam INVITE atau ACK.
Pihak yang dipanggil mencantumkan kemampuan medianya dalam tanggapan 200 OK terhadap INVITE.
Penggunaan SIP khas SDP mencakup bidang berikut: versi, asal, subjek, waktu, koneksi, dan satu atau lebih media dan atribut.
Subjek dan bidang waktu tidak digunakan oleh SIP tetapi disertakan untuk kompatibilitas.
Dalam standar SDP, bidang subjek adalah bidang wajib dan harus berisi setidaknya satu karakter, disarankan menjadi s = - jika tidak ada subjek.
Bidang waktu biasanya disetel ke t = 00. SIP menggunakan bidang koneksi, media, dan atribut untuk menyiapkan sesi antara UA.
Bidang asal memiliki penggunaan terbatas dengan SIP.
Sesi-id biasanya dijaga konstan selama sesi SIP.
Versi ini bertambah setiap kali SDP diubah. Jika SDP yang dikirim tidak berubah dari yang dikirim sebelumnya, versinya tetap sama.
Karena jenis sesi media dan codec yang akan digunakan adalah bagian dari negosiasi koneksi, SIP dapat menggunakan SDP untuk menentukan beberapa jenis media alternatif dan untuk secara selektif menerima atau menolak jenis media tersebut.
Spesifikasi penawaran / jawaban, RFC 3264, merekomendasikan bahwa atribut yang berisi a = rtpmap: digunakan untuk setiap bidang media. Aliran media ditolak dengan menyetel nomor port ke nol untuk bidang media yang sesuai dalam respons SDP.
Contoh
Dalam contoh berikut, penelepon Tesla ingin menyiapkan panggilan audio dan video dengan dua kemungkinan codec audio dan codec video di SDP yang dibawa dalam INVITE awal -
v = 0
o = John 0844526 2890844526 IN IP4 172.22.1.102
s = -
c = IN IP4 172.22.1.102
t = 0 0
m = audio 6000 RTP/AVP 97 98
a = rtpmap:97 AMR/16000/1
a = rtpmap:98 AMR-WB/8000/1
m = video 49172 RTP/AVP 32
a = rtpmap:32 MPV/90000
Codec ini direferensikan oleh nomor profil RTP / AVP 97, 98.
Pihak yang dipanggil Marry menjawab panggilan tersebut, memilih codec kedua untuk bidang media pertama, dan menolak bidang media kedua, hanya menginginkan sesi AMR.
v = 0
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110
s = -
c = IN IP4 200.201.202.203
t = 0 0
m = audio 60000 RTP/AVP 8
a = rtpmap:97 AMR/16000
m = video 0 RTP/AVP 32
Jika panggilan audio-only ini tidak dapat diterima, Tom akan mengirimkan ACK lalu BYE untuk membatalkan panggilan tersebut. Jika tidak, sesi audio akan dibuat dan paket RTP dipertukarkan.
Seperti yang diilustrasikan dalam contoh ini, kecuali jumlah dan urutan bidang media dipertahankan, pihak pemanggil tidak akan mengetahui secara pasti sesi media mana yang diterima dan ditolak oleh pihak yang dipanggil.
Aturan penawaran / jawaban dirangkum di bagian berikut.
Aturan untuk Menghasilkan Penawaran
Tawaran SDP harus menyertakan semua bidang SDP yang diperlukan (ini termasuk v =, o =, s =, c =, dan t =). Ini adalah bidang wajib di SDP.
Biasanya mencakup bidang media ( m = ) tetapi tidak harus. Baris media berisi semua codec yang terdaftar dalam urutan preferensi. Satu-satunya pengecualian untuk ini adalah jika titik akhir mendukung sejumlah besar codec, yang paling mungkin diterima atau paling disukai harus dicantumkan. Jenis media yang berbeda termasuk audio, video, teks, MSRP, BFCP, dan lain sebagainya.
Aturan untuk Menghasilkan Jawaban
Jawaban SDP untuk suatu penawaran harus dibuat sesuai dengan aturan berikut -
Jawabannya harus memiliki jumlah garis m = yang sama dengan urutan jawaban yang sama.
Aliran media individu dapat ditolak dengan mengatur nomor port ke 0.
Aliran diterima dengan mengirimkan nomor port bukan nol.
Payload yang terdaftar untuk setiap jenis media harus merupakan subset dari payload yang tercantum dalam penawaran.
Untuk payload dinamis, nomor payload dinamis yang sama tidak perlu digunakan di setiap arah. Biasanya, hanya satu payload yang dipilih.
Aturan untuk Mengubah Sesi
Salah satu pihak dapat memulai pertukaran penawaran / jawaban lain untuk mengubah sesi. Ketika sesi diubah, aturan berikut harus diikuti -
Nomor versi baris asal ( o = ) harus sama dengan yang terakhir dikirim, yang menunjukkan bahwa SDP ini identik dengan pertukaran sebelumnya, atau mungkin bertambah satu, yang menunjukkan SDP baru yang harus diurai.
Penawaran harus menyertakan semua lini media yang ada dan harus dikirim dalam urutan yang sama.
Aliran media tambahan dapat ditambahkan ke akhir daftar m = line.
Aliran media yang ada dapat dihapus dengan menyetel nomor port ke 0. Saluran media ini harus tetap dalam SDP dan semua penawaran / pertukaran jawaban di masa mendatang untuk sesi ini.
Call Hold
Salah satu pihak dalam panggilan dapat menunda sementara pihak lainnya. Ini dilakukan dengan mengirimkan UNDANG dengan SDP yang identik dengan yang asli INVITE tetapi dengana = sendonly atribut hadir.
Panggilan tersebut menjadi aktif lagi dengan mengirim UNDANG lain dengan a = sendrecvatribut hadir. Ilustrasi berikut menunjukkan aliran panggilan dari penahanan panggilan.
Personal mobilityadalah kemampuan untuk memiliki pengenal konstan di sejumlah perangkat. SIP mendukung mobilitas pribadi dasar menggunakan metode REGISTER, yang memungkinkan perangkat seluler mengubah alamat IP dan titik koneksi ke Internet dan masih dapat menerima panggilan masuk.
SIP juga dapat mendukung service mobility - kemampuan pengguna untuk menyimpan layanan yang sama saat seluler
Mobilitas SIP Selama Serah Terima (Pra-panggilan)
Perangkat mengikat URI Kontaknya dengan alamat rekaman dengan pendaftaran sip sederhana. Menurut alamat IP perangkat, pendaftaran mengizinkan informasi ini secara otomatis diperbarui di jaringan sip.
Selama serah terima, agen Pengguna merutekan antara operator yang berbeda, di mana ia harus mendaftar lagi dengan Kontak sebagai AOR dengan penyedia layanan lain.
Sebagai contoh, mari kita ambil contoh aliran panggilan berikut. UA yang untuk sementara menerima URI SIP baru dengan penyedia layanan baru. UA kemudian melakukan pendaftaran ganda -
Pendaftaran pertama dilakukan dengan operator layanan baru, yang mengikat URI Kontak perangkat dengan URI AOR penyedia layanan baru.
Permintaan REGISTER kedua dirutekan kembali ke penyedia layanan asli dan menyediakan AOR penyedia layanan baru sebagai URI Kontak.
Seperti yang ditunjukkan nanti dalam aliran panggilan, saat permintaan masuk ke jaringan penyedia layanan asli, INVITE dialihkan ke penyedia layanan baru yang kemudian merutekan panggilan ke pengguna.
Untuk pendaftaran pertama, pesan yang berisi URI perangkat akan menjadi -
REGISTER sip:visited.registrar1.com SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca
Max-Forwards: 70
To: Tom <sip:[email protected]>
From: Tom <sip:[email protected]>;tag = 72d65a24
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sip:[email protected]:5060>
Expires: 600000
Content-Length: 0
Pesan registrasi kedua dengan URI roaming adalah -
REGISTER sip:home.registrar2.in SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u
Max-Forwards: 70
To: Tom <sip:[email protected]>
From: Tom <sip:[email protected]>;tag = 45375
Call-ID:[email protected]
CSeq: 6421 REGISTER
Contact: <sip:[email protected]>
Content-Length: 0
UNDANGAN pertama yang terwakili pada gambar di atas akan dikirim ke sip: registrar2.in; UNDANGAN kedua akan dikirim ke sip: sip: [email protected], yang akan diteruskan kesip:[email protected]. Ini mencapai Tom dan memungkinkan sesi untuk ditetapkan. Secara berkala, kedua pendaftaran perlu diperbarui.
Mobilitas Selama Panggilan (Undangan Ulang)
Agen Pengguna dapat mengubah alamat IP selama sesi saat bertukar dari satu jaringan ke jaringan lainnya. SIP dasar mendukung skenario ini, karena MENGUNDANG ulang dalam dialog dapat digunakan untuk memperbarui URI Kontak dan mengubah informasi media di SDP.
Lihatlah aliran panggilan yang disebutkan pada gambar di bawah ini.
Di sini, Tom mendeteksi jaringan baru,
Menggunakan DHCP untuk mendapatkan alamat IP baru, dan
Melakukan UNDANG ulang untuk memungkinkan pensinyalan dan aliran media ke alamat IP baru.
Jika UA dapat menerima media dari kedua jaringan, interupsi dapat diabaikan. Jika ini tidak terjadi, beberapa paket media mungkin hilang, mengakibatkan sedikit gangguan pada panggilan.
UNDANGAN ulang akan muncul sebagai berikut -
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a
Max-Forwards: 70
To: <sip:[email protected]>
From: sip:[email protected];tag = 70133df4
Call-ID: 76d4861c19c
CSeq: 1 INVITE
Accept: application/sdp
Accept-Language: en
Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE
Contact: <sip:172.22.1.102:5060>;
Content-Type: application/sdp
Content-Length: 168
v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1
s = -
c = IN IP4 192.168.2.1
b = AS:49
t = 0 0
b = RR:0
b = RS:0
a = rtpmap:97 AMR/8000/1
m = audio 6000 RTP/AVP 96
a = fmtp:102 0-15
a = ptime:20
a = maxptime:240
UNDANGAN ulang berisi alamat IP baru Bowditch di bidang header Via dan Kontak dan informasi media SDP.
Mobilitas di Midcall (Dengan ganti Header)
Dalam mobilitas panggilan tengah, rangkaian rute aktual (kumpulan proxy SIP yang harus dilintasi pesan SIP) harus berubah. Kami tidak dapat menggunakan UNDANGAN ulang dalam mobilitas panggilan tengah
Misalnya, jika proxy diperlukan untuk NAT traversal, URI Kontak harus diubah - dialog baru harus dibuat. Oleh karena itu, ia harus mengirim UNDANGAN baru dengan header Replaces, yang mengidentifikasi sesi yang ada.
Note - Misalkan A & B keduanya dalam panggilan dan jika A mendapat UNDANGAN lain (katakanlah dari C) dengan tajuk pengganti (harus cocok dengan dialog yang ada), maka A harus menerima UNDANG dan mengakhiri sesi dengan B dan mentransfer semua sumber daya ke dialog yang baru terbentuk.
Alur panggilan ditunjukkan pada Gambar berikut. Ini mirip dengan aliran panggilan sebelumnya menggunakan re-INVITE kecuali bahwa BYE secara otomatis dibuat untuk menghentikan dialog yang ada saat UNDANGAN dengan Mengganti diterima.
Diberikan di bawah ini adalah poin yang perlu diperhatikan dalam skenario ini -
Dialog yang ada antara Tom dan Jerry menyertakan server proxy lama yang dikunjungi.
Dialog baru yang menggunakan jaringan nirkabel baru memerlukan penyertaan server proxy yang baru dikunjungi.
Akibatnya, UNDANGAN dengan Mengganti dikirim oleh Tom, yang membuat dialog baru yang menyertakan server proxy baru yang dikunjungi tetapi bukan server proxy lama yang dikunjungi.
Ketika Jerry menerima UNDANGAN, BYE secara otomatis dikirim untuk menghentikan dialog lama yang merutekan melalui server proxy lama yang dikunjungi yang sekarang tidak lagi terlibat dalam sesi.
Sesi media yang dihasilkan dibuat menggunakan alamat IP baru Tom dari SDP di INVITE.
Mobilitas Layanan
Layanan di SIP dapat disediakan di proxy atau di UA. Menyediakan layanan mobilitas bersama dengan mobilitas pribadi dapat menjadi tantangan kecuali perangkat pengguna dikonfigurasi secara identik dengan layanan yang sama.
SIP dapat dengan mudah mendukung mobilitas layanan melalui Internet. Saat tersambung ke Internet, UA yang dikonfigurasi untuk menggunakan sekumpulan proxy di India masih dapat menggunakan proxy tersebut saat roaming di Eropa. Ini tidak berdampak pada kualitas sesi media karena media selalu mengalir langsung antara dua UA dan tidak melintasi server proxy SIP.
Layanan residen titik akhir hanya tersedia jika titik akhir terhubung ke Internet. Layanan penghentian seperti layanan penerusan panggilan yang diterapkan di titik akhir akan gagal jika titik akhir kehilangan koneksi Internet untuk sementara. Oleh karena itu beberapa layanan diimplementasikan di jaringan menggunakan server proxy SIP.
Kadang-kadang server proxy meneruskan satu panggilan SIP ke beberapa titik akhir SIP. Proses ini dikenal sebagai forking. Di sini, satu panggilan dapat membunyikan banyak titik akhir pada saat yang bersamaan.
Dengan SIP forking, Anda dapat membuat telepon meja Anda berdering pada saat yang sama dengan softphone atau telepon SIP di ponsel Anda, memungkinkan Anda untuk menerima panggilan dari salah satu perangkat dengan mudah.
Umumnya, di kantor, misalkan atasan tidak dapat mengangkat panggilan atau pergi, SIP forking memungkinkan sekretaris untuk menjawab panggilan ekstensi-nya.
Forking akan dimungkinkan jika ada proxy stateful yang tersedia karena ia perlu melakukan dan merespons dari banyak proxy yang diterimanya.
Kami memiliki dua jenis garpu -
- Forking Paralel
- Forking Berurutan
Forking Paralel
Dalam skenario ini, server proxy akan membagi INVITE ke, misalnya, dua perangkat (UA2, UA3) pada satu waktu. Kedua perangkat akan menghasilkan 180 Dering dan siapa pun yang menerima panggilan akan menghasilkan 200 OK. Respons (misalkan UA2) yang mencapai Originator pertama kali akan membuat sesi dengan UA2. Untuk tanggapan lainnya, BATAL akan dipicu.
Jika originator menerima kedua respon tersebut secara bersamaan, maka berdasarkan q-value, ia akan meneruskan respon tersebut.
Forking Berurutan
Dalam skenario ini, server proxy akan membagi UNDANG ke satu perangkat (UA2). Jika UA2 tidak tersedia atau sibuk pada saat itu, maka proxy akan memindahkannya ke perangkat lain (UA3).
Cabang - ID dan Tag
ID cabang membantu proxy mencocokkan respons untuk permintaan bercabang. Tanpa ID Cabang, server proxy tidak akan dapat memahami respons bercabang. Branch-id akan tersedia di header Via.
Tag digunakan oleh UAC untuk membedakan beberapa tanggapan akhir dari UAS yang berbeda. UAS tidak dapat menyelesaikan apakah permintaan telah bercabang atau tidak. Oleh karena itu perlu ditambahkan tag.
Proxy juga dapat menambahkan tag jika menghasilkan respons akhir, mereka tidak pernah memasukkan tag ke dalam permintaan atau respons yang diteruskannya.
Mungkin saja satu permintaan dapat bercabang oleh beberapa server proxy juga. Jadi proxy yang akan bercabang harus menambahkan ID uniknya sendiri ke cabang yang dibuatnya.
Kaki panggilan dan ID Panggilan
Kaki panggilan mengacu pada hubungan pensinyalan satu ke satu antara dua agen pengguna. ID panggilan adalah pengenal unik yang dibawa dalam pesan SIP yang merujuk ke panggilan tersebut. Panggilan adalah kumpulan kaki panggilan.
UAC dimulai dengan mengirimkan UNDANGAN. Karena bercabang, mungkin menerima beberapa 200 OK dari UA yang berbeda. Masing-masing berhubungan dengan bagian panggilan yang berbeda dalam panggilan yang sama.
Dengan demikian, panggilan adalah sekelompok kaki panggilan. Kaki panggilan mengacu pada koneksi ujung ke ujung antara UA.
Ruang CSeq di dua arah kaki panggilan bersifat independen. Dalam satu arah, nomor urut bertambah untuk setiap transaksi.
Pesan suara
Pesan suara sangat umum sekarang-a-hari untuk pengguna perusahaan. Ini aplikasi telepon. Muncul gambaran ketika pihak yang dipanggil tidak tersedia atau tidak dapat menerima panggilan, PBX akan mengumumkan kepada pihak yang menelepon untuk meninggalkan pesan suara.
Agen pengguna akan mendapatkan respons 3xx atau dialihkan ke server pesan suara jika nomor pihak yang dipanggil tidak dapat dihubungi. Namun demikian, beberapa jenis ekstensi SIP diperlukan untuk menunjukkan ke sistem pesan suara kotak surat mana yang akan digunakan — yaitu, salam yang akan diputar dan di mana menyimpan pesan yang direkam. Ada dua cara untuk mencapai ini -
Dengan menggunakan ekstensi bidang header SIP
Dengan menggunakan Request-URI untuk memberi sinyal informasi ini
Misalkan untuk pengguna sip:[email protected] memiliki sistem pesan suara di sip: voicemail.tutorialspoint.com yang menyediakan pesan suara, Permintaan-URI dari UNDANGAN ketika diteruskan ke server pesan suara bisa terlihat seperti -
sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486
Ilustrasi berikut memperlihatkan bagaimana Request-URI membawa pengenal kotak surat dan alasannya (di sini 486).
Seperti yang kita ketahui, server proxy dapat berupa stateless atau stateful. Di sini, di bab ini, kita akan membahas lebih lanjut tentang server proxy dan perutean SIP.
Server Proksi Tanpa Status
Server proxy tanpa negara hanya meneruskan pesan yang diterimanya. Jenis server ini tidak menyimpan informasi panggilan atau transaksi apa pun.
- Proksi tanpa status melupakan permintaan SIP setelah diteruskan.
- Transaksi akan cepat melalui proxy tanpa kewarganegaraan.
Server Proxy Stateful
Server proxy yang stateful melacak setiap permintaan dan respons yang diterimanya. Itu dapat menggunakan informasi yang disimpan di masa depan, jika diperlukan. Itu dapat mengirim ulang permintaan jika tidak menerima respon dari pihak lain.
Proksi stateful mengingat permintaan setelah diteruskan, sehingga mereka dapat menggunakannya untuk perutean lanjutan. Proksi berstatus mempertahankan status transaksi . Transaksi menyiratkan status transaksi,notpanggilan negara .
Transaksi tidak secepat proxy stateful seperti stateless.
Proksi stateful dapat melakukan fork dan retransmit jika diperlukan (misalnya: call forward busy, misalnya).
Melalui dan Rekam-rute
Rekor-Rute
Header Record-Route dimasukkan ke dalam permintaan oleh proxy yang ingin berada di jalur permintaan selanjutnya untuk call-id yang sama. Ini kemudian digunakan oleh agen pengguna untuk mengarahkan permintaan berikutnya.
Melalui
Melalui header dimasukkan oleh server ke dalam permintaan untuk mendeteksi loop dan untuk membantu tanggapan menemukan jalan kembali ke klien. Ini berguna hanya untuk tanggapan untuk mencapai tujuan mereka.
UA sendiri membuat dan menambahkan alamatnya sendiri di bidang header Via saat mengirim permintaan.
Sebuah proxy yang meneruskan permintaan menambahkan kolom header Via yang berisi alamatnya sendiri ke bagian atas daftar kolom header Via.
Proksi atau UA yang menghasilkan respons untuk permintaan menyalin semua bidang header Via dari permintaan untuk menjadi respons, kemudian mengirimkan respons ke alamat yang ditentukan di bidang header Via atas.
Proksi yang menerima tanggapan memeriksa bidang header Via atas dan mencocokkan alamatnya sendiri. Jika tidak cocok, respons telah dibuang.
Bidang header Via atas kemudian dihapus, dan tanggapan diteruskan ke alamat yang ditentukan di bidang header Via berikutnya.
Melalui kolom header berisi nama protokol, nomor versi, dan transportasi (SIP / 2.0 / UDP, SIP / 2.0 / TCP, dll.) Dan berisi nomor port dan parameter seperti yang diterima, rport, cabang.
Tag yang diterima ditambahkan ke bidang header Via jika UA atau proxy menerima permintaan dari alamat yang berbeda dari yang ditentukan di bidang header Via atas.
Parameter cabang ditambahkan ke kolom header Via oleh UA dan proxy, yang dihitung sebagai fungsi hash dari Request-URI, dan nomor To, From, Call-ID, dan CSeq.
SIP (Softphone) dan PSTN (Telepon lama) keduanya adalah jaringan yang berbeda dan berbicara dalam bahasa yang berbeda. Jadi kami membutuhkan penerjemah (Gateway di sini) untuk berkomunikasi antara dua jaringan ini.
Mari kita ambil contoh untuk menunjukkan bagaimana telepon SIP melakukan panggilan telepon ke PSTN melalui gateway PSTN.
Dalam contoh ini, Tom (sip:[email protected]) adalah telepon sip dan Jerry menggunakan nomor telepon global +91401234567.
SIP ke PSTN melalui Gateway
Ilustrasi berikut menunjukkan aliran panggilan dari SIP ke PSTN melalui gateway.
Diberikan di bawah ini adalah penjelasan langkah demi langkah dari semua proses yang terjadi saat melakukan panggilan dari telepon SIP ke PSTN.
Pertama-tama, telepon (Tom) SIP menghubungi nomor global +91401234567 untuk menghubungi Jerry. Agen pengguna SIP memahaminya sebagai nomor global dan mengubahnya menjadi request-uri menggunakan DNS dan memicu permintaan tersebut.
Telepon SIP mengirimkan UNDANG langsung ke gateway.
Gateway memulai panggilan ke PSTN dengan memilih trunk SS7 ISUP ke saklar telepon berikutnya di PSTN.
Digit keluar dari INVITE dipetakan ke dalam ISUP IAM. Pesan lengkap alamat ISUP (ACM) dikirim kembali oleh PSTN untuk menunjukkan bahwa bagasi telah dibuat.
Telepon menghasilkan nada dering dan beralih ke saklar telepon. Gateway memetakan ACM ke respons 183 Session Progress yang berisi SDP yang menunjukkan port RTP yang akan digunakan gateway untuk menjembatani audio dari PSTN.
Setelah menerima 183, UAC pemanggil mulai menerima paket RTP yang dikirim dari gateway dan menyajikan audio ke pemanggil sehingga mereka tahu bahwa panggilan berjalan di PSTN.
Panggilan selesai ketika pihak yang dipanggil menjawab telepon, yang menyebabkan saklar telepon mengirim pesan jawaban (ANM) ke gateway.
Gateway kemudian memotong sambungan audio PSTN di kedua arah dan mengirimkan respons 200 OK ke pemanggil. Karena jalur media RTP sudah dibuat, gateway menjawab SDP di 183 tetapi tidak menyebabkan perubahan pada sambungan RTP.
UAC mengirimkan ACK untuk menyelesaikan pertukaran pensinyalan SIP. Karena tidak ada pesan yang setara di ISUP, gateway menyerap ACK.
Penelepon mengirimkan BYE ke gateway untuk mengakhiri. Gateway memetakan BYE ke dalam pesan rilis ISUP (REL).
Gateway mengirimkan 200OK ke BYE dan menerima RLC dari PSTN.
Codec, kependekan dari coder-decoder, melakukan dua operasi dasar -
Pertama, itu mengubah sinyal suara analog ke bentuk digital yang setara sehingga dapat dengan mudah ditransmisikan.
Setelah itu, ia mengubah sinyal digital yang dikompresi kembali ke bentuk analog aslinya sehingga dapat diputar ulang.
Ada banyak codec yang tersedia di pasaran - beberapa gratis sementara yang lain membutuhkan lisensi. Codec bervariasi dalam kualitas suara dan bandwidth yang sesuai.
Perangkat keras seperti telepon dan gateway mendukung beberapa codec yang berbeda. Saat berbicara satu sama lain, mereka menegosiasikan codec mana yang akan mereka gunakan.
Di sini, di bab ini, kita akan membahas beberapa codec audio SIP populer yang banyak digunakan.
G.711
G.711 adalah codec yang diperkenalkan oleh ITU pada tahun 1972 untuk digunakan pada telepon digital. Codec ini memiliki dua varian:A-Law sedang digunakan di Eropa dan dalam hubungan telepon internasional, uLaw digunakan di AS dan Jepang.
G.711 menggunakan kompresi logaritmik. Ini meremas setiap sampel 16-bit menjadi 8 bit, sehingga mencapai rasio kompresi 1: 2.
Bitrate-nya 64 kbit / s untuk satu arah, jadi sebuah panggilan menghabiskan 128 kbit / s.
G.711 adalah codec yang sama yang digunakan oleh jaringan PSTN, sehingga memberikan kualitas suara terbaik. Namun itu mengkonsumsi lebih banyak bandwidth daripada codec lain.
Ini bekerja paling baik di jaringan area lokal di mana kami memiliki banyak bandwidth yang tersedia.
G.729
G.729 adalah codec dengan kebutuhan bandwidth rendah; ini memberikan kualitas audio yang bagus.
Codec mengkodekan audio dalam bingkai dengan panjang 10 ms. Diberikan frekuensi sampling 8 kHz, frame 10 ms berisi 80 sampel audio.
Algoritma codec mengkodekan setiap frame menjadi 10 byte, sehingga bitrate yang dihasilkan adalah 8 kbit / s dalam satu arah.
G.729 adalah codec berlisensi. Pengguna akhir yang ingin menggunakan codec ini harus membeli perangkat keras yang mengimplementasikannya (baik itu telepon VoIP atau gateway).
Varian yang sering digunakan dari G.729 adalah G.729a. Ini kompatibel dengan kabel dengan codec asli tetapi memiliki persyaratan CPU yang lebih rendah.
G.723.1
G.723.1 adalah hasil kompetisi yang diumumkan ITU dengan tujuan merancang codec yang memungkinkan panggilan melalui sambungan modem 28,8 dan 33 kbit / s.
Kami memiliki dua varian G.723.1. Keduanya beroperasi pada frame audio 30 ms (yaitu 240 sampel), tetapi algoritmanya berbeda.
Bitrate varian pertama adalah 6,4 kbit / s, sedangkan untuk varian kedua 5,3 kbit / s.
Frame yang dikodekan untuk kedua varian masing-masing memiliki panjang 24 dan 20 byte.
GSM 06.10
GSM 06.10 adalah codec yang dirancang untuk jaringan seluler GSM. Ini juga dikenal sebagai GSM Full Rate.
Varian codec GSM ini dapat digunakan secara bebas, sehingga Anda akan sering menemukannya pada aplikasi VoIP open source.
Codec beroperasi pada frame audio sepanjang 20 ms (yaitu 160 sampel) dan memampatkan setiap frame menjadi 33 byte, sehingga bitrate yang dihasilkan adalah 13 kbit /.
Agen pengguna back-to-back (B2BUA) adalah elemen jaringan logis dalam aplikasi SIP. Ini adalah jenis SIP UA yang menerima permintaan SIP, kemudian merumuskan kembali permintaan tersebut, dan mengirimkannya sebagai permintaan baru.
Tidak seperti server proxy, ia mempertahankan status dialog dan harus berpartisipasi dalam semua permintaan yang dikirim pada dialog yang dibuatnya. B2BUA mematahkan sifat SIP ujung-ke-ujung.
B2BUA - Bagaimana Cara Kerjanya?
Agen B2BUA beroperasi di antara dua titik akhir panggilan telepon dan membagi saluran komunikasi menjadi dua call legs. B2BUA adalah gabungan dari UAC dan UAS. Ini berpartisipasi dalam semua sinyal SIP antara kedua ujung panggilan, itu telah ditetapkan. Karena B2BUA tersedia di penyedia layanan dialog mungkin menerapkan beberapa fitur nilai tambah.
Di kaki panggilan asal, B2BUA bertindak sebagai server agen pengguna (UAS) dan memproses permintaan sebagai klien agen pengguna (UAC) ke ujung tujuan, menangani pensinyalan antara titik akhir secara berurutan.
B2BUA mempertahankan status lengkap untuk panggilan yang ditangani. Setiap sisi B2BUA beroperasi sebagai elemen jaringan SIP standar sebagaimana ditentukan dalam RFC 3261.
Fungsi B2BUA
B2BUA menyediakan fungsi-fungsi berikut -
Manajemen panggilan (penagihan, pemutusan panggilan otomatis, transfer panggilan, dll.)
Jaringan interworking (mungkin dengan adaptasi protokol)
Menyembunyikan internal jaringan (alamat pribadi, topologi jaringan, dll.)
Seringkali, B2BUA juga diimplementasikan di gateway media untuk menjembatani aliran media untuk kontrol penuh atas sesi tersebut.
Contoh B2BUA
Banyak sistem telepon perusahaan private branch exchange (PBX) menggabungkan logika B2BUA.
Beberapa firewall telah dibangun dengan fungsionalitas ALG (Application Layer Gateway), yang memungkinkan firewall untuk mengotorisasi SIP dan lalu lintas media sambil tetap mempertahankan tingkat keamanan yang tinggi.
Jenis B2BUA umum lainnya dikenal sebagai Session Border Controller (SBC).