Přímé směrování služeb Azure Communication Services: Podrobnosti protokolu SIP
Tento článek popisuje, jak přímé směrování implementuje PROTOKOL SIP (Session Initiation Protocol), aby se zajistily správné trasy provozu mezi řadičem SBC (Session Border Controller) a proxy serverem SIP. Zvýrazňuje také důležitost určitých parametrů PROTOKOLU SIP, které vyžadují konkrétní hodnoty. Tento článek je určený pro správce hlasu, kteří zodpovídají za konfiguraci připojení mezi SBC a proxy službou SIP.
Zpracování příchozího požadavku: Vyhledání prostředku Komunikační služby
Poznámka:
Možnosti SIP přímého směrování ve službě Azure Communication Services jsou ve výchozím nastavení povolené a nelze je zakázat. SBC musí nejprve zahájit výměnu OPTIONS, protože proxy server SIP čeká na spuštění výměny SBC.
Před zpracováním příchozího nebo odchozího volání se zprávy OPTIONS vyměňují mezi proxy serverem SIP a SBC. Tyto zprávy OPTIONS umožňují proxy serveru SIP poskytovat povolené možnosti SBC. Je důležité, aby vyjednávání o MOŽNOSTech bylo úspěšné (odpověď 200 OK), což umožňuje další komunikaci mezi SBC a PROXY serverem SIP pro navázání volání. Hlavičky SIP ve zprávách OPTIONS proxy serveru SIP jsou k dispozici jako příklad:
| Název parametru | Příklad hodnoty |
|---|---|
| Identifikátor URI požadavku | MOŽNOSTI sip:sip.pstnhub.microsoft.com:5061 SIP /2.0 |
| Via Header | Via: SIP/2.0/TLS sbc1.contoso.com:5061; Alias; branch=z9hG4bKac2121518978 |
| Hlavička Max-Forwards | Max-Forwards:68 |
| Ze záhlaví | Z záhlaví z: sip:sbc1.contoso.com:5061 |
| Do záhlaví | Na: sip:sip.pstnhub.microsoft.com:5061 |
| Hlavička CSeq | CSeq: 1 POZVAT |
| Záhlaví kontaktu | Kontakt: sip:sbc1.contoso.com:5061; transport=tls |
Poznámka:
Hlavičky SIP neobsahují informace o uživateli v používaném identifikátoru URI SIP. Podle dokumentu RFC 3261 oddíl 19.1.1 je část informace o uživateli identifikátoru URI nepovinná a může chybět, pokud cílový hostitel nemá představu o uživatelích nebo když samotný hostitel je identifikovaný prostředek. Pokud se znak @ nachází v identifikátoru SIP URI, pole uživatele nesmí být prázdné. Upozorňujeme, že identifikátor SIPS URI by se neměl používat s přímým směrováním, protože se nepodporuje. Zkontrolujte konfiguraci řadiče pro ohraničení relace a ujistěte se, že v požadavcích SIP nepoužíváte hlavičky Replaces. Přímé směrování odmítne požadavky PROTOKOLU SIP, které mají definované hlavičky Replaces.
Při příchozím volání musí proxy protokolu SIP najít prostředek komunikace Azure, ke kterému je volání určené. Tato část popisuje, jak proxy protokolu SIP najde prostředek a provádí ověřování SBC na příchozím připojení.
Příklad zprávy Pozvat na základě protokolu SIP při příchozím hovoru:
| Název parametru | Příklad hodnoty |
|---|---|
| Identifikátor URI požadavku | POZVAT sip:+54321@sip.pstnhub.microsoft.com SIP /2.0 |
| Via Header | Via: SIP/2.0/TLS sbc1.contoso.com:5061; Alias; branch=z9hG4bKac2121518978 |
| Hlavička Max-Forwards | Max-Forwards:68 |
| Ze záhlaví | Z hlavičky z: <sip:+12345@sbc1.contoso.com; transport=udp; tag=1c68821811 |
| Do záhlaví | Na: sip:+54321@sbc1.contoso.com |
| Hlavička CSeq | CSeq: 1 POZVAT |
| Záhlaví kontaktu | Kontakt: sip:+12345@sbc1.contoso.com:5061; transport=tls |
Při přijetí pozvánky proxy protokolu SIP provede následující kroky:
Zkontrolujte certifikát. Při počátečním připojení přebírá služba přímého směrování název plně kvalifikovaného názvu domény uvedený v hlavičce Kontaktu a odpovídá názvu společného názvu nebo alternativnímu názvu subjektu prezentovaného certifikátu. Název SBC musí odpovídat jedné z následujících možností:
Možnost 1. Úplný název plně kvalifikovaného názvu domény uvedený v hlavičce kontaktu se musí shodovat s běžným názvem nebo alternativním názvem subjektu prezentovaného certifikátu.
Možnost 2. Doménová část názvu plně kvalifikovaného názvu domény v záhlaví kontaktu (například contoso.com názvu plně kvalifikovaného názvu domény sbc1.contoso.com) musí odpovídat hodnotě se zástupným znakem v alternativním názvu společného názvu nebo subjektu (například *.contoso.com).
Zkuste najít tenanta Microsoftu 365 pomocí úplného názvu plně kvalifikovaného názvu domény uvedeného v záhlaví kontaktu.
Zkontrolujte, jestli je název plně kvalifikovaného názvu domény v záhlaví kontaktu (sbc1.contoso.com) zaregistrovaný jako název DNS v libovolné organizaci Microsoftu 365 nebo Office 365. Pokud se najde, provede se vyhledávání uživatele v tenantovi, který má plně kvalifikovaný název domény SBC zaregistrovaný jako název domény. Pokud se nenajde, použije se krok 3.
Zkuste najít prostředek komunikace Azure pomocí úplného názvu plně kvalifikovaného názvu domény zobrazeného v hlavičce kontaktu.
Zkontrolujte, jestli je název plně kvalifikovaného názvu domény v hlavičce kontaktu (sbc1.contoso.com) zaregistrovaný jako plně kvalifikovaný název domény SBC v libovolném prostředku služby Azure Communication. Pokud se najde, volání se odešle do daného prostředku. Pokud se nenajde, použije se krok 4.
Krok 4 platí jenom v případě, že kroky 2 a 3 selhaly.
Odeberte část hostitele z plně kvalifikovaného názvu domény, která se zobrazí v záhlaví kontaktu (plně kvalifikovaný název domény: sbc1.contoso.com, po odebrání části hostitele: contoso.com) a zkontrolujte, jestli je tento název zaregistrovaný jako název DNS v libovolné organizaci Microsoftu 365 nebo Office 365. Pokud se najde, provede se vyhledávání uživatele v tomto tenantovi. Pokud se nenajde, volání selže.
Krok 5 platí jenom v případě, že se nepovedlo provést kroky 2, 3 a 4.
Odeberte část hostitele z plně kvalifikovaného názvu domény, která se zobrazí v hlavičce kontaktu (plně kvalifikovaný název domény: sbc1.contoso.com, po odebrání části hostitele: contoso.com) a zkontrolujte, jestli je tento název zaregistrovaný jako plně kvalifikovaný název domény SBC v libovolném prostředku azure Communication. Pokud se najde, volání se odešle do daného prostředku. Pokud se nenajde, volání selže.
Pokud je k prostředku přidruženo nasazení Dynamics Omnichannel, vyhledejte telefonní číslo uvedené v identifikátoru Request-URI. Porovná zobrazené telefonní číslo s uživatelem Omnichannel (frontou) nalezeným v předchozím kroku.
Krok 7 se použije jenom v případě, že kroky 6 selhaly.
V případě, že pro prostředek komunikace neexistuje žádné nasazení Omnichannel nebo číslo v identifikátoru Request-URI neodpovídá žádnému nakonfigurovanýmu číslu Omnichannel, odešle volání do event Gridu.
Krok 8 se použije jenom v případě, že kroky 7 selhaly.
Pokud služba Event Grid není nakonfigurovaná nebo neexistuje žádná pravidla pro správu příchozího hovoru, volání se zahodí.
Podrobné požadavky na hlavičku kontaktu a identifikátor URI požadavku
Záhlaví kontaktu
U všech příchozích zpráv SIP (OPTIONS, INVITE) na proxy serveru Microsoft SIP musí hlavička kontaktu obsahovat spárovaný plně kvalifikovaný název domény SBC v názvu hostitele identifikátoru URI následujícím způsobem:
Syntaxe: Kontakt: <sip:phone nebo sip address@FQDN SBC; transport=tls>
Podle dokumentu RFC 3261, oddíl 11.1, pole záhlaví kontaktu může být přítomno ve zprávě OPTIONS. Při přímém směrování se vyžaduje záhlaví kontaktu. Pokud jde o zprávy OPTIONS, mohou být informace o uživateli vyloučeny z identifikátoru SIP URI a pouze plně kvalifikovaný název domény lze odeslat v následujícím formátu:
Syntaxe: Kontakt: <sip:FQDN SBC; transport=tls>
Tento název (FQDN) musí být také v polích Běžný název nebo Alternativní název subjektu prezentovaného certifikátu. Microsoft podporuje použití zástupných znaků názvů v polích Běžný název nebo Alternativní název subjektu certifikátu. Podpora zástupných znaků je popsaná v dokumentu RFC 2818 v části 3.1. Konkrétně:
"Názvy můžou obsahovat zástupný znak *, který se považuje za shodu s libovolnou komponentou názvu domény nebo fragmentem součásti. Například *.a.com odpovídá foo.a.com, ale nikoli bar.foo.a.com. f*.com odpovídá foo.com, ale nikoli bar.com."
Pokud V záhlaví kontaktu zobrazeném ve zprávě SIP podle SBC používá více než jednu hodnotu, použije se pouze část plně kvalifikovaného názvu domény první hodnoty záhlaví kontaktu. Jako pravidlo pro přímé směrování je důležité, aby se plně kvalifikovaný název domény používal k naplnění identifikátoru URI protokolu SIP místo IP adresy. Příchozí zpráva POZVAT nebo MOŽNOSTI proxy serveru SIP se záhlavím kontaktu, kde je název hostitele reprezentován IP adresou a ne plně kvalifikovaným názvem domény, připojení se odmítne s 403 Zakázáno.
Identifikátor URI požadavku
Pro všechna příchozí volání se identifikátor URI požadavku používá k identifikaci volané. V současné době musí telefonní číslo obsahovat znaménko plus (+), jak je znázorněno v následujícím příkladu.
INVITE sip:+12345@sip.pstnhub.microsoft.com SIP /2.0
Ze záhlaví
U všech příchozích hovorů se záhlaví odesílatele používá ke shodě s telefonním číslem volajícího.
Telefonní číslo musí obsahovat +, jak je znázorněno v následujícím příkladu.
From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811
Důležité informace o hlavičkách kontaktů a tras záznamů
Proxy protokolu SIP musí vypočítat plně kvalifikovaný název domény dalšího segmentu směrování pro nové transakce klienta v dialogovém okně (například Bye nebo Re-Invite) a při odpovídání na SIP OPTIONS. Můžete to provést buď pomocí kontaktu, nebo trasy záznamu. Podle dokumentu RFC 3261 je v každé žádosti vyžadována hlavička kontaktu, která může vést k vytvoření nového dialogového okna. Trasa záznamu se vyžaduje jenom v případě, že proxy server chce zůstat na cestě budoucích požadavků v dialogovém okně.
K výpočtu dalšího segmentu směrování používá proxy server SIP:
Priorita 1. Trasa záznamu nejvyšší úrovně. Pokud trasa záznamu nejvyšší úrovně obsahuje název plně kvalifikovaného názvu domény, použije se název plně kvalifikovaného názvu domény k vytvoření odchozího připojení v dialogovém okně.
Priorita 2. Záhlaví kontaktu. Pokud záznam-trasa neexistuje, proxy protokolu SIP vyhledá hodnotu hlavičky Kontaktu a vytvoří odchozí připojení. (Doporučená konfigurace.)
Pokud se použijí kontaktní i záznamové trasy, musí správce SBC zachovat své hodnoty identické, což způsobuje režijní náklady na správu.
Použití názvu plně kvalifikovaného názvu domény v kontaktu nebo trase záznamu
Použití IP adresy není podporováno buď v záznamové trase nebo kontaktu. Jedinou podporovanou možností je plně kvalifikovaný název domény, který se musí shodovat s běžným názvem nebo alternativním názvem certifikátu SBC (podporují se hodnoty zástupných znaků v certifikátu).
Pokud se v záznamu nebo kontaktu zobrazí IP adresa, kontrola certifikátu selže a volání selže.
Pokud plně kvalifikovaný název domény neodpovídá hodnotě společného alternativního názvu nebo alternativního názvu subjektu v zobrazeném certifikátu, volání selže.
Záhlaví kontextu volání
Záhlaví kontextu volání jsou aktuálně k dispozici pouze pro sadu SDK pro automatizaci volání. Sada SDK pro automatizaci volání podporuje hlavičku User-To-User a až pět vlastních hlaviček SIP. Tyto hlavičky jsou podporovány v metodách POZVAT a REFER.
Hlavička User-To-User
Hlavička SIP User-To-User (UUI) je oborový standard pro předávání kontextových informací během procesu nastavení volání. Maximální délka klíče hlavičky UUI je 64 znaků. Maximální délka hodnoty záhlaví UUI je 256 znaků. Hodnota záhlaví UUI se může skládat z alfanumerických znaků a několika vybraných symbolů, včetně , , , , *. _-!~%+.;=
Vlastní hlavička
Azure Communication Services také podporuje až pět vlastních hlaviček SIP. Vlastní klíč hlavičky SIP musí začínat povinnou X-MS-Custom- předponou. Maximální délka klíče hlavičky SIP je 64 znaků včetně předpony X-MS-Custom- . Klíč záhlaví SIP se může skládat z alfanumerických znaků a několika vybraných symbolů, včetně ., !, %, , *, _, +, ~, . - Maximální délka hodnoty hlavičky SIP je 256 znaků. Hodnota záhlaví SIP se může skládat z alfanumerických znaků a několika vybraných symbolů, včetně , , , , !, %, +*_~, . -.;=
Podrobnosti implementace najdete v tématu Jak předat kontextová data mezi voláními.
Příchozí volání: Popis dialogového okna SIP
Tady jsou podrobnosti o tom, jak proxy protokolu SIP zpracovává příchozí volání.
| Název parametru | Hodnota |
|---|---|
| Kandidáti na média ve 183 a 200 zprávách přicházejících z | Procesory médií |
| Počet 183 zpráv, které může SBC přijímat | Jedna na relaci |
| Hovor může být s prozatímní odpovědí (183) | Ano |
| Hovor může být bez prozatímní odpovědi (183) | Ano |
Identitu služby Azure Communication Services je možné použít ve více koncových bodech (aplikacích) najednou. Například webová aplikace, i Telefon aplikace a aplikace pro Android. Každý koncový bod může signalizovat zbytek PROTOKOLU HTTP následujícím způsobem:
Průběh volání – převeden proxy serverem SIP na zprávu SIP 180. Při příjmu zprávy 180 musí SBC generovat místní vyzvánění.
Odpověď na média – převedena proxy serverem SIP na zprávu 183 s kandidáty na média v protokolu SDP (Session Description Protocol). Při přijetí zprávy 183 očekává SBC připojení k kandidátům médií přijatým ve zprávě SDP.
Poznámka:
V některých případech nemusí být vygenerována odpověď na média a koncový bod může odpovědět zprávou "Přijmout hovor".
Volání přijato – převedeno proxy SIP na ZPRÁVU SIP 200 s SDP. Při přijetí zprávy 200 se očekává, že SBC bude odesílat a přijímat média do a od poskytnutých kandidátů SDP.
Poznámka:
Přímé směrování nepodporuje zpožděné pozvání nabídky (pozvání bez protokolu SDP).
Vyzvánění několika koncových bodů s prozatímní odpovědí
Při přijetí první pozvánky z SBC odešle proxy server SIP zprávu SIP SIP/2.0 100 Trying" a upozorní všechny koncové body koncového uživatele na příchozí hovor.
Po oznámení začne každý koncový bod vyzvánět a odesílat zprávy "Průběh volání" proxy serveru SIP. Vzhledem k tomu, že identitu služby Azure Communication Services používá více koncových bodů, proxy protokolu SIP může přijímat více zpráv o průběhu volání.
Pro každou zprávu o průběhu volání přijaté z koncových bodů proxy server SIP převede zprávu Průběh volání na zprávu SIP SIP/2.0 180 Vyzvánění. Interval pro odesílání takových zpráv odpovídá intervalu přijímajících zpráv z kontroleru volání. V následujícím diagramu jsou dvě 180 zpráv vygenerované proxy serverem SIP. Tyto zprávy pocházejí ze dvou koncových bodů sady SDK. Každý koncový bod má jedinečné ID značky. Každá zpráva pocházející z jiného koncového bodu je samostatná relace (parametr "tag" v poli Komu je jiný). Koncový bod ale nemusí okamžitě generovat zprávu 180 a odeslat zprávu 183, jak je znázorněno v následujícím diagramu.
Jakmile koncový bod vygeneruje zprávu Odpovědi na médium s IP adresami kandidátů na média koncového bodu, proxy protokolu SIP převede zprávu přijatou na zprávu "Průběh relace SIP 183" se z koncového bodu nahrazeno protokolem SDP z procesoru médií. V následujícím diagramu koncový bod z Forku 2 odpověděl na hovor. Zpráva 183 SIP se vygeneruje pouze jednou. 183 může přijít na existující fork nebo začít nový.
Na proxy serveru SIP se odešle zpráva o přijetí volání s konečnými kandidáty koncového bodu, který hovor přijal. Zpráva přijetí volání je převedena na zprávu SIP 200.
Vyzvánění několika koncových bodů bez prozatímní odpovědi
Při přijetí první pozvánky z SBC odešle proxy server SIP zprávu SIP SIP/2.0 100 Trying" a upozorní všechny koncové body koncového uživatele na příchozí hovor.
Po oznámení začne každý koncový bod vyzvánět a odesílá zprávu "Průběh volání" na proxy serveru SIP. Vzhledem k tomu, že stejnou identitu služby Azure Communication Services je možné použít ve více aplikacích, může proxy protokolu SIP přijímat více zpráv o průběhu volání.
Pro každou zprávu o průběhu volání přijaté z koncových bodů proxy server SIP převede zprávu Průběh volání na zprávu SIP SIP/2.0 180 Vyzvánění. Interval pro odesílání zpráv odpovídá intervalu příjmu zpráv z kontroleru volání. Na obrázku jsou dvě 180 zpráv vygenerované proxy serverem SIP, což znamená, že volání je rozvětvováno na dva různé klienty a každý klient odesílá průběh volání. Každá zpráva je samostatná relace (parametr "tag" v poli Komu je jiný).
Na proxy serveru SIP se odešle zpráva o přijetí volání s konečnými kandidáty koncového bodu, který hovor přijal. Zpráva přijetí volání je převedena na zprávu SIP 200.
Možnost Nahradit
SBC musí podporovat FUNKCI POZVĚT s nahrazeními.
Důležité informace o velikosti protokolu SDP
Rozhraní přímého směrování může odesílat zprávu SIP přesahující 1 500 bajtů. Velikost protokolu SDP způsobuje především takové chování. Pokud je však za SBC kmen UDP, může zprávu odmítnout, pokud se přepošla z proxy serveru Microsoft SIP do kmene beze změny. Společnost Microsoft doporučuje při odesílání zprávy do kmenů UDP některé hodnoty v protokolu SDP na SBC. Můžete například odebrat kandidáty ICE nebo nepoužívané kodeky.
Přepojení hovorů
Přímé směrování podporuje dvě metody pro přenos volání:
Možnost 1. Proxy procesy SIP odkazují z klienta místně a fungují jako referee, jak je popsáno v části 7.1 RFC 3892.
S touto možností proxy protokolu SIP ukončí přenos a přidá novou pozvánku.
Možnost 2. Proxy server SIP odešle odkaz na SBC a funguje jako převodník, jak je popsáno v části 6 RFC 5589.
S touto možností proxy server SIP odešle odkaz na SBC a očekává, že SBC zpracuje přenos plně.
Proxy server SIP vybere metodu na základě schopností hlášených SBC. Pokud SBC indikuje, že podporuje metodu "Odkaz", proxy protokolu SIP používá možnost 2 pro přenosy volání. Příklad SBC odesílající zprávy, že metoda Refer je podporovaná:
ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Pokud SBC nezmíní, že se jedná o podporovanou metodu, použije přímé směrování možnost 1 (proxy server SIP funguje jako referee). SBC musí také signalizovat, že podporuje metodu Notify: Příklad SBC označující, že metoda Refer není podporována:
ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS
Procesy proxy serveru SIP odkazují z klienta místně a fungují jako referenční osoba.
Pokud SBC naznačuje, že metoda Refer není podporovaná, proxy protokolu SIP funguje jako referenční osoba. Požadavek Refer, který pochází z klienta, se ukončí na proxy serveru SIP. Žádost o odkaz od klienta se v následujícím diagramu zobrazuje jako "Přepojení hovorů na Dave". Další informace naleznete v části 7.1 dokumentu RFC 3892.
Proxy server SIP odešle odkaz na SBC a funguje jako převodník.
Proxy protokolu SIP jako transferor je upřednostňovanou metodou pro přenosy volání.
Standard je vysvětlen v části 6 DOKUMENTU RFC 5589. Související rfcs jsou:
Řízení volání protokolu SIP (Session Initiation Protocol) – přenos
Hlavička PROTOKOLU SIP (Session Initiation Protocol) "Replaces" (Replaces)
Mechanismus PROTOKOLU SIP (Session Initiation Protocol) "Odkazovaný podle"
Tato možnost předpokládá, že proxy protokolu SIP funguje jako přenosač a odesílá zprávu Odkaz na SBC. SBC funguje jako převod a zpracovává odkaz, aby vygeneroval novou nabídku pro převod. Existují dva možné případy:
- Hovor se přepošla na externího účastníka veřejné telefonní sítě.
- Volání se přenese z jednoho koncového bodu sady SDK do jiného koncového bodu sady SDK ve stejném prostředku přes SBC.
Pokud je volání přeneseno z jednoho koncového bodu sady SDK do jiného koncového bodu sady SDK přes SBC, očekává se, že SBC vydá novou pozvánku (spustí nové dialogové okno) pro cíl přenosu pomocí informací přijatých ve zprávě Odkaz. Pro interní naplnění polí to/transferor pro transakci požadavku musí proxy protokolu SIP sdělit tyto informace v hlavičce REFER-TO/REFERENCE-BY. Proxy server SIP tvoří identifikátor REFER-TO jako identifikátor SIP URI, který se skládá z plně kvalifikovaného názvu domény proxy protokolu SIP v názvu hostitele, a to buď:
Telefonní číslo E.164 v uživatelském jménu v části identifikátoru URI v případě, že cíl přenosu je telefonní číslo, nebo
Parametry x-m a x-t kódující úplný cíl přenosu MRI a ID komunikačního prostředku.
Hlavička REFERRED-BY má identifikátor SIP URI s mrI převodu, který je v něm kódovaný, a ID prostředku převodu a další parametry kontextu přenosu, jak je znázorněno v následující tabulce:
| Parametr | Hodnota | Popis |
|---|---|---|
| x-m | MRI | Úplný cíl převodce nebo převodu, který je vyplněný službou CC |
| x-t | ID tenanta | ID prostředku x-t – Volitelné ID prostředku vyplněné službou CC |
| x-ti | ID korelace převodu | ID korelace volání převodce |
| x-tt | Přenos identifikátoru URI cílového volání | Kódovaný identifikátor URI nahrazení volání |
Velikost hlavičky odkaz může být v tomto případě až 400 symbolů. SBC musí podporovat zpracování zpráv Typu Odkaz s velikostí až 400 symbolů.
Přesměrování hovorů
Sada SDK služby Azure Communication Services pro automatizaci volání může přesměrovat příchozí hovory na jiné číslo nebo koncový bod sady SDK/Teams, vyzvánět souběžně jiným uživatelům nebo uživatelům (souběžným vyzváněním) nebo vyzvánět skupině uživatelů nebo čísel. Co je potřeba vzít v úvahu:
Identifikátor URI požadavku request-URI v požadavku POZVAT z proxy serveru SIP na user C obsahuje parametr příčiny .
Vyplní se záhlaví Historie a informace.
Pokud je uživatel A jiným uživatelem veřejné telefonní sítě, proxy server SIP vygeneruje prozatímní odpověď na uživatele A volání SIP/2.0 181.
Pokud uživatel A a uživatel C jsou uživatelé veřejné telefonní sítě, proxy siP zachová prozatímní odpověď SIP SIP/2.0 181 Volání se přesměrovává.
Hlavička Historie informací by se měla použít pro prevenci smyčky.
Časovač relace
Proxy server SIP podporuje časovač relace (vždy nabízí). Použití časovače relace pro SBC není povinné.
Použití parametru Request-URI user=phone
Proxy server SIP analyzuje identifikátor Request-URI a pokud je k dispozici parametr user=phone, služba zpracovává identifikátor Request-URI jako telefonní číslo odpovídající číslu uživateli. Pokud parametr není k dispozici, proxy server SIP použije heuristika k určení typu uživatele Request-URI (telefonní číslo nebo adresa SIP).
Microsoft doporučuje vždy použít parametr user=phone, aby se zjednodušil proces nastavení volání.
Záhlaví Historie a informace
Poznámka:
V hlavičce Historie a informace o přímém směrování ve službě Azure Communication Services je ve výchozím nastavení povolená a nelze ji zakázat.
Hlavička Historie-informace se používá k retargetingu požadavků SIP a "poskytuje" standardní mechanismus pro zaznamenání informací historie požadavků, aby bylo možné povolit širokou škálu služeb pro sítě a koncové uživatele." Další informace naleznete v dokumentu RFC 4244 – oddíl 1.1. Pro přímé směrování se tato hlavička používá ve scénářích souběžných vyzvánění a přesměrování volání.
Informace o historii jsou povoleny takto:
Proxy server SIP vloží parametr obsahující přidružené telefonní číslo do jednotlivých položek Historie-Informace, které obsahují hlavičku Historie-Informace odeslanou kontroleru veřejné telefonní sítě. Pomocí pouze položek, které mají parametr telefonního čísla, řadič veřejné telefonní sítě znovu sestaví novou hlavičku Historie-Informace a předá ji poskytovateli kmene SIP prostřednictvím proxy serveru SIP.
Záhlaví Historie- Informace se přidá pro případy souběžného vyzvánění a přesměrování volání.
Hlavička Historie-Informace není přidána pro případy přenosu volání.
Jednotlivá položka historie v rekonstruované hlavičce Historie-Informace má parametr telefonního čísla, který je v kombinaci s plně kvalifikovaným názvem domény směrování (sip.pstnhub.microsoft.com) nastaveným jako hostitelská část identifikátoru URI. Parametr user=phone přidaný jako součást identifikátoru SIP URI. Všechny ostatní parametry přidružené k původní hlavičce Historie-Informace s výjimkou parametrů kontextu telefonu, které se předávají v rekonstruované hlavičce Historie-Informace.
Poznámka:
Položky, které jsou soukromé (podle mechanismů definovaných v oddílu 3.3 DOKUMENTU RFC 4244), jak je uvedeno, protože poskytovatel kmene SIP je důvěryhodný partnerský vztah.
Informace o příchozí historii se zachovají pro prevenci smyčky.
Následuje formát hlavičky Historie informací odesílané proxy serverem SIP:
<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2
Pokud bylo volání přesměrováno několikrát, informace o každém přesměrování jsou zahrnuty s odpovídajícím důvodem v chronologickém pořadí v seznamu odděleném čárkami.
Příklad záhlaví:
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
Identifikátor SIP v hlavičce Historie a informace je formátován podle oddílu 25 dokumentu RFC 3261 (viz definice addr-spec). V předchozím příkladu je SIP;cause=496;text="User Busy"původní text záhlaví Reason identifikátoru URI , který získá jeho ;", a = znaky řídicích znaků na jejich šestnáctkové hodnoty %3BASCII , %22a 3Dv uvedeném pořadí.
Informace o historii jsou chráněné povinným mechanismem TLS.
Připojení SBC k přímému směrování a mechanismu převzetí služeb při selhání
Viz část Mechanismus převzetí služeb při selhání pro signalizaci SIP v požadavcích na infrastrukturu přímého směrování.
Opakovat po
Pokud je datacentrum přímého směrování zaneprázdněné, může služba odeslat zprávu Opakovat po s jedním intervalem do SBC. Když SBC obdrží zprávu 503 s hlavičkou Opakovat po v reakci na POZVÁNKU, musí SBC toto připojení ukončit a vyzkoušet další dostupné datové centrum Microsoftu.
Zpracování opakovaných pokusů (odpověď 603)
Pokud koncový uživatel po odmítnutí příchozího hovoru zaznamená několik zmeškaných volání pro jedno volání, znamená to, že je chybně nakonfigurovaný mechanismus opakování poskytovatele SBC nebo veřejné telefonní sítě. SBC musí být překonfigurovaný tak, aby se zastavily pokusy o opakování odpovědi 603.