Persyaratan infrastruktur perutean langsung Azure

Penting

Fungsionalitas yang dijelaskan dalam dokumen ini saat ini berada dalam pratinjau publik. Versi pratinjau ini disediakan tanpa perjanjian tingkat layanan, dan tidak disarankan untuk beban kerja produksi. Fitur tertentu mungkin tidak didukung atau mungkin memiliki kemampuan terbatas. Untuk mengetahui informasi selengkapnya, lihat Ketentuan Penggunaan Tambahan untuk Pratinjau Microsoft Azure.

Artikel ini menjelaskan detail infrastruktur, lisensi, dan konektivitas Pengontrol Batas Sesi (SBC) yang ingin Anda ingat sebagai rencana 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 telefoni pihak ketiga, seperti PBX, Adaptor Telefoni Analog, dan sebagainya. Opsi konektivitas PSTN apa pun yang terhubung ke SBC akan berfungsi. (Untuk konfigurasi batang PSTN ke SBC, lihat vendor SBC atau penyedia batang.)
Langganan Azure Langganan Azure yang Anda gunakan untuk membuat sumber daya Layanan Komunikasi, dan konfigurasi serta 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 FQDN untuk SBC, tempat bagian domain FQDN tidak cocok dengan domain terdaftar di organisasi Microsoft 365 atau Office 365 Anda. Untuk informasi selengkapnya, lihat Nama domain SBC.
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 tepercaya publik untuk SBC.
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.

Nama domain SBC

Pelanggan tanpa Office 365 bisa menggunakan nama domain apa pun yang sertifikat publiknya bisa mereka peroleh.

Tabel berikut ini memperlihatkan contoh nama DNS yang terdaftar untuk penyewa, apakah nama tersebut dapat digunakan sebagai nama domain yang sepenuhnya memenuhi syarat (FQDN) untuk SBC, dan contoh nama FQDN yang valid:

Nama DNS Dapat digunakan untuk SBC FQDN Contoh nama FQDN
contoso.com Ya Nama yang valid:
sbc1.contoso.com
ssbcs15.contoso.com
europe.contoso.com
contoso.onmicrosoft.com Tidak Penggunaan domain *.onmicrosoft.com tidak didukung untuk nama SBC

Jika Anda adalah pelanggan Office 365, nama domain SBC tidak boleh cocok dengan yang terdaftar di Domain penyewa Office 365. Di bawah ini adalah contoh koeksistensi Office 365 dan Azure Communication Service:

Domain yang terdaftar di Office 365 Contoh SBC FQDN dalam Teams Contoh nama SBC FQDN di Azure Communication Services
contoso.com (domain tingkat kedua) sbc.contoso.com (nama di domain tingkat kedua) sbc.acs.contoso.com (nama di domain tingkat ketiga)
sbc.fabrikam.com (nama apa pun dalam domain berbeda)
o365.contoso.com (domain tingkat ketiga) sbc.o365.contoso.com (nama di domain tingkat ketiga) sbc.contoso.com (nama di domain tingkat kedua)
sbc.acs.o365.contoso.com (nama di domain tingkat keempat)
sbc.fabrikam.com (nama apa pun dalam domain berbeda)

Pasangan SBC bekerja pada tingkat sumber daya Communication Services, yang berarti Anda dapat memasangkan banyak SBC ke satu sumber daya Communication Services, tetapi 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.

Sertifikat tepercaya publik untuk SBC

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

Catatan

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

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

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

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

Sertifikat perlu dibuat oleh salah satu otoritas sertifikat akar berikut:

  • AffirmTrust
  • AddTrust External CA Root
  • Baltimore CyberTrust Root*
  • Buypass
  • Cybertrust
  • Class 3 Public Primary Certification Authority
  • Comodo Secure Root CA
  • Deutsche Telekom
  • DigiCert Global Root CA
  • DigiCert High Assurance EV Root CA
  • Entrust
  • GlobalSign
  • Go Daddy
  • GeoTrust
  • Verisign, Inc.
  • SSL.com
  • Starfield
  • Symantec Enterprise Mobile Root for Microsoft
  • SwissSign
  • Thawte Timestamping CA
  • Trustwave
  • TeliaSonera
  • T-Systems International GmbH (Deutsche Telekom)
  • QuoVadis
  • Otoritas Sertifikasi RSA USERTrust
  • Hongkong Post Root CA 1,2,3
  • Sectigo Root CA

Microsoft sedang berupaya menambahkan lebih banyak otoritas sertifikasi berdasarkan permintaan pelanggan.

Sinyal SIP: FQDN

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

  • sip.pstnhub.microsoft.com – FQDN Global – harus dicoba terlebih dulu. Ketika SBC mengirim permintaan untuk menjelaskan nama ini, server DNS Microsoft Azure 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 Ketiga – secara geografis memetakan ke wilayah prioritas ketiga.

Menempatkan ketiga FQDN ini secara berurutan 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 di bawah ini.

FQDN – sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com, dan sip3.pstnhub.microsoft.com – akan dijelaskan di salah satu alamat IP berikut:

  • 52.112.0.0/14 (IP addresses from 52.112.0.1 to 52.115.255.254)
  • 52.120.0.0/14 (IP addresses from 52.120.0.1 to 52.123.255.254)

Buka port firewall untuk semua rentang alamat IP ini untuk memungkinkan lalu lintas masuk dan keluar ke dan dari alamat untuk pemberian sinyal. Jika firewall Anda mendukung nama DNS, FQDN sip-all.pstnhub.microsoft.com menyelesaikan semua alamat IP ini.

Sinyal SIP: Port

Gunakan port berikut untuk perutean langsung Azure Communication Services:

Lalu lintas Dari Ke Port sumber Port tujuan
SIP/TLS Proksi SIP SBC 1024 – 65535 Ditentukan pada SBC (For Office 365 GCC High/DoD, hanya port 5061 yang harus digunakan)
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 akan mencoba sip2.pstnhub.microsoft.com, yang menyelesaikan ke pusat data kedua yang ditetapkan, dan, dalam kasus yang jarang terjadi ketika pusat data di dua wilayah tidak tersedia, SBC mencoba kembali FQDN terakhir (sip3.pstnhub.microsoft.com), yang menyediakan IP pusat data ketiga.

Lalu lintas media: Rentang IP dan Port

Lalu lintas media mengalir ke dan dari layanan terpisah yang disebut Prosesor Media. Pada saat penerbitan, Prosesor Media untuk Communication Services dapat menggunakan alamat IP Azure apa pun. Unduh daftar lengkap alamat.

Rentang porta

Rentang port Prosesor Media diperlihatkan dalam tabel berikut ini:

Lalu lintas Dari Ke Port sumber Port tujuan
UDP/SRTP Prosesor Media SBC 3478-3481 dan 49152 – 53247 Ditentukan pada SBC
UDP/SRTP SBC Prosesor Media Ditentukan pada SBC 3478-3481 dan 49152 – 53247

Catatan

Microsoft menyarankan setidaknya dua port per panggilan bersamaan pada SBC.

Lalu lintas media: Geografi prosesor media

Lalu lintas media mengalir melalui komponen yang disebut prosesor media. Prosesor media ditempatkan di pusat data yang sama dengan proksi SIP. Selain itu, ada prosesor media tambahan untuk mengoptimalkan aliran media. Misalnya, kami saat ini tidak memiliki komponen proksi SIP di Australia (SIP mengalir melalui Singapura atau Hong Kong), tetapi kami memiliki prosesor media secara lokal di Australia. Kebutuhan akan prosesor media secara lokal ditentukan oleh latensi yang kami alami ketika mengirim lalu lintas jarak jauh, misalnya dari Australia ke Singapura atau Hong Kong. Meskipun latensi dalam contoh lalu lintas yang mengalir dari Australia ke Hong Kong atau Singapura dapat diterima untuk menjaga kualitas panggilan yang baik untuk lalu lintas SIP, tetapi hal tersebut tidak berlaku untuk lalu lintas media real time.

Lokasi tempat komponen proksi SIP dan prosesor media disebarkan:

  • AS (dua di pusat data US Barat dan US Timur)
  • Eropa (pusat data Amsterdam dan Dublin)
  • Asia (pusat data Singapura dan Hong Kong)
  • Australia (pusat data AU Timur and Tenggara)

Lokasi tempat hanya prosesor media yang disebarkan (SIP mengalir melalui pusat data terdekat yang tercantum di atas):

  • Jepang (pusat data JP Timur dan Barat)

Lalu lintas media: Codec

Bagian antara SBC dan Prosesor Media Cloud atau klien Microsoft Teams.

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. Microsoft sedang berupaya menambahkan lebih banyak codec pada bagian ini.

Pengontrol Batas Sesi (SBC) yang didukung

Langkah berikutnya

Dokumentasi konseptual

Mulai cepat