Perutean langsung Azure Communication Services: Detail protokol SIP

Artikel ini menjelaskan bagaimana perutean langsung menerapkan Protokol Inisiasi Sesi (SIP) untuk memastikan rute lalu lintas yang tepat antara Pengontrol Batas Sesi (SBC) dan proksi SIP. Ini juga menyoroti pentingnya parameter SIP tertentu yang memerlukan nilai tertentu. Artikel ini ditujukan untuk administrator suara yang bertanggung jawab untuk mengonfigurasi koneksi antara SBC dan layanan proksi SIP.

Memproses permintaan masuk: menemukan sumber daya Communication Services

Catatan

Di Azure Communication Services opsi perutean langsung SIP diaktifkan secara default dan tidak dapat dinonaktifkan. SBC harus memulai pertukaran OPTIONS terlebih dahulu, karena Proksi SIP menunggu SBC untuk memulai pertukaran.

Sebelum panggilan masuk atau keluar dapat diproses, pesan OPTIONS ditukar antara Proksi SIP dan SBC. Pesan OPTIONS ini memungkinkan Proksi SIP untuk menyediakan kemampuan yang diizinkan ke SBC. Penting bagi negosiasi OPTIONS agar berhasil (respons 200 OK), memungkinkan komunikasi lebih lanjut antara SBC dan Proksi SIP untuk membuat panggilan. Header SIP dalam pesan OPTIONS ke Proksi SIP disediakan sebagai contoh:

Nama Parameter	Contoh nilai
Request-URI	OPTIONS sip:sip.pstnhub.microsoft.com:5061 SIP /2.0
Melalui Header	Melalui: sbc1.contoso.com:5061 SIP/2.0/TLS; Alias; branch=z9hG4bKac2121518978
Header Max-Forwards	Max-Forwards:68
Dari Header	Dari Header Dari: sip:sbc1.contoso.com:5061
Ke Header	Ke: sip:sip.pstnhub.microsoft.com:5061
Header CSeq	CSeq: 1 UNDANGAN
Header Kontak	Kontak: sip:sbc1.contoso.com:5061; transport=tls

Catatan

Header SIP tidak berisi userinfo dalam URI SIP yang digunakan. Sesuai RFC 3261, bagian 19.1.1, bagian userinfo dari URI bersifat opsional dan mungkin tidak ada ketika host tujuan tidak memiliki gagasan tentang pengguna atau ketika host itu sendiri adalah sumber daya yang diidentifikasi. Jika tanda @ ada di URI SIP, bidang pengguna tidak boleh kosong. Harap dicatat, bahwa SIPS URI tidak boleh digunakan dengan perutean langsung karena tidak didukung. Periksa konfigurasi Pengontrol Batas Sesi Anda dan pastikan Anda tidak menggunakan header "Ganti" dalam permintaan SIP. Perutean langsung akan menolak permintaan SIP yang telah menggantikan header yang ditentukan.

Pada panggilan masuk, proksi SIP perlu menemukan sumber daya Azure Communication tempat panggilan ditujukan. Bagian ini menjelaskan bagaimana proksi SIP menemukan sumber daya, dan melakukan autentikasi SBC pada koneksi masuk.

Contoh pesan Undangan SIP pada panggilan masuk:

Nama Parameter	Contoh nilai
Request-URI	INVITE sip:+54321@sip.pstnhub.microsoft.com SIP /2.0
Melalui Header	Melalui: sbc1.contoso.com:5061 SIP/2.0/TLS; Alias; branch=z9hG4bKac2121518978
Header Max-Forwards	Max-Forwards:68
Dari Header	Dari Header Dari: <sip:+12345@sbc1.contoso.com; transport=udp; tag=1c68821811
Ke Header	Untuk: sip:+54321@sbc1.contoso.com
Header CSeq	CSeq: 1 UNDANGAN
Header Kontak	Kontak: sip:+12345@sbc1.contoso.com:5061; transport=tls

Saat menerima undangan, proksi SIP melakukan langkah-langkah berikut:

1. Periksa sertifikat. Pada koneksi awal, layanan perutean langsung mengambil nama FQDN yang disajikan di header Kontak dan mencocokkannya dengan Nama Umum atau Nama Alternatif Subjek dari sertifikat yang disajikan. Nama SBC harus cocok dengan salah satu opsi berikut:

   • Opsi 1. Nama FQDN lengkap yang disajikan di header Kontak harus cocok dengan Nama Umum/Nama Alternatif Subjek dari sertifikat yang disajikan.

   • Opsi 2. Bagian domain dari nama FQDN yang disajikan di header Kontak (misalnya contoso.com nama FQDN sbc1.contoso.com) harus cocok dengan nilai kartubebas dalam Nama Umum/Nama Alternatif Subjek (misalnya *.contoso.com).

2. Cobalah untuk menemukan penyewa Microsoft 365 menggunakan nama FQDN lengkap yang disajikan di header Kontak.

   Periksa apakah nama FQDN dari header Kontak (sbc1.contoso.com) terdaftar sebagai nama DNS di organisasi Microsoft 365 atau Office 365 mana pun. Jika ditemukan, pencarian pengguna dilakukan di penyewa yang memiliki SBC FQDN yang terdaftar sebagai Nama domain. Jika tidak ditemukan, Langkah 3 berlaku.

3. Cobalah untuk menemukan sumber daya Azure Communication menggunakan nama FQDN lengkap yang disajikan di header Kontak.

   Periksa apakah nama FQDN dari header Kontak (sbc1.contoso.com) terdaftar sebagai FQDN SBC di sumber daya Azure Communication apa pun. Jika ditemukan, panggilan dikirim ke sumber daya tersebut. Jika tidak ditemukan, Langkah 4 berlaku.

4. Langkah 4 hanya berlaku jika Langkah 2 dan 3 gagal.

   Hapus bagian host dari FQDN, yang disajikan di header Kontak (FQDN: sbc1.contoso.com, setelah menghapus bagian host: contoso.com), dan periksa apakah nama ini terdaftar sebagai nama DNS di organisasi Microsoft 365 atau Office 365 mana pun. Jika ditemukan, pencarian pengguna dilakukan di penyewa ini. Jika tidak ditemukan, panggilan gagal.

5. Langkah 5 hanya berlaku jika Langkah 2, 3, dan 4 gagal.

   Hapus bagian host dari FQDN, yang disajikan di header Kontak (FQDN: sbc1.contoso.com, setelah menghapus bagian host: contoso.com), dan periksa apakah nama ini terdaftar sebagai SBC FQDN di sumber daya Azure Communication apa pun. Jika ditemukan, panggilan dikirim ke sumber daya tersebut. Jika tidak ditemukan, panggilan gagal.

6. Jika sumber daya memiliki penyebaran Dynamics Omnichannel yang terkait, lakukan pencarian nomor telepon yang disajikan dalam Request-URI. Cocokkan nomor telepon yang disajikan dengan pengguna Multisaluran (antrean) yang ditemukan pada langkah sebelumnya.

7. Langkah 7 hanya berlaku jika Langkah 6 gagal.

   Jika tidak ada penyebaran Multisaluran untuk sumber daya Komunikasi, atau nomor di Request-URI tidak cocok dengan nomor Multisaluran yang dikonfigurasi, kirim panggilan ke Event Grid.

8. Langkah 8 hanya berlaku jika Langkah 7 gagal.

   Jika Event Grid tidak dikonfigurasi, atau tidak ada aturan untuk mengelola panggilan masuk, panggilan akan dihentikan.

Persyaratan terperinci untuk header Kontak dan Request-URI

Header kontak

Untuk semua pesan SIP masuk (OPTIONS, INVITE) ke proksi Microsoft SIP, header Kontak harus memiliki SBC FQDN yang dipasangkan di nama host URI sebagai berikut:

Sintaks: Kontak: <sip:phone atau sip address@FQDN SBC; transport=tls>

Sesuai RFC 3261, bagian 11.1, bidang Header kontak mungkin ada dalam pesan OPTIONS. Dalam perutean langsung, header kontak diperlukan. Ketika datang ke pesan OPTIONS, userinfo dapat dikecualikan dari URI SIP dan hanya FQDN yang dapat dikirim dalam format berikut:

Sintaks: Kontak: <sip:FQDN dari SBC; transport=tls>

Nama ini (FQDN) juga harus berada di bidang Nama Umum atau Nama Alternatif Subjek dari sertifikat yang disajikan. Microsoft mendukung penggunaan nilai kartubebas nama di bidang Nama Umum atau Nama Alternatif Subjek sertifikat. Dukungan untuk wildcard dijelaskan dalam RFC 2818, bagian 3.1. Khususnya:

"Nama mungkin berisi karakter kartubebas *, yang dianggap cocok dengan komponen nama domain tunggal atau fragmen komponen. Misalnya, *.a.com cocok dengan foo.a.com tetapi tidak bar.foo.a.com. f*.com cocok dengan foo.com tetapi tidak bar.com."

Jika lebih dari satu nilai di header Kontak yang disajikan dalam pesan SIP oleh SBC, hanya bagian FQDN dari nilai pertama header Kontak yang digunakan. Sebagai aturan praktis untuk perutean langsung, penting bahwa FQDN digunakan untuk mengisi URI SIP alih-alih IP. Pesan UNDANGAN atau OPSI masuk ke Proksi SIP dengan header Kontak di mana nama host diwakili oleh IP dan bukan FQDN, koneksi ditolak dengan 403 Terlarang.

Request-URI

Untuk semua panggilan masuk, Request-URI digunakan untuk mengidentifikasi penerima panggilan. Saat ini nomor telepon harus berisi tanda plus (+) seperti yang ditunjukkan dalam contoh berikut.

INVITE sip:+12345@sip.pstnhub.microsoft.com SIP /2.0

Dari header

Untuk semua panggilan masuk, Header Dari digunakan untuk mencocokkan nomor telepon penelepon.

Nomor telepon harus berisi + seperti yang ditunjukkan dalam contoh berikut.

From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811

Pertimbangan header Kontak dan Rute Rekaman

Proksi SIP perlu menghitung FQDN hop berikutnya untuk transaksi klien baru dalam dialog (misalnya Bye atau Undang Ulang), dan saat membalas OPSI SIP. Ini dapat dilakukan menggunakan Kontak atau Rekam-Rute. Menurut RFC 3261, bagian 8.1.1.8, header Kontak diperlukan dalam permintaan apa pun yang dapat menghasilkan dialog baru. Record-Route hanya diperlukan jika proksi ingin tetap berada di jalur permintaan di masa mendatang dalam dialog.

Untuk menghitung hop berikutnya, proksi SIP menggunakan:

• Prioritas 1. Rute Rekam tingkat atas. Jika Record-Route tingkat atas berisi nama FQDN, nama FQDN digunakan untuk membuat koneksi dalam dialog keluar.

• Prioritas 2. Header kontak. Jika Record-Route tidak ada, proksi SIP mencari nilai header Kontak untuk membuat koneksi keluar. (Konfigurasi yang disarankan.)

Jika Kontak dan Rute Rekaman digunakan, administrator SBC harus menjaga nilainya tetap identik, yang menyebabkan overhead administratif.

Penggunaan nama FQDN di Kontak atau Rute Rekaman

Penggunaan alamat IP tidak didukung di Record-Route atau Contact. Satu-satunya opsi yang didukung adalah FQDN, yang harus cocok dengan Nama Umum atau Nama Alternatif Subjek sertifikat SBC (nilai kartubebas dalam sertifikat didukung).

• Jika alamat IP disajikan dalam Record-route atau Contact, pemeriksaan sertifikat gagal, dan panggilan gagal.

• Jika FQDN tidak cocok dengan nilai Nama Alternatif Umum atau Subjek dalam sertifikat yang disajikan, panggilan gagal.

Memanggil header konteks

Header konteks panggilan saat ini hanya tersedia untuk Call Automation SDK. SDK Automation Panggilan mendukung header Pengguna-Ke-Pengguna dan hingga lima header SIP kustom. Header tersebut didukung dalam metode INVITE dan REFER.

Header Pengguna-ke-Pengguna

Header Pengguna ke Pengguna (UUI) SIP adalah standar industri untuk meneruskan informasi kontekstual selama proses penyiapan panggilan. Panjang maksimum kunci header UUI adalah 64 karakter. Panjang maksimum nilai header UUI adalah 256 karakter. Nilai header UUI mungkin terdiri dari karakter alfanumerik dan beberapa simbol yang dipilih, termasuk =, , , .!;, %, *, _, +, , ~. -

Header kustom

Azure Communication Services juga mendukung hingga lima header SIP kustom. Kunci header SIP kustom harus dimulai dengan awalan wajib X-MS-Custom- . Panjang maksimum kunci header SIP adalah 64 karakter, termasuk awalan X-MS-Custom- . Kunci header SIP mungkin terdiri dari karakter alfanumerik dan beberapa simbol yang dipilih, termasuk ., , !, %*, _, +, , ~. - Panjang maksimum nilai header SIP adalah 256 karakter. Nilai header SIP mungkin terdiri dari karakter alfanumerik dan beberapa simbol yang dipilih, termasuk =, , , .;!, %, *, , _, +, , . -~

Untuk detail implementasi, lihat Cara meneruskan data kontekstual antar panggilan.

Panggilan masuk: Deskripsi dialog SIP

Berikut adalah detail cara Proksi SIP memproses panggilan masuk.

Nama Parameter	Nilai
Kandidat media dalam 183 dan 200 pesan yang berasal dari	Prosesor media
Jumlah 183 pesan yang dapat diterima SBC	Satu per sesi
Panggilan dapat dengan jawaban provisi (183)	Ya
Panggilan bisa tanpa jawaban provisi (183)	Ya

Identitas Azure Communication Services mungkin digunakan di beberapa titik akhir (aplikasi) secara bersamaan. Misalnya, aplikasi web, aplikasi i Telepon, dan aplikasi Android. Setiap titik akhir mungkin memberi sinyal titik akhir HTTP sebagai berikut:

• Kemajuan panggilan - dikonversi oleh proksi SIP ke pesan SIP 180. Saat menerima pesan 180, SBC harus menghasilkan dering lokal.

• Jawaban media - dikonversi oleh proksi SIP ke pesan 183 dengan kandidat media dalam Session Description Protocol (SDP). Pada menerima pesan 183, SBC mengharapkan untuk terhubung ke kandidat media yang diterima dalam pesan SDP.

  Catatan

  Dalam beberapa kasus, jawaban Media mungkin tidak dihasilkan, dan titik akhir mungkin menjawab dengan pesan "Panggilan Diterima".

• Panggilan diterima - dikonversi oleh proksi SIP ke pesan SIP 200 dengan SDP. Pada menerima pesan 200, SBC diharapkan untuk mengirim dan menerima media ke dan dari kandidat SDP yang disediakan.

  Catatan

  Perutean langsung tidak mendukung Undangan Penawaran Tertunda (Undang tanpa SDP).

Beberapa titik akhir berdering dengan jawaban provisi

1. Saat menerima Undangan pertama dari SBC, proksi SIP mengirimkan pesan "SIP SIP/2.0 100 Mencoba" dan memberi tahu semua titik akhir pengguna akhir tentang panggilan masuk.

2. Setelah pemberitahuan, setiap titik akhir mulai berdering dan mengirim pesan "Kemajuan panggilan" ke proksi SIP. Karena identitas Azure Communication Services digunakan oleh beberapa titik akhir, proksi SIP mungkin menerima beberapa pesan Kemajuan Panggilan.

3. Untuk setiap pesan Kemajuan Panggilan yang diterima dari titik akhir, proksi SIP mengonversi pesan Kemajuan Panggilan ke pesan SIP "SIP SIP/2.0 180 Dering". Interval untuk mengirim pesan tersebut berkorelasi dengan interval pesan penerima dari Pengontrol Panggilan. Dalam diagram berikut, ada dua pesan 180 yang dihasilkan oleh proksi SIP. Pesan-pesan ini berasal dari dua titik akhir SDK. Titik akhir masing-masing memiliki ID Tag yang unik. Setiap pesan yang berasal dari titik akhir yang berbeda adalah sesi terpisah (parameter "tag" di bidang "Ke" berbeda). Tetapi titik akhir mungkin tidak menghasilkan pesan 180 dan langsung mengirim pesan 183 seperti yang ditunjukkan dalam diagram berikut.

4. Setelah titik akhir menghasilkan pesan Jawaban Media dengan alamat IP kandidat media titik akhir, proksi SIP mengonversi pesan yang diterima ke pesan "Kemajuan Sesi SIP 183" dengan SDP dari titik akhir yang digantikan oleh SDP dari Prosesor Media. Dalam diagram berikut, titik akhir dari Fork 2 menjawab panggilan. Pesan SIP 183 dihasilkan hanya sekali. 183 mungkin datang pada fork yang ada atau memulai yang baru.

5. Pesan Penerimaan Panggilan dikirim ke Proksi SIP dengan kandidat akhir titik akhir yang menerima panggilan. Pesan Penerimaan Panggilan dikonversi ke pesan SIP 200.

   

Beberapa titik akhir berdering tanpa jawaban provisi

1. Saat menerima Undangan pertama dari SBC, proksi SIP mengirimkan pesan "SIP SIP/2.0 100 Mencoba" dan memberi tahu semua titik akhir pengguna akhir tentang panggilan masuk.

2. Setelah pemberitahuan, setiap titik akhir mulai berdering dan mengirim pesan "Progres panggilan" ke proksi SIP. Karena identitas Azure Communication Services yang sama dapat digunakan dalam beberapa aplikasi, proksi SIP mungkin menerima beberapa pesan Kemajuan Panggilan.

3. Untuk setiap pesan Kemajuan Panggilan yang diterima dari titik akhir, proksi SIP mengonversi pesan Kemajuan Panggilan ke pesan SIP "SIP SIP/2.0 180 Dering". Interval untuk mengirim pesan berkorelasi dengan interval penerimaan pesan dari Pengontrol Panggilan. Pada gambar ada dua pesan 180 yang dihasilkan oleh proksi SIP, yang berarti bahwa panggilan di-fork ke dua klien yang berbeda dan setiap klien mengirim kemajuan panggilan. Setiap pesan adalah sesi terpisah (parameter "tag" di bidang "Ke" berbeda)

4. Pesan Penerimaan Panggilan dikirim ke Proksi SIP dengan kandidat akhir titik akhir yang menerima panggilan. Pesan Penerimaan Panggilan dikonversi ke pesan SIP 200.

   

Opsi ganti

SBC harus mendukung INVITE dengan Replaces.

Ukuran pertimbangan SDP

Antarmuka perutean langsung mungkin mengirim pesan SIP yang melebihi 1.500 byte. Ukuran SDP terutama menyebabkan perilaku tersebut. Namun, jika ada batang UDP di belakang SBC, itu mungkin menolak pesan jika diteruskan dari proksi Microsoft SIP ke bagasi yang tidak dimodifikasi. Microsoft merekomendasikan untuk menghapus beberapa nilai dalam SDP pada SBC saat mengirim pesan ke batang UDP. Misalnya, kandidat ICE atau codec yang tidak digunakan dapat dihapus.

Transfer panggilan

Perutean langsung mendukung dua metode untuk transfer panggilan:

• Opsi 1. Proses proksi SIP Merujuk dari klien secara lokal dan bertindak sebagai Wasit seperti yang dijelaskan dalam bagian 7.1 RFC 3892.

  Dengan opsi ini, proksi SIP mengakhiri transfer dan menambahkan Undangan baru.

• Opsi 2. Proksi SIP mengirimkan Lihat SBC dan bertindak sebagai Transferor sebagaimana digambarkan dalam Bagian 6 RFC 5589.

  Dengan opsi ini, proksi SIP mengirimkan Lihat SBC dan mengharapkan SBC menangani Transfer sepenuhnya.

Proksi SIP memilih metode berdasarkan kemampuan yang dilaporkan oleh SBC. Jika SBC menunjukkan bahwa SBC mendukung metode "Rujuk", proksi SIP menggunakan Opsi 2 untuk transfer panggilan. Contoh SBC yang mengirim pesan bahwa metode Rujuk didukung:

ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Jika SBC tidak menunjukkan bahwa Rujuk sebagai metode yang didukung, perutean langsung menggunakan Opsi 1 (proksi SIP bertindak sebagai Wasit). SBC juga harus memberi sinyal bahwa SBC mendukung metode Beri Tahu: Contoh SBC yang menunjukkan bahwa metode Rujuk tidak didukung:

ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS

Proses proksi SIP Merujuk dari klien secara lokal dan bertindak sebagai wasit

Jika SBC menunjukkan bahwa metode Referensi tidak didukung, proksi SIP bertindak sebagai wasit. Permintaan Rujuk yang berasal dari klien berakhir pada proksi SIP. Permintaan Referensi dari klien ditampilkan sebagai "Transfer panggilan ke Dave" dalam diagram berikut. Untuk informasi selengkapnya, lihat bagian 7.1 dari RFC 3892.

Proksi SIP mengirimkan Lihat SBC dan bertindak sebagai transferor

Proksi SIP sebagai transferor adalah metode yang disukai untuk transfer panggilan.

Standar dijelaskan dalam Bagian 6 RFC 5589. RFC terkait adalah:

• Kontrol Panggilan Protokol Inisiasi Sesi (SIP) - Transfer

• Header "Ganti" Protokol Inisiasi Sesi (SIP)

• Mekanisme Protokol Inisiasi Sesi (SIP) "Dirujuk Oleh"

Opsi ini mengasumsikan bahwa proksi SIP bertindak sebagai transferor dan mengirim pesan Rujuk ke SBC. SBC bertindak sebagai penerima transfer dan menangani Referensi untuk menghasilkan penawaran baru untuk transfer. Ada dua kemungkinan kasus:

• Panggilan ditransfer ke peserta PSTN eksternal.
• Panggilan ditransfer dari satu titik akhir SDK ke titik akhir SDK lain di sumber daya yang sama melalui SBC.

Jika panggilan ditransfer dari satu titik akhir SDK ke titik akhir SDK lain melalui SBC, SBC diharapkan mengeluarkan Undangan baru (mulai dialog baru) untuk target transfer menggunakan informasi yang diterima dalam pesan Rujuk. Untuk mengisi bidang Kepada/Transferor untuk transaksi permintaan secara internal, proksi SIP perlu menyampaikan informasi ini di dalam header REFER-TO/REFERRED-BY. Proksi SIP membentuk REFER-TO sebagai URI SIP yang terdiri dari FQDN proksi SIP di nama host dan:

• Nomor telepon E.164 di bagian nama pengguna URI jika target transfer adalah nomor telepon, atau

• Parameter x-m dan x-t yang mengodekan target transfer penuh MRI dan ID sumber daya Komunikasi masing-masing.

Header REFERRED-BY memiliki URI SIP dengan MRI transferor yang dikodekan di dalamnya dan ID sumber daya transferor dan parameter konteks transfer lainnya seperti yang ditunjukkan dalam tabel berikut:

Parameter	Nilai	Deskripsi
x-m	MRI	MRI penuh target transferor/transfer seperti yang diisi oleh CC
x-t	ID Penyewa	ID sumber daya x-t ID sumber daya opsional seperti yang diisi oleh CC
x-ti	ID Korelasi Transferor	ID korelasi panggilan ke transferor
x-tt	Mentransfer URI panggilan target	URI penggantian panggilan yang dikodekan

Ukuran Header Referensi dapat mencapai 400 simbol dalam hal ini. SBC harus mendukung penanganan Merujuk pesan dengan ukuran hingga 400 simbol.

Pengalihan panggilan

SDK Automasi Panggilan Azure Communication Services dapat mengalihkan panggilan masuk ke nomor lain atau titik akhir SDK/Teams, menghubungi pengguna atau pengguna lain secara paralel (berdering bersamaan), atau menghubungi sekelompok pengguna atau nomor. Hal-hal yang perlu dipertimbangkan:

• Request-URI dalam permintaan INVITE dari proksi SIP ke Pengguna C berisi parameter penyebab .

• Header History-Info diisi.

• Ketika Pengguna A adalah pengguna PSTN lain, proksi SIP menghasilkan respons provisi "SIP SIP/2.0 181 Call sedang diteruskan" ke Pengguna A.

• Jika Pengguna A dan Pengguna C adalah pengguna PSTN, proksi SIP mempertahankan respons provisi "SIP SIP/2.0 181 Call sedang diteruskan".

• Header History-Info harus digunakan untuk pencegahan perulangan.

Timer sesi

Proksi SIP mendukung (selalu menawarkan) Timer Sesi. Penggunaan Session Timer oleh SBC tidak wajib.

Penggunaan parameter Request-URI user=phone

Proksi SIP menganalisis Request-URI dan jika parameter user=phone ada, layanan menangani Request-URI sebagai nomor telepon, yang cocok dengan nomor tersebut dengan pengguna. Jika parameter tidak ada, proksi SIP menerapkan heuristik untuk menentukan jenis pengguna Request-URI (nomor telepon atau alamat SIP).

Microsoft merekomendasikan untuk selalu menerapkan parameter user=phone untuk menyederhanakan proses penyiapan panggilan.

Header Info Riwayat

Catatan

Di header Riwayat-Info perutean langsung Azure Communication Services diaktifkan secara default dan tidak dapat dinonaktifkan.

Header History-Info digunakan untuk menargetkan ulang permintaan SIP dan "menyediakan mekanisme standar untuk menangkap informasi riwayat permintaan untuk mengaktifkan berbagai layanan untuk jaringan dan pengguna akhir." Untuk informasi selengkapnya, lihat RFC 4244 – Bagian 1.1. Untuk perutean langsung, header ini digunakan dalam skenario pengalihan dering dan panggilan bersamaan.

History-Info diaktifkan sebagai berikut:

• Proksi SIP menyisipkan parameter yang berisi nomor telepon terkait dalam entri Info Riwayat individual yang terdiri dari header History-Info yang dikirim ke Pengontrol PSTN. Hanya menggunakan entri yang memiliki parameter nomor telepon, Pengontrol PSTN membangun kembali header Info Riwayat baru dan meneruskannya ke penyedia batang SIP melalui proksi SIP.

• Header History-Info ditambahkan untuk kasus dering dan pengalihan panggilan secara bersamaan.

• Header History-Info tidak ditambahkan untuk kasus transfer panggilan.

• Entri riwayat individual di header History-Info yang direkonstruksi memiliki parameter nomor telepon yang disediakan dikombinasikan dengan FQDN perutean langsung (sip.pstnhub.microsoft.com) yang ditetapkan sebagai bagian host dari URI. Parameter 'user=phone' ditambahkan sebagai bagian dari URI SIP. Parameter lain yang terkait dengan header History-Info asli, kecuali untuk parameter konteks telepon, yang diteruskan di header History-Info yang direkonstruksi.

  Catatan

  Entri yang bersifat privat (sebagaimana ditentukan oleh mekanisme yang ditentukan dalam Bagian 3.3 RFC 4244) diteruskan apa adanya karena penyedia batang SIP adalah serekan tepercaya.

• Info Riwayat Masuk dipertahankan untuk pencegahan perulangan.

Berikut ini adalah format header History-info yang dikirim oleh proksi SIP:

<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2

Jika panggilan dialihkan beberapa kali, informasi tentang setiap pengalihan disertakan dengan alasan yang sesuai dalam urutan kronologis, dalam daftar yang dipisahkan koma.

Contoh Header:

History-Info:
  <sip:+123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:+113579@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D496%3Btext%3D%22User%20Busy%22>;index=1.1

URI SIP di header History-Info diformat sesuai Bagian 25 RFC 3261 (lihat definisi addr-spec). Dalam contoh sebelumnya, teks asli header Reason URI adalah SIP;cause=496;text="User Busy", yang mendapatkan karakter , , "dan = yang lolos ;ke nilai %3Bheksa ASCII mereka , , %22dan 3D, masing-masing.

History-Info dilindungi oleh mekanisme TLS wajib.

Koneksi SBC ke mekanisme perutean dan failover langsung

Lihat bagian Mekanisme failover untuk sinyal SIP dalam persyaratan infrastruktur perutean langsung.

Retry-After

Jika pusat data perutean langsung sibuk, layanan dapat mengirim pesan Coba Lagi-Setelah dengan interval satu detik ke SBC. Saat SBC menerima pesan 503 dengan header Coba Lagi-Setelah sebagai respons terhadap INVITE, SBC harus mengakhiri koneksi tersebut dan mencoba pusat data Microsoft berikutnya yang tersedia.

Menangani percobaan ulang (respons 603)

Jika pengguna akhir mengamati beberapa panggilan yang terlewat untuk satu panggilan setelah menolak panggilan masuk, itu berarti bahwa mekanisme coba lagi penyedia batang SBC atau PSTN salah dikonfigurasi. SBC harus dikonfigurasi ulang untuk menghentikan upaya coba lagi pada respons 603.