Persyaratan infrastruktur perutean langsung Azure

  • Artikel

Artikel ini menjelaskan detail konektivitas infrastruktur, lisensi, dan Pengontrol Batas Sesi (SBC) yang ingin Anda ingat saat merencanakan penyebaran perutean langsung Azure Anda.

Persyaratan infrastruktur

Persyaratan infrastruktur untuk SBC, domain, dan persyaratan konektivitas jaringan lainnya yang didukung untuk menyebarkan perutean langsung Azure tercantum dalam tabel berikut:

Persyaratan infrastruktur Anda memerlukan yang berikut ini
Pengontrol Batas Sesi (SBC) SBC yang didukung. Untuk informasi selengkapnya, lihat SBC yang didukung.
Batang telefoni yang terhubung ke SBC Satu atau beberapa batang telefoni yang terhubung ke SBC. Di satu ujung, SBC terhubung ke Azure Communication Service melalui perutean langsung. SBC juga dapat terhubung ke entitas telepon pihak ketiga, seperti PBX, Adaptor Telepon Analog. Setiap opsi konektivitas Public Switched Telephony Network (PSTN) yang terhubung ke SBC berfungsi. (Untuk konfigurasi batang PSTN ke SBC, lihat vendor SBC atau penyedia batang.)
Langganan Azure Langganan Azure yang Anda gunakan untuk membuat sumber daya Communication Services, serta konfigurasi dan koneksi ke SBC.
Token Akses Communication Services Untuk melakukan panggilan, Anda memerlukan Token Akses yang valid dengan cakupan voip. Lihat Token Akses
Alamat IP publik untuk SBC Alamat IP publik yang dapat digunakan untuk terhubung ke SBC. Berdasarkan jenis SBC, SBC dapat menggunakan NAT.
Nama Domain yang Sepenuhnya Memenuhi Syarat (FQDN) untuk SBC Untuk informasi selengkapnya, lihat Sertifikat SBC dan nama domain.
Entri DNS publik untuk SBC Entri DNS publik yang memetakan SBC FQDN ke alamat IP publik.
Sertifikat tepercaya publik untuk SBC Sertifikat untuk SBC yang akan digunakan untuk semua komunikasi dengan perutean langsung Azure. Untuk informasi selengkapnya, lihat Sertifikat SBC dan nama domain.
Alamat IP dan port firewall untuk sinyal dan media SIP SBC berkomunikasi dengan layanan berikut di cloud:

Proksi SIP, yang menangani sinyal
Prosesor Media, yang menangani media

Kedua layanan ini memiliki alamat IP terpisah di Microsoft Cloud, yang dijelaskan nanti dalam dokumen ini.

Sertifikat SBC dan nama domain

Microsoft menyarankan agar Anda meminta sertifikat untuk SBC dengan permintaan penandatanganan sertifikasi (CSR). Untuk instruksi khusus tentang cara menghasilkan CSR untuk SBC, lihat instruksi interkoneksi atau dokumentasi yang disediakan oleh vendor SBC Anda.

Catatan

Sebagian besar Otoritas Sertifikat (CA) mengharuskan ukuran kunci privat setidaknya 2048. Ingatlah hal ini saat Anda membuat CSR.

Sertifikat harus memiliki SBC FQDN sebagai nama umum (CN) atau bidang nama alternatif subjek (SAN). Sertifikat harus dikeluarkan langsung dari otoritas sertifikasi, bukan penyedia perantara.

Atau, perutean langsung Communication Services mendukung wildcard di CN dan/atau SAN, dan wildcard harus sesuai dengan HTTP RFC standar Melalui TLS.

Pelanggan yang sudah menggunakan Office 365 dan memiliki domain yang terdaftar di pusat Admin Microsoft 365 dapat menggunakan SBC FQDN dari domain yang sama.

Contohnya adalah menggunakan *.contoso.com, yang akan cocok dengan SBC FQDNsbc.contoso.com, tetapi tidak akan cocok dengan sbc.test.contoso.com.

Catatan

SBC FQDN dalam perutean langsung Azure Communication Services harus berbeda dari SBC FQDN di Perutean Langsung Teams.

Communication Services hanya mempercayai sertifikat yang ditandatangani oleh Otoritas Sertifikat (CA) yang merupakan bagian dari Program Sertifikat Akar Tepercaya Microsoft. Pastikan bahwa sertifikat SBC Anda ditandatangani oleh CA yang merupakan bagian dari program, dan ekstensi Extended Key Usage (EKU) sertifikat Anda menyertakan Autentikasi Server. Selengkapnya:

Persyaratan Program — Program Akar Tepercaya Microsoft

Daftar Sertifikat CA yang Disertakan

Penting

Perutean langsung Azure Communication Services hanya mendukung TLS 1.2. Untuk menghindari dampak layanan apa pun, pastikan bahwa SBC Anda dikonfigurasi untuk mendukung TLS1.2 dan dapat terhubung menggunakan salah satu suite sandi berikut untuk sinyal SIP:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 yaitu ECDHE-RSA-AES256-GCM-SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 yaitu ECDHE-RSA-AES128-GCM-SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 yaitu ECDHE-RSA-AES256-SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 yaitu ECDHE-RSA-AES128-SHA256

Untuk media SRTP hanya AES_CM_128_HMAC_SHA1_80 yang didukung.

Pemasangan SBC berfungsi pada tingkat sumber daya Communication Services. Ini berarti Anda dapat memasangkan banyak SBC ke satu sumber daya Communication Services. Namun, Anda tidak dapat memasangkan satu SBC ke lebih dari satu sumber daya Communication Services. SBC FQDN yang unik diperlukan untuk memasangkan ke sumber daya yang berbeda.

Jika dukungan Mutual TLS (MTLS) diaktifkan untuk koneksi perutean langsung pada SBC, maka Anda harus menginstal Baltimore CyberTrust Root dan sertifikat DigiCert Global Root G2 di SBC Trusted Root Store dari konteks TLS perutean langsung. (Ini karena sertifikat layanan Microsoft menggunakan salah satu dari dua sertifikat akar ini.) Untuk mengunduh sertifikat akar ini, lihat Rantai Enkripsi Office 365. Untuk informasi selengkapnya, lihat Perubahan Sertifikat Office TLS.

Sinyal SIP: FQDN

Titik koneksi untuk perutean langsung Communication Services adalah tiga FQDN berikut:

  • sip.pstnhub.microsoft.com — FQDN Global — harus dicoba terlebih dahulu. Saat SBC mengirim permintaan untuk mengatasi nama ini, server Microsoft Azure DNS mengembalikan alamat IP yang menunjuk ke pusat data Azure utama yang ditetapkan ke SBC. Penugasan didasarkan pada metrik performa pusat data dan kedekatan geografis dengan SBC. Alamat IP yang dikembalikan sesuai dengan FQDN utama.
  • sip2.pstnhub.microsoft.com — FQDN Sekunder — secara geografis memetakan ke wilayah prioritas kedua.
  • sip3.pstnhub.microsoft.com — FQDN Tersier — secara geografis memetakan ke wilayah prioritas ketiga.

Ketiga FQDN ini diperlukan untuk:

  • Memberikan pengalaman optimal (dimuat lebih sedikit dan paling dekat dengan pusat data SBC yang ditetapkan dengan mengkueri FQDN pertama).
  • Menyediakan failover ketika koneksi dari SBC dibuat ke pusat data yang mengalami masalah sementara. Untuk informasi selengkapnya, lihat Mekanisme failover.

FQDN — sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com, dan sip3.pstnhub.microsoft.com — selesaikan ke salah satu alamat IP berikut:

  • 52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
  • 52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

Buka port firewall untuk semua rentang alamat IP ini untuk memungkinkan lalu lintas masuk dan keluar ke dan dari alamat untuk pemberian sinyal.

Sinyal SIP: Port

Gunakan port berikut untuk perutean langsung Azure Communication Services:

Lalu lintas Dari Untuk Port Sumber Port tujuan
SIP/TLS Proksi SIP SBC 1024–65535 Ditentukan pada SBC
SIP/TLS SBC Proksi SIP Ditentukan pada SBC 5061

Mekanisme failover untuk Sinyal SIP

SBC membuat kueri DNS untuk menyelesaikan sip.pstnhub.microsoft.com. Berdasarkan lokasi SBC dan metrik performa pusat data, pusat data utama dipilih. Jika pusat data utama mengalami masalah, SBC mencoba sip2.pstnhub.microsoft.com, yang diselesaikan ke pusat data kedua yang ditetapkan, dan, dalam kasus yang jarang terjadi bahwa pusat data di dua wilayah tidak tersedia, SBC mencoba kembali FQDN terakhir (sip3.pstnhub.microsoft.com), yang menyediakan IP pusat data tersier.

Lalu lintas media: Rentang IP dan Port

Lalu lintas media mengalir ke dan dari layanan terpisah yang disebut Prosesor Media. Rentang alamat IP untuk lalu lintas media sama dengan untuk sinyal:

  • 52.112.0.0/14 (IP addresses from 52.112.0.0 to 52.115.255.255)
  • 52.120.0.0/14 (IP addresses from 52.120.0.0 to 52.123.255.255)

Rentang port

Rentang port Prosesor Media diperlihatkan dalam tabel berikut:

Lalu lintas Dari Untuk Port Sumber Port tujuan
UDP/SRTP Prosesor Media SBC 49152–53247 Ditentukan pada SBC
UDP/SRTP SBC Prosesor Media Ditentukan pada SBC 49152–53247

Catatan

Microsoft menyarankan setidaknya dua port per panggilan bersamaan pada SBC.

Lalu lintas media: Geografi prosesor media

Prosesor Media ditempatkan di pusat data yang sama dengan proksi SIP:

  • NOAM (US Selatan Tengah, dua di pusat data AS Barat dan US Timur)
  • Eropa (UE Barat, UE Utara, Swedia, Prancis Tengah)
  • Asia (pusat data Singapura)
  • Jepang (pusat data JP Timur dan Barat)
  • Australia (pusat data AU Timur and Tenggara)
  • LATAM (Brasil Selatan)
  • Afrika (Afrika Selatan Utara)

Lalu lintas media: Codec

Kaki antara SBC dan Cloud Media Processor.

Antarmuka perutean langsung Azure pada bagian antara Pengontrol Batas Sesi dan Prosesor Media Cloud dapat menggunakan codec berikut:

  • SILK, G.711, G.722, G.729

Anda dapat memaksa penggunaan codec tertentu pada Pengontrol Batas Sesi dengan mengecualikan codec yang tidak diinginkan dari penawaran.

Bagian antara aplikasi SDK Panggilan Communication Services dan Prosesor Media Cloud

Pada bagian antara Prosesor Media Cloud dan aplikasi SDK Panggilan Communication Services, G.722 digunakan. Bekerja untuk menambahkan lebih banyak codec pada kaki ini sedang berlangsung.

Pengontrol Batas Sesi (SBC) yang didukung

Langkah berikutnya

Dokumentasi konseptual

Mulai cepat