Kända problem i SDK:er och API:er

  • Artikel

De här artiklarna innehåller information om begränsningar och kända problem som rör Azure Communication Services Calling SDK:er och Api:er för samtalsautomatisering för kommunikationstjänster.

Viktigt!

Det finns flera faktorer som kan påverka kvaliteten på din samtalsupplevelse. Mer information om metodtips för nätverkskonfiguration och testning av Kommunikationstjänster finns i Nätverksrekommendationer.

Anropa webb-SDK

Följande avsnitt innehåller information om kända problem som är associerade med Röst- och videosamtals-SDK:er för Azure Communication Services JavaScript.

Chrome M115 – regression

Chrome version 115 för Android introducerade en regression vid videosamtal – resultatet av den här buggen är att en användare som ringer ett anrop på Azure Communication Services med den här versionen av Chrome inte har någon utgående video i Grupp- och Azure Communication Services-Microsoft Teams-anrop.

  • Den här regressionen är ett känt problem som introduceras på Chromium
  • Som en kortsiktig åtgärd instruerar du användare att använda Microsoft Edge eller Firefox på Android, eller undvika att använda Google Chrome 115/116 på Android

Kända problem med Firefox

Webbläsarstöd för Firefox är nu tillgängligt i offentlig förhandsversion. Kända problem är:

  • Uppräkningshögtalare är inte tillgängliga: Om du använder Firefox kan din app inte räkna upp eller välja högtalare via Enhetshanteraren för Kommunikationstjänster. I det här scenariot måste du välja enheter via operativsystemet.
  • Virtuella kameror stöds för närvarande inte när du gör Firefox desktop audio\video-anrop.

Kända problem med iOS Chrome

iOS Chrome-webbläsarstöd är nu tillgängligt i offentlig förhandsversion. Kända problem är:

  • Inget utgående och inkommande ljud när du byter webbläsare till bakgrunden eller låser enheten. Det här problemet har åtgärdats i iOS version 16.4+.
  • Inget inkommande/utgående ljud kommer från Bluetooth-headsetet. När en användare ansluter bluetooth-headset mitt i Azure Communication Services-samtalet kommer ljudet fortfarande ut från högtalaren tills användaren låser och låser upp telefonen. Vi har sett det här problemet på äldre iOS-versioner (15.6, 15.7) och det är inte reproducerbart i iOS 16.

iOS Safari visar en felaktig upplösningsstorlek för kameraförhandsgranskningen

Den här buggen inträffar på tidigare versioner av iOS 16.7 eller iOS 17 än 17.4 när användarna roterar sina telefoner eller aktiverar/inaktiverar video under samtalet. Kameraförhandsgranskningen visar kort en felaktig upplösningsstorlek innan den återgår till det normala. Problemet är inte reproducerbart i iOS 17.4 Beta. Relaterad WebKit-bugg här.

iOS 16 introducerade buggar när webbläsaren sattes i bakgrunden under ett anrop

IOS 16-versionen introducerades en bugg som kan stoppa ljud-/videosamtalet i Azure Communication Services när du använder Safari Mobile Browser. Apple är medveten om det här problemet och letar efter en korrigering på deras sida. Effekten kan vara att ett Azure Communication Services-samtal kan sluta fungera under ett samtal och den enda lösningen för att få det att fungera igen är att låta slutkund starta om sin telefon.

Så här återskapar du den här buggen:

  • Låta en användare använda en i Telefon som kör iOS 16
  • Anslut Azure Communication Services-samtal (endast med ljud eller med ljud och video) med safari iOS mobile browser
  • Om någon under ett samtal placerar Safari-webbläsaren i bakgrunden och visar YouTube ELLER tar emot ett FaceTime\telefonsamtal när den är ansluten via en Bluetooth-enhet

Resultat:

  • Efter några minuter av den här situationen kan den inkommande och utgående videon sluta fungera.
  • Det enda sättet att få Azure Communication Services-samtal att fungera igen är att låta slutanvändaren starta om sin telefon.

Chrome M98 – regression

Chrome version 98 introducerade en regression med onormal generering av videonyckelramar som påverkar upplösningen av en skickad videoström negativt för majoriteten (70 %+) av användarna.

  • Den här regressionen är ett känt problem som introduceras på Chromium

Vid ett PSTN-samtal kan användaren fortfarande höra ljud från ACS-samtalet

Det här problemet inträffar när en Android Chrome-användare får ett inkommande PSTN-samtal När pstn-samtalet har besvarats stängs mikrofonen i ACS-anropet av. Det utgående ljudet för ACS-anropet är avstängt, så att andra deltagare inte kan höra den användare som är PSTN-samtalet. Det är värt att notera att användarens inkommande ljud inte är avstängt och att det här beteendet är inbyggt i webbläsaren.

Inget inkommande ljud under ett samtal

Ibland kan det hända att en användare i ett Azure Communication Services-samtal inte kan höra ljudet från fjärrdeltagare. Det finns en relaterad Chromium-bugg som orsakar det här problemet. Problemet kan åtgärdas genom att återansluta Peer Anslut ion. Vi har lagt till den här lösningen sedan SDK 1.9.1 (stabil) och SDK 1.10.0 (beta).

Om en användare ansluter till Azure Communication Services-samtal flera gånger i Android Chrome kan det inkommande ljudet också försvinna. Användaren kan inte höra ljudet från andra deltagare förrän sidan har uppdaterats. Vi har åtgärdat det här problemet i SDK 1.10.1-beta.1 och förbättrat användningen av ljudresurser.

Vissa Android-enheter misslyckas med samtalsscenarier förutom gruppsamtal.

Många specifika Android-enheter kan inte starta, acceptera samtal och möten. De enheter som stöter på det här problemet kan inte återställas och misslyckas vid varje försök. Dessa är främst Samsung model A-enheter, särskilt modellerna A326U, A125U och A215U.

  • Den här regressionen är ett känt problem som introduceras på Chromium.

Android Chrome stänger av anropet efter att webbläsaren har gått till bakgrunden i en minut

Om en användare använder ett Azure Communication Services-anrop i Android Chrome och placerar webbläsaren i bakgrunden i en minut. Mikrofonen förlorar åtkomst och de andra deltagarna i samtalet kan inte höra ljudet från användaren. När användaren tar webbläsaren till förgrunden är mikrofonen tillgänglig igen. Relaterade krombuggar här och här

En mobil användare (iOS och Android) har avbrutit samtalet men visas fortfarande på deltagarlistan.

Problemet kan uppstå om en mobil användare lämnar Azure Communication Services-gruppanropet utan att använda API:et Call.hangUp(). När en mobil användare stänger webbläsaren eller uppdaterar webbsidan utan att lägga på, kan andra deltagare i gruppsamtalet fortfarande se den här mobilanvändaren i deltagarlistan i cirka 60 sekunder.

iOS Safari uppdaterar sidan om användaren går till en annan app och återgår till webbläsaren

Problemet kan uppstå om en användare i ett Azure Communication Services-samtal med iOS Safari och växlar till en annan app ett tag. När användaren återvänder till webbläsaren kan webbläsarsidan uppdateras. Detta beror på att operativsystemet dödar webbläsaren. Ett sätt att åtgärda det här problemet är att behålla vissa tillstånd och återställa efter siduppdateringar.

iOS 15.1-användare ansluter till gruppsamtal eller Microsoft Teams-möten.

  • Ibland när inkommande PSTN tas emot låser sig fliken med samtalet eller mötet. Relaterade WebKit-buggar här och här.

Lokal mikrofon/kamera stängs av när vissa avbrott inträffar i iOS Safari och Android Chrome.

Det här problemet kan uppstå om ett annat program eller om operativsystemet tar över kontrollen över mikrofonen eller kameran. Här följer några exempel som kan inträffa när en användare är i anropet:

  • Ett inkommande samtal anländer via PSTN (offentligt växlat telefonnätverk) och det fångar mikrofonenhetens åtkomst.
  • En användare spelar till exempel upp en YouTube-video eller startar ett FaceTime-samtal. Om du byter till ett annat inbyggt program kan du samla in åtkomst till mikrofonen eller kameran.
  • En användare aktiverar Siri, vilket ger åtkomst till mikrofonen.

Om till exempel ett PSTN-samtal kommer in i ett Azure Communication Services-anrop i iOS, aktiveras en mikrofonMutedUnexepectedly dålig UFD och ljudet slutar flöda i Azure Communication Services-anropet och samtalet markeras som avstängt. När PSTN-anropet är över måste användaren slå på ljudet från Azure Communication Services-anropet för att ljudet ska börja flöda igen i Azure Communication Services-anropet. När ett PSTN-samtal kommer in i Android Chrome slutar ljudet att flöda i Azure Communication Services-anropet och Azure Communication Services-anropet markeras inte som avstängt. I det här fallet finns det ingen mikrofonMutedUnexepectedly UFD-händelse. När PSTN-samtalet är klart återfår Android Chrome ljudet automatiskt och ljudet börjar flöda normalt igen i Azure Communication Services-anropet.

Om kameran är på och ett avbrott inträffar kan Azure Communication Services-anropet förlora kameran eller inte. Om den tappas bort markeras kameran som avstängd och användaren måste slå på den igen efter att avbrottet släppt kameran.

Ibland släpps inte mikrofon- eller kameraenheter i tid och det kan orsaka problem med det ursprungliga anropet. Om användaren till exempel försöker slå på ljudet när han eller hon tittar på en YouTube-video eller om ett PSTN-samtal är aktivt samtidigt.

Inkommande videoströmmar slutar inte återges om användaren är på iOS 15.2+ och använder SDK version 1.4.1-beta.1+. Stegen för att slå på/starta video krävs fortfarande för att starta om utgående ljud och video.

För iOS 15.4+ ska ljud och video kunna återställas automatiskt i de flesta fall. För att slå på ljudet i vissa gränsfall måste programmet anropa ett API för att "slå på ljudet" (kan bero på användaråtgärder) för att återställa det utgående ljudet.

iOS med Safari kraschar och uppdaterar sidan om en användare försöker växla från den främre kameran till den bakre kameran.

Azure Communication Services Calling SDK version 1.2.3-beta.1 introducerade en bugg som påverkar alla anrop från iOS Safari. Problemet uppstår när en användare försöker växla kameravideoströmmen framifrån och tillbaka. Om du växlar kamera resulterar det i att Safari-webbläsaren kraschar och läser in sidan igen.

Det här problemet har åtgärdats i Azure Communication Services Calling SDK version 1.3.1-beta.1 +

  • iOS Safari-version: 15.1

Skärmdelning i macOS Ventura Safari (v16.3 och lägre)

Skärmdelning fungerar inte i macOS Ventura Safari (v16.3 och lägre). Kända problem från Safari och kommer att åtgärdas i v16.4+.

Om du uppdaterar en sida tar du inte bort användaren från anropet direkt

Om en användare är i ett anrop och bestämmer sig för att uppdatera sidan, tar kommunikationstjänsten inte bort den här användaren omedelbart från anropet. Den väntar på att användaren ska återansluta. Användaren tas bort från anropet efter tidsgränsen för medietjänsten.

Det är bäst att skapa användarupplevelser som inte kräver att slutanvändarna uppdaterar sidan i ditt program under ett anrop. Om en användare uppdaterar sidan återanvänder du samma kommunikationstjänstanvändar-ID när användaren återvänder till programmet. Genom att återansluta med samma användar-ID representeras användaren som samma befintliga objekt i remoteParticipants samlingen. Från andra deltagares perspektiv i samtalet förblir användaren i samtalet under den tid det tar att uppdatera sidan, upp till en minut eller två.

Om användaren skickade video innan uppdateringen videoStreams behåller samlingen den tidigare dataströmsinformationen tills tjänsten överskrider tidsgränsen och tar bort den. I det här scenariot kan programmet bestämma sig för att observera alla nya strömmar som läggs till i samlingen och återge en med högst id.

Det går inte att återge flera förhandsversioner från flera enheter på webben

Det här problemet är en känd begränsning. Mer information finns i Översikt över SDK för samtal.

Det går inte att räkna upp enheter i Safari när programmet körs på iOS eller iPadOS

Program kan inte räkna upp eller välja högtalarenheter (t.ex. Bluetooth) i Safari iOS eller iPadOS. Det här problemet är en känd begränsning för dessa operativsystem.

Om du använder Safari på macOS kan din app inte räkna upp eller välja högtalare via Enhetshanteraren för Kommunikationstjänster. I det här scenariot måste du välja enheter via operativsystemet. Om du använder Chrome på macOS kan appen räkna upp eller välja enheter via Enhetshanteraren för Kommunikationstjänster.

  • iOS Safari-version: 15.1

Om videoenheter växlas upprepade gånger kan videoströmningen stoppas tillfälligt

Om du växlar mellan videoenheter kan videoströmmen pausas medan strömmen hämtas från den valda enheten. Att växla mellan enheter ofta kan orsaka prestandaförsämring. Det är bäst för utvecklare att stoppa en enhetsström innan de startar en annan.

Bluetooth-headsetmikrofon identifieras inte eller hörs inte under samtalet på Safari på iOS

Bluetooth-headset stöds inte av Safari i iOS. Bluetooth-enheten visas inte i tillgängliga mikrofonalternativ och andra deltagare kan inte höra dig om du försöker använda Bluetooth via Safari.

Den här regressionen är en känd begränsning för operativsystemet. Med Safari på macOS och iOS/iPadOS går det inte att räkna upp eller välja talarenheter via Kommunikationstjänsters enhetshanterare. Det beror på att Safari inte stöder uppräkning eller val av talare. I det här scenariot använder du operativsystemet för att uppdatera enhetsvalet.

Rotation av en enhet kan skapa dålig videokvalitet

När användarna roterar en enhet kan den här rörelsen försämra kvaliteten på video som strömmas.

Det här problemet uppstår i följande miljöer:

  • Enheter som påverkas: Google Pixel 5, Google Pixel 3a, Apple iPad 8 och Apple iPad X
  • Klientbibliotek: Anropa (JavaScript)
  • Webbläsare: Safari, Chrome
  • Operativsystem: iOS, Android

Kamera växling gör att skärmen låses

När en Communication Services-användare ansluter till ett samtal med hjälp av JavaScript-anropande SDK och sedan väljer knappen kameraväxel kan användargränssnittet sluta svara. Användaren måste sedan uppdatera programmet eller skicka webbläsaren till bakgrunden.

Det här problemet uppstår i följande miljöer:

  • Enheter som påverkas: Google Pixel 4a
  • Klientbibliotek: Anropa (JavaScript)
  • Webbläsare: Chrome
  • Operativsystem: iOS, Android

Videosignalsproblem när samtalet är i anslutningstillstånd

Om en användare aktiverar och inaktiverar video snabbt när anropet är i Anslut tillstånd kan den här åtgärden leda till ett problem med strömmen som hämtats för anropet. Det är bäst för utvecklare att skapa sina appar på ett sätt som inte kräver att video aktiveras och inaktiveras medan samtalet är i Anslut tillstånd. Försämrade videoprestanda kan inträffa i följande scenarier:

  • Om användaren börjar med ljud och sedan startar och stoppar video, medan samtalet är i Anslut tillstånd.
  • Om användaren börjar med ljud och sedan startar och stoppar video, medan samtalet är i läget Lobby .

Räkna upp eller komma åt enheter för Safari på macOS och iOS

I vissa miljöer kanske du märker att enhetsbehörigheter återställs efter en viss tidsperiod. I macOS och iOS behåller Safari inte behörigheter under en längre tid om det inte finns en dataström som har hämtats. Det enklaste sättet att kringgå den här begränsningen är att anropa API:et DeviceManager.askDevicePermission() innan du anropar enhetshanterarens api:er för enhetsuppräkning. Dessa uppräknings-API:er inkluderar DeviceManager.getCameras(), DeviceManager.getSpeakers()och DeviceManager.getMicrophones(). Om behörigheterna finns där ser användaren ingenting. Om behörigheterna inte finns där uppmanas användaren att ange behörigheterna igen.

Det här problemet uppstår i följande miljöer:

  • Enheten påverkas: i Telefon
  • Klientbibliotek: Anropa (JavaScript)
  • Webbläsare: Safari
  • Operativsystem: iOS

Fördröjning vid återgivning av videor för fjärrdeltagare

Under ett pågående gruppsamtal antar du att användare A skickar video och sedan ansluter användare B till samtalet. Ibland kan användare B inte se video från användare A eller användare A:s video börjar återges efter en lång fördröjning. Ett konfigurationsproblem för nätverksmiljön kan orsaka den här fördröjningen. Mer information finns i Nätverksrekommendationer.

Om du använder bibliotek från tredje part under samtalet kan det leda till ljudförlust

Om du använder getUserMedia separat i programmet går ljudströmmen förlorad. Ljudströmmen går förlorad eftersom ett bibliotek från tredje part tar över enhetsåtkomsten från Azure Communication Services-biblioteket.

  • Använd inte bibliotek från tredje part som använder API:et getUserMedia internt under anropet.
  • Om du fortfarande behöver använda ett bibliotek från tredje part är det enda sättet att återställa ljudströmmen att ändra den valda enheten (om användaren har fler än en) eller starta om anropet.

Det här problemet uppstår i följande miljöer:

  • Webbläsare: Safari
  • Operativsystem: iOS

Orsaken till det här problemet kan vara att anskaffning av din egen ström från samma enhet har en bieffekt av att köras i tävlingsförhållanden. Att hämta strömmar från andra enheter kan leda användaren till otillräcklig USB/IO-bandbredd och sourceUnavailableError hastigheten skjuter i höjden.

Överdriven användning av vissa API:er som mute/unmute resulterar i begränsning i Azure Communication Services-infrastrukturen

Som ett resultat av anropet mute/unmute API informerar Azure Communication Services-infrastrukturen andra deltagare i samtalet om tillståndet för ljud för en lokal deltagare som anropade mute/unmute, så att deltagarna i samtalet vet vem som är avstängd/oföränderliga. Överdriven användning av mute/unmute blockeras i Azure Communication Services-infrastrukturen. Begränsning sker om deltagaren (eller programmet för deltagarens räkning) försöker stänga av/slå på ljudet kontinuerligt, varje sekund, mer än 15 gånger i ett rullande 30-sekundersfönster.

Anropa Automation-API:er

Följande begränsningar är kända problem i API:erna för samtalsautomatisering i Communication Services:

  • Den enda autentisering som för närvarande stöds för serverprogram är att använda en anslutningssträng.

  • Gör endast anrop mellan entiteter av samma Communication Services-resurs. Kommunikation mellan resurser blockeras.

  • Samtal mellan klientanvändare av Microsoft Teams- och Communication Services-användare eller serverprogramentiteter tillåts inte.

  • Om ett program ringer ut till två eller flera PSTN-identiteter och sedan avslutar samtalet, avbryts samtalet mellan de andra PSTN-entiteterna.

Följande avsnitt innehåller information om kända problem som är associerade med Azure Communication Services Calling Native och Native UI SDK:er.

Android API-emulatorer

När du använder Android API-emulatorer på Android 5.0 (API-nivå 21) och Android 5.1 (API-nivå 22) förväntas vissa krascher.

Android Trouter-modulkonflikt

När Android Chat och Calling SDK är tillsammans i samma program fungerar inte chatt-SDK:ns realtidsaviseringar. Du kan få problem med att lösa ett beroende.

Medan vi arbetar med en lösning kan du inaktivera funktionen för realtidsaviseringar genom att lägga till följande beroendeinformation i appens build.gradle-fil och i stället avsöka Api:et GetMessages för att visa inkommande meddelanden för användare.

Java

 implementation ("com.azure.android:azure-communication-chat:1.0.0") {
     exclude group: 'com.microsoft', module: 'trouter-client-android'
 }
 implementation 'com.azure.android:azure-communication-calling:1.0.0'

Obs! Om programmet försöker röra någon av meddelande-API:erna som chatAsyncClient.startRealtimeNotifications() eller chatAsyncClient.addEventHandler(), uppstår ett körningsfel.

iOS pågående videoBild i bild (PiP)

Inkommande video stoppas när appen hamnar i bakgrunden. Om programmet är i förgrunden återges videon korrekt.

UI-bibliotek

Du kan följa wiki-sidan med kända problem på GitHub-lagringsplatserna.