Topologi alur panggilan

Artikel ini menjelaskan topologi alur panggilan Azure Communication Services. Dalam artikel ini, Anda mempelajari detail tentang konsep jaringan untuk Azure Communication Services, cara memanggil lalu lintas dienkripsi, dan Untuk pengenalan alur panggilan Communication Services, kunjungi dokumentasi konseptual alur panggilan.

Latar belakang

Konsep jaringan

Sebelum meninjau topologi alur panggilan, kami menentukan beberapa istilah yang disebut di seluruh dokumen.

Jaringan pelanggan berisi segmen jaringan apa pun yang Anda kelola. Jaringan ini mungkin termasuk jaringan kabel dan nirkabel di dalam kantor Anda atau di antara kantor, pusat data, serta penyedia layanan internet.

Jaringan pelanggan biasanya memiliki beberapa perimeter jaringan dengan firewall dan/atau server proxy yang menerapkan kebijakan keamanan organisasi Anda. Sebaiknya lakukan penilaian jaringan komprehensif untuk memastikan performa dan kualitas yang optimal dari solusi komunikasi Anda.

Jaringan Communication Services adalah jaringan yang mendukung Azure Communication Services. Jaringan ini dikelola oleh Microsoft dan didistribusikan di seluruh dunia dengan pusat data milik Microsoft yang paling dekat dengan pelanggan akhir. Jaringan ini bertanggung jawab untuk relai transportasi, pemrosesan media untuk panggilan grup, dan komponen lain yang mendukung komunikasi media real time yang kaya.

Jenis lalu lintas

Communication Services dibangun terutama pada dua jenis lalu lintas: media real time dan sinyal.

Media real time ditransmisikan menggunakan Protokol Transportasi Real Time (RTP). Protokol ini mendukung transmisi data audio, video, dan berbagi layar. Data ini sensitif terhadap masalah latensi jaringan. Meskipun memungkinkan untuk mengirimkan media real time menggunakan TCP atau HTTP, sebaiknya gunakan UDP sebagai protokol lapisan transportasi untuk mendukung pengalaman pengguna akhir berperforma tinggi. Payload media yang ditransmisikan melalui RTP diamankan menggunakan SRTP.

Pengguna solusi Communication Services Anda terhubung ke layanan Anda dari perangkat klien mereka. Komunikasi antara perangkat ini dan server Anda ditangani dengan sinyal. Misalnya: inisiasi panggilan dan obrolan real time didukung oleh sinyal antara perangkat dan layanan Anda. Sebagian besar lalu lintas sinyal menggunakan HTTPS REST, meskipun dalam beberapa skenario, SIP dapat digunakan sebagai protokol lalu lintas sinyal. Meskipun jenis lalu lintas ini kurang sensitif terhadap latensi, sinyal latensi rendah memberi pengguna solusi Anda pengalaman pengguna akhir yang menyenangkan.

Enkripsi Media

Alur panggilan di klien SDK panggilan Azure Communication Services dan Teams didasarkan pada model penawaran dan jawaban Protokol Deskripsi Sesi (SDP) RFC 8866 melalui HTTPS. Setelah penerima panggilan menerima panggilan masuk, pemanggil dan penerima panggilan menyetujui parameter sesi.

Lalu lintas media dienkripsi, dan mengalir antara, penelepon dan penerima panggilan menggunakan Secure RTP (SRTP), profil Protokol Transportasi Real-time (RTP) yang memberikan kerahasiaan, autentikasi, dan perlindungan serangan pemutaran ulang ke lalu lintas RTP. Dalam kebanyakan kasus, lalu lintas klien ke media klien dinegosiasikan melalui sinyal koneksi klien ke server, dan dienkripsi menggunakan SRTP saat langsung dari klien ke klien.

SDK panggilan Azure Communication Services menggunakan DTLS untuk mendapatkan kunci enkripsi. Setelah jabat tangan DTLS selesai, media mulai mengalir menggunakan kunci enkripsi yang dinegosiasikan DTLS ini melalui SRTP.

Klien SDK dan Teams panggilan Azure Communication Services menggunakan token berbasis kredensial untuk akses aman ke relai media melalui TURN. Relai media menukar token melalui saluran yang diamankan TLS.

Lalu lintas media Azure Communication Services antara dua titik akhir yang berpartisipasi dalam berbagi audio, video, dan video Azure Communication Services menggunakan SRTP untuk mengenkripsi aliran media. Kunci kriptografi dinegosiasikan antara dua titik akhir melalui protokol sinyal, yang menggunakan saluran UDP/TCP terenkripsi TLS 1.2 dan AES-256 (dalam mode GCM).

Prinsip alur panggilan

Ada empat prinsip umum yang mendasari alur panggilan Azure Communication Services:

• Peserta pertama panggilan grup Communication Services menentukan wilayah tempat panggilan dihost. Ada pengecualian untuk aturan ini di beberapa topologi, yang dijelaskan di bawah ini.
• Titik akhir media yang digunakan untuk mendukung panggilan Communication Services dipilih berdasarkan kebutuhan pemrosesan media, dan tidak terpengaruh oleh jumlah peserta pada panggilan. Misalnya, panggilan titik ke titik dapat menggunakan titik akhir media di cloud untuk memproses media untuk transkripsi atau perekaman, sementara panggilan dengan dua peserta mungkin tidak menggunakan titik akhir media apa pun. Panggilan grup menggunakan titik akhir media untuk tujuan pencampuran dan perutean. Titik akhir ini dipilih berdasarkan wilayah tempat panggilan dihost. Lalu lintas media yang dikirim dari klien ke titik akhir media dapat dirutekan secara langsung atau dapat menggunakan relai transportasi di Azure jika pembatasan firewall jaringan pelanggan memerlukannya.
• Lalu lintas media untuk panggilan peer-to-peer mengambil rute paling langsung yang tersedia, dengan asumsi panggilan tidak memerlukan titik akhir media di cloud. Rute yang disukai langsung ke serekan jarak jauh (klien). Jika rute langsung tidak tersedia, satu atau beberapa transportasi akan meneruskan lalu lintas. Lalu lintas media seharusnya tidak melintasi server yang bertindak seperti pembentuk paket, server VPN, atau fungsi lain yang mungkin menunda pemrosesan dan menurunkan pengalaman pengguna akhir.
• Lalu lintas sinyal selalu masuk ke server apa pun yang paling dekat dengan pengguna.

Untuk mempelajari selengkapnya tentang detail di jalur media yang dipilih, lihat dokumentasi konseptual alur panggilan.

Alur panggilan di berbagai topologi

Communication Services (internet)

Topologi ini digunakan oleh pelanggan yang menggunakan Communication Services dari cloud tanpa penyebaran lokal apa pun, seperti perutean langsung Azure. Dalam topologi ini, lalu lintas ke dan dari Communication Services mengalir melalui Internet.

Gambar 1 - Topologi Communication Services

Arah panah pada diagram di atas mencerminkan arah inisiasi komunikasi yang memengaruhi konektivitas di perimeter perusahaan. Dalam kasus UDP untuk media, paket pertama dapat mengalir ke arah sebaliknya, tetapi paket-paket ini dapat diblokir sampai paket ke arah lain mengalir.

Deskripsi alur:

• Alur 2 – Mewakili alur yang dimulai oleh pengguna di jaringan pelanggan ke Internet sebagai bagian dari pengalaman Communication Services pengguna. Contoh aliran ini termasuk transmisi DNS dan media peer-to-peer.
• Alur 2' - Mewakili alur yang dimulai oleh pengguna Communication Services seluler jarak jauh, dengan VPN ke jaringan pelanggan.
• Alur 3 - Mewakili alur yang dimulai oleh pengguna Communication Services seluler jarak jauh ke titik akhir Communication Services.
• Alur 4 - Mewakili alur yang dimulai oleh pengguna di jaringan pelanggan ke Communication Services.
• Alur 5 - Mewakili alur media peer-to-peer antara satu pengguna Communication Services dan pengguna lainnya dalam jaringan pelanggan.
• Alur 6 - Mewakili alur media peer-to-peer antara pengguna Communication Services seluler jarak jauh dan pengguna Communication Services seluler jarak jauh lainnya melalui Internet.

Kasus penggunaan: Panggilan satu ke satu

Panggilan satu-ke-satu berarti satu pengguna langsung memanggil pengguna lain. Untuk menginisialisasi panggilan, SDK panggilan mendapatkan sekumpulan kandidat yang terdiri dari alamat IP dan port, termasuk kandidat lokal, relai, dan refleksif (alamat IP publik klien seperti yang dilihat oleh relai). Penelepon SDK mengirimkan kandidat ini ke pihak yang dipanggil; pihak yang dipanggil juga mendapatkan sekumpulan kandidat yang sama dan mengirimkannya ke pemanggil. Pesan pemeriksaan konektivitas STUN digunakan untuk menemukan jalur media pihak pemanggil/yang dipanggil mana yang berfungsi, dan jalur kerja terbaik dipilih. Setelah jalur koneksi dibuat, jabat tangan DTLS dilakukan melalui koneksi ini untuk memastikan keamanan. Setelah jabat tangan DTLS, kunci SRTP berasal dari proses jabat tangan DTLS. Media (yaitu, paket RTP/RTCP yang diamankan menggunakan SRTP) selanjutnya dikirim menggunakan pasangan kandidat terpilih. Relai transportasi tersedia sebagai bagian dari Azure Communication Services.

Jika alamat IP lokal dan kandidat port atau kandidat refleksif memiliki konektivitas, maka jalur langsung antara klien (atau menggunakan NAT) dipilih untuk media. Jika klien sama-sama berada di jaringan pelanggan, jalur langsung akan dipilih. Konektivitas UDP langsung dalam jaringan pelanggan diperlukan. Jika klien sama-sama pengguna cloud nomaden, bergantung pada NAT/firewall, media dapat menggunakan konektivitas langsung.

Jika satu klien internal di jaringan pelanggan dan satu klien bersifat eksternal (misalnya, pengguna cloud seluler), maka tidak mungkin konektivitas langsung antara kandidat lokal atau refleksif akan diaktifkan. Dalam hal ini, opsinya adalah menggunakan salah satu kandidat relai transportasi dari salah satu klien (misalnya, klien internal memperoleh kandidat relai dari relai transportasi di Azure; klien eksternal harus dapat mengirim paket STUN/RTP/RTCP ke relai transportasi). Opsi lain adalah klien internal mengirim ke kandidat relai yang diperoleh klien cloud seluler. Meskipun konektivitas UDP untuk media sangat disarankan, TCP didukung.

Langkah-langkah tingkat tinggi:

1. Pengguna Communication Services A menentukan nama domain URL (DNS) menggunakan Alur 2.
2. Pengguna A mengalokasikan port relai media pada relai transportasi Teams menggunakan Alur 4.
3. Pengguna Communication Services A mengirimkan "undangan" dengan kandidat ICE menggunakan Alur 4 ke Communication Services.
4. Communication Services memberi tahu Pengguna B menggunakan Alur 4.
5. Pengguna B mengalokasikan port relai media pada relai transportasi Teams menggunakan Alur 4.
6. Pengguna B mengirimkan "jawaban" dengan kandidat ICE menggunakan Alur 4, yang diteruskan kembali ke Pengguna A menggunakan Alur 4.
7. Pengguna A dan Pengguna B memanggil uji konektivitas ICE serta jalur media terbaik yang tersedia dipilih (lihat diagram di bawah ini untuk berbagai kasus penggunaan).
8. Kedua pengguna mengirimkan telemetri ke Communication Services menggunakan Alur 4.

Jaringan pelanggan (intranet)

Gambar 2 - Dalam jaringan pelanggan

Di Langkah 7, Alur 5 media peer-to-peer dipilih.

Transmisi media ini bersifat dua arah. Arah Alur 5 menunjukkan satu sisi memulai komunikasi dari perspektif konektivitas. Dalam hal ini, tidak masalah arah mana yang digunakan karena kedua titik akhir berada dalam jaringan pelanggan.

Jaringan pelanggan ke pengguna eksternal (media yang diteruskan oleh Teams Transport Relay)

Gambar 3 - Jaringan pelanggan ke pengguna eksternal (media yang diteruskan oleh Azure Transport Relay)

Di Langkah 7, Alur 4 (dari jaringan pelanggan ke Communication Services) dan Alur 3 (dari pengguna Communication Services seluler jarak jauh ke Azure Communication Services) dipilih.

Alur ini diteruskan oleh Teams Transport Relay dalam Azure.

Transmisi media ini bersifat dua arah. Arah menunjukkan satu sisi mana yang memulai komunikasi dari perspektif konektivitas. Dalam hal ini, aliran ini digunakan untuk sinyal dan media, menggunakan protokol dan alamat transportasi yang berbeda.

Jaringan pelanggan ke pengguna eksternal (media langsung)

Gambar 4 - Jaringan pelanggan ke pengguna eksternal (media langsung)

Di langkah 7, Alur 2 (dari jaringan pelanggan ke serekan melalui Internet klien) dipilih.

Media langsung dengan pengguna seluler jarak jauh (tidak diteruskan melalui Azure) bersifat opsional. Dengan kata lain, Anda dapat memblokir jalur ini untuk menerapkan jalur media melalui relai transportasi di Azure.

Transmisi media ini bersifat dua arah. Arah Alur 2 ke pengguna seluler jarak jauh menunjukkan satu sisi memulai komunikasi dari perspektif konektivitas.

Pengguna VPN ke pengguna internal (media yang diteruskan oleh Teams Transport Relay)

Gambar 5 - Pengguna VPN ke pengguna internal (media yang diteruskan oleh Azure Relay

Sinyal antara VPN ke jaringan pelanggan menggunakan Alur 2*. Sinyal antara jaringan pelanggan dan Azure menggunakan Alur 4. Namun, media melewati VPN dan dirutekan menggunakan Alur 3 dan 4 melalui Azure Media Relay.

Pengguna VPN ke pengguna internal (media langsung)

Gambar 6 - Pengguna VPN ke pengguna internal (media langsung)

Sinyal antara VPN ke jaringan pelanggan menggunakan Alur 2'. Sinyal antara jaringan pelanggan dan Azure menggunakan alur 4. Namun, media melewati VPN dan dirutekan menggunakan aliran 2 dari jaringan pelanggan ke Internet.

Transmisi media ini bersifat dua arah. Arah Alur 2 ke pengguna seluler jarak jauh menunjukkan satu sisi memulai komunikasi dari perspektif konektivitas.

Pengguna VPN ke pengguna eksternal (media langsung)

Gambar 7 - Pengguna VPN ke pengguna eksternal (media langsung)

Sinyal antara pengguna VPN ke jaringan pelanggan menggunakan Alur 2* dan Alur 4 ke Azure. Namun, media melewati VPN dan dirutekan menggunakan Alur 6.

Transmisi media ini bersifat dua arah. Arah Alur 6 ke pengguna seluler jarak jauh menunjukkan satu sisi memulai komunikasi dari perspektif konektivitas.

Kasus Penggunaan: Klien Communication Services ke PSTN melalui Batang Communication Services

Communication Services memungkinkan untuk menempatkan dan menerima panggilan dari Jaringan Telepon Tetap (PSTN). Jika batang PSTN terhubung menggunakan nomor telepon yang disediakan oleh Communication Services, tidak ada persyaratan konektivitas khusus untuk kasus penggunaan ini. Jika Anda ingin menyambungkan batang PSTN lokal Anda sendiri ke Azure Communication Services, Anda dapat menggunakan perutean langsung Azure (tersedia di CY2021).

Gambar 8 - Pengguna Communication Services ke PSTN melalui Azure Trunk

Dalam hal ini, sinyal dan media dari jaringan pelanggan ke Azure menggunakan Alur 4.

Kasus penggunaan: Panggilan grup Communication Services

Layanan berbagi audio/video/layar (VBSS) adalah bagian dari Azure Communication Services. Layanan ini memiliki alamat IP publik yang harus dapat dijangkau dari jaringan pelanggan dan harus dapat dijangkau dari klien Nomadic Cloud. Setiap klien/titik akhir harus dapat terhubung ke layanan.

Klien internal mendapatkan kandidat lokal, refleksif, dan relai dengan cara yang sama seperti yang dijelaskan untuk panggilan satu-ke-satu. Klien mengirim kandidat ini ke layanan dalam undangan. Layanan ini tidak menggunakan relai karena memiliki alamat IP yang dapat dijangkau secara publik, sehingga merespons dengan kandidat alamat IP lokalnya. Klien dan layanan memeriksa konektivitas dengan cara yang sama yang dijelaskan untuk panggilan satu ke satu.

Gambar 9 – Panggilan Grup Communication Services

Pembatasan interoperabilitas

Media yang mengalir melalui Azure Communication Services dibatasi sebagai berikut:

Pengontrol Batas Sesi (SBC) pihak ketiga pada batas dengan PSTN harus mengakhiri aliran RTP/RTCP, diamankan menggunakan SRTP, dan tidak menyampaikannya ke hop berikutnya. Jika Anda meneruskan aliran ke lompatan berikutnya, aliran mungkin tidak dipahami.

Server proxy SIP pihak ketiga. Dialog SIP sinyal Communication Services dengan SBC dan/atau gateway pihak ketiga dapat melintasi proxy SIP asli Microsoft (sama seperti Teams). Interoperabilitas dengan proksi SIP pihak ketiga tidak didukung.

B2BUA (atau SBC) pihak ketiga. Aliran media Communication Services ke dan dari PSTN dihentikan oleh SBC pihak ketiga. Interoperabilitas dengan SBC pihak ketiga dalam jaringan Communication Services (di mana SBC pihak ketiga menengahi dua titik akhir Communication Services) tidak didukung.

Teknologi yang tidak didukung

Jaringan VPN. Communication Services tidak mendukung transmisi media melalui VPN. Jika pengguna Anda menggunakan klien VPN, klien harus membagi dan merutekan lalu lintas media melalui koneksi non-VPN seperti yang ditentukan di Mengaktifkan media Lync untuk melewati tunnel VPN.

Catatan

Meskipun judul menunjukkan Lync, judul tersebut berlaku untuk Azure Communication Services dan Teams.*

Pembentuk paket. Perangkat pemotong paket, inspeksi paket, atau pembentuk paket tidak didukung dan dapat menurunkan kualitas secara signifikan.

Langkah berikutnya

Mulai menggunakan panggilan

Dokumen berikut mungkin menarik bagi Anda:

• Pelajari lebih lanjut jenis panggilan
• Pelajari lebih lanjut Arsitektur server klien