Problémy, které mají vliv na příchozí volání přímého směrování

Při příjmu volání veřejné telefonní sítě (PSTN) prostřednictvím přímého směrování může docházet k problémům. Tento článek popisuje některé z těchto problémů a obsahuje řešení, která můžete vyzkoušet.

Žádný tón zpětného vyzvánění, když Teams přijme hovor z koncového bodu veřejné telefonní sítě

K tomuto problému dochází v následujícím scénáři:

Když klient Microsoft Teams přijme hovor, nejprve odešle zprávu vyzvánění PROTOKOLU SIP 180 a pak odešle zprávu o průběhu relace SIP 183 společně s nabídkou médií (SDP).

Podle standardů RFC 3261 a RFC 3960, když koncový bod, který používá volající, obdrží zprávu VYZVÁNĚNÍ 180 SIP 180, musí generovat vyzváněcí tón místně. Pokud zařízení volajícího obdrží zprávu o průběhu relace SIP 183 s protokolem SDP, umožní cíli (v tomto scénáři klienta Teams) přehrát zvuk nebo vyzváněcí tón před přijetím relace volaným uživatelem. Takový zvuk se označuje jako raná média.

Některá zařízení volajícího a operátoři ale přestanou generovat vyzváněcí tón místně, když obdrží zprávu o průběhu relace SIP 183. K tomu dochází i v případě, že zařízení a operátoři by měli dál generovat vyzváněcí tón, dokud nebudou přijaty skutečné pakety médií.

Řešení

Chcete-li tento problém vyřešit, musíte aktualizovat konfiguraci řadiče pro ohraničení relace (SBC) pro zpracování více zpráv SIP 18x.

Většina sbc nabízí jednu z následujících možností omezení rizik:

• Přesměrujte pouze první zprávu SIP 18x a ignorujte následující zprávy, dokud se hovor neodpoví nebo neskončí. Tuto možnost nabízí například sbcs AudioCodes.
• Odeberte informace protokolu SDP ze zprávy o průběhu relace SIP 183 a potom zprávu změňte na zprávu vyzvánění PROTOKOLU SIP 180. Tuto možnost nabízí například sbcs Metaswitch.

Pokyny k aktualizaci pravidel manipulace s SIP ve vašem SBC najdete v dokumentaci, která je specifická pro váš model SBC, a požádejte dodavatele SBC o další doporučené možnosti.

Více oznámení o zmeškaných hovorech

Když Teams přijme hovor a odmítne ho, protože uživatel je zaneprázdněný nebo nechce hovor přijmout, může operátor veřejné telefonní sítě nebo SBC hovor opakovat několikrát. Aplikace Teams interpretuje každou z opakovaných volání jako samostatná volání a zobrazuje několik zmeškaných oznámení hovorů.

K tomuto problému dochází, protože různé komunikační standardy, jako je RFC 4497 standard a NICC standard ND1017:2006/07, mapují stejný kód odpovědi SIP na různé kódy příčin Q.850.

Například RFC 4497 mapuje kód odpovědi SIP 486 na Q.850 kód příčiny 34 a ND1017:2006/07 (který používá přímé směrování) mapuje kód 486 na Q.850 příčina kód 17. Vzhledem k tomuto rozdílu poskytovatelé veřejné telefonní sítě, kteří používají standard RFC 4497, interpretují důvod, proč Aplikace Teams odmítla volání nesprávně. Poskytovatelé veřejné telefonní sítě proto několikrát opakují volání.

Řešení

Pokud chcete tento problém vyřešit, aktualizujte pravidla manipulace s protokolem SIP ve vašem SBC tak, aby odebrala kód příčiny Q.850, který je namapovaný na kód odpovědi SIP 486, nebo změňte kód příčiny z 34 na 17. Pokyny k aktualizaci pravidel manipulace s SIP najdete v dokumentaci, která je specifická pro váš model SBC.

Pokud aktualizace pravidel problém nevyřeší, je pravděpodobné, že buď SBC, síťové zařízení v komunikační cestě, nebo poskytovatel veřejné telefonní sítě opakuje volání, jakmile obdrží kód odpovědi SIP 4xx . Toto chování se nedoporučuje. V této situaci aktualizujte konfiguraci SBC a síťových zařízení nebo požádejte poskytovatele veřejné telefonní sítě, aby aktualizoval konfiguraci, aby se ujistil, že po přijetí odpovědi SIP 4xx na ukončení hovoru nepokusí znovu zavolat.

Pro příchozí volání se zobrazí nesprávné ID volajícího (CLI).

Když Teams přijme hovor, zobrazí číslo volajícího, které je zadané v From záhlaví zprávy SIP INVITE. Někteří poskytovatelé veřejné telefonní sítě ale mohou místo záhlaví použít P-Asserted-Identity záhlaví From k uložení čísla volajícího. V takovém případě jsou informace zobrazené uživateli Teams nesprávné.

Řešení

Pokud chcete tento problém vyřešit, zkontrolujte, jestli váš poskytovatel veřejné telefonní sítě používá hlavičku P-Asserted-Identity . Pokud ano, nakonfigurujte SBC tak, aby přepsal obsah From záhlaví informacemi z hlavičky P-Asserted-Identity .

Pokud chcete hlavičku From přepsat, pokyny najdete v dokumentaci specifické pro váš model SBC.

Poznámka:

From Pokud záhlaví obsahuje jako informace "Anonymní", Teams ho někdy převede na číslo a místo toho zobrazí 266696687.

Příchozí hovory jsou nesprávně označené jako nevyžádaná pošta s pravděpodobností.

Pokud je povolené filtrování nevyžádané pošty pro hovory , zkontrolují se ID volajících všech příchozích hovorů a přiřadí skóre spamu. Pokud je skóre ID volajícího vyšší než konkrétní prahová hodnota, Teams zobrazí oznámení, že hovor může být spam.

Řešení

Pokud chcete snížit pravděpodobnost označení telefonního čísla volajícího jako spamu, ujistěte se, že je číslo zadané ve formátu E.164.

Příchozí hovory nejsou blokované podle očekávání

Teams nakonfigurujete tak, aby blokovala volání z ID volajícího, která splňují předdefinovaná konkrétní kritéria. I nadále ale budete přijímat hovory z těchto telefonních čísel.

Příčinou tohoto problému je obvykle neshoda mezi formátem ID volajícího, který se očekává výrazem, který se používá k blokování příchozích hovorů, a formátEM ID volajícího v From záhlaví zprávy SIP.

ID volajícího může být například zadáno v mezinárodním formátu, včetně úvodního znaménka plus (+) a mezinárodní předpony. Výraz však kontroluje pouze čísla zadaná v národním formátu. Situace může být také obrácená.

Řešení

Chcete-li tento problém vyřešit, aktualizujte výraz, který se používá ke kontrole příchozích volání přidáním znaménka plus (+) jako volitelného znaku. Tento revidovaný výraz pokrývá více formátů ID volajícího a je zvlášť užitečný, pokud používáte plány přímého směrování i volání, ve kterých jsou čísla prezentována v různých formátech.

Zpoždění při přijímání hovorů do veřejné telefonní sítě v Teams

Když Teams přijme hovor z koncového bodu veřejné telefonní sítě, dojde buď ke zpoždění při odpovídání na hovor, nebo po několika sekundách od odpovědi Teams na hovor neuslyšíte žádný zvuk.

Tyto problémy jsou obvykle způsobeny několika obnoveními protokolu SIP, které se odesílají mezi SBC a proxy serverem SIP, než se volání úspěšně připojí. To je zvlášť běžné ve scénářích, které zahrnují obejití médií nebo místní optimalizaci médií, které vyžadují několik opětovného zavedení návrhu. Kromě toho v situaci, jako je situace, kdy SBC nenabízí odpovídající IP adresu média v původní pozvánce, musí SBC poslat znovu, která má správné informace. Pokud proxy protokolu SIP přijme opětovný návrat ze SBC v nesprávném pořadí nebo v nesprávném čase (což způsobuje konflikt časování), může obnovení trvat déle, než se vyjedná. Tato situace může způsobit zpoždění zvuku.

Řešení

Pokud chcete tyto problémy vyřešit, aktualizujte konfiguraci SBC. Ujistěte se, že ve výchozím nastavení nabízí nejpravděpodobnější IP adresu média, abyste minimalizovali počet opětovných obnovení. Pokud se například od interních uživatelů očekává většina volání, nakonfigurujte SBC tak, aby nejdřív nabízela interní IP adresu. Podrobné pokyny ke konfiguraci SBC najdete v dokumentaci, která je specifická pro váš model SBC.

Počet volání po určité době zahodí

V Teams můžou probíhající hovory a příchozí hovory, které se stále snaží připojit, z různých důvodů vynechat.

Na základě doby, po které volání klesne, vyzkoušejte řešení, která fungují pro váš scénář.

Počet volání se po čtyřech sekundách zahodí

Příčinou tohoto problému je obvykle špatné připojení nebo problém s komunikací, který existuje mezi SBC a proxy serverem SIP. Příklad:

• SBC nemusí obdržet zprávu SIP 100 Trying message, protože zpráva je blokována bránou firewall nebo není odeslána kvůli problémům se sítí.
• SBC obdrží zprávu SIP, ale nepotvrdí ji odesláním zprávy SIP ACK.

Řešení

Pokud chcete tento problém vyřešit, aktualizujte konfiguraci SBC a sítě tak, aby umožňovala provoz do a ze všech rozsahů IP adres, které funkce Přímé směrování používá pro signalizaci SIP. Kromě toho se ujistěte, že SBC odesílá zprávy podle standardního procesu, který se používá ke komunikaci signálů SIP.

Podrobné pokyny ke konfiguraci SBC najdete v dokumentaci, která je specifická pro váš model SBC.

Počet volání po 10 až 20 sekundách

Pokud příchozí hovor klesne mezi 10 a 20 sekundami pokusu o připojení a neexistuje žádný zvuk, důvodem může být, že v daném časovém rámci nebyly přijaty žádné informace o médiu nebo kontroly připojení k interaktivnímu připojení (ICE). V této situaci teams hovor zahodí.

Řešení

Pokud chcete tento problém vyřešit, ujistěte se, že jsou do zprávy SDP ze SBC zahrnuty správné kandidáty ICE. Aktualizujte také konfiguraci sítě a brány firewall podle potřeby, abyste měli jistotu, že mohou zpracovávat požadavky a odpovědi od kandidátů ICE.

Počet volání po několika minutách

Probíhající volání se zahodí bez vrácení kódu chyby po připojení a zůstane aktivní mezi 10 a 60 minutami. K tomuto scénáři může dojít v případě, že se problém týká časovače relace nebo mechanismu aktualizace relace, který je zadaný v SESSION-EXPIRES hlavičce zprávy SIP INVITE. Volání je naplánováno tak, aby skončilo po uplynutí zadaného času v SESSION-EXPIRES hlavičce, pokud se neposílají znovu připojit k aktualizaci relace před vypršením času.

V následujícím příkladu hlavička SESSION-EXPIRES určuje, že volání skončí po 1 800 sekundách (30 minut):

SESSION-EXPIRES : 1800;refresher=uac

Poznámka:

• Opětovné obnovení se obvykle odesílá v polovině času určeného časovačem relace.
• Pokud je uachodnota refresher parametru v hlavičce , strana, která odešle zprávu SIP INVITE, je zodpovědná za odeslání opětovného obnovení k aktualizaci relace.
• Pokud je uashodnota refresher parametru v hlavičce , strana, která obdrží zprávu SIP INVITE, je zodpovědná za odeslání znovuvite aktualizovat relaci.

Řešení

Pokud chcete tento problém vyřešit, aktualizujte konfiguraci SBC, abyste měli jistotu, že správná strana odešle zprávu znovu v odpovídající době před vypršením platnosti časovače relace.

K problémům s časovačem relace může dojít také v jiných částech volání, jako je operátor veřejné telefonní sítě v komunikační cestě. Pokud hovor selže u operátora veřejné telefonní sítě, odešle zprávu SIP BYE do SBC. Tato zpráva se pak odešle na proxy serveru SIP a proxy ukončí volání. Pokud chcete tento problém vyřešit, určete zdroj zprávy SIP BYE a pak problém ve zdroji vyřešte.