Skype for Business Online – Cloud PBX, PSTN Anrufe und Audio & Video Problembehandlung

Technische Stufe: Expert


Zusammenfassung

PSNT Anrufe ist ein Аdd-on telefonischer Dienst, wenn es mit einem Skype for Business PBX kombiniert wird, kann es Ihr telefonisches System werden. PSTN Anrufe bieten den Benutzern in Ihrem Geschäft primäre Telefonnummer an und lässt die Benutzern Telefonanrufe außerhalb Ihre Organisation durchführen und empfangen.

Benutzer, denen Telefonnummern zugewiesen sind, können von allen Skype for Business-Geräten, einschließlich Desktop-Telefonen, PCs und mobilen Geräten, Sprachanrufe führen. Sie können Ihre Anrufe über Desktop-Telefone steuern, z. B. stumm schalten/freischalten, halten/fortsetzen, Anrufe weiterleiten und Anrufweiterleitungsfunktionen verwenden.

Weitere Information gibt es hier.

Bevor Sie eine Serviceanfrage bei Microsoft erstellen, gibt es mehrere Informationen, die gesammelt und untersucht werden können, damit das Problem besser zusammengefasst wird und eine schnellere Lösung gefunden wird.

Die Fragen an die Medien leiten Sie immer zu den beiden einfachsten Testpunkten.

Es ist verständlich, dass einige Szenarien nicht auf zwei einfache Punkte heruntergebrochen werden können.

Jedoch, wenn Sie das Szenario vereinfachen können, werden Sie Ihre Chancen das Problem zu beheben erhöhen.


Details

Verstehen Sie das Problem und prüfen Sie, ob das Problem auf Wunsch reproduziert werden kann.

Einige Beispiele, was Ihre Benutzer Ihnen zur Verfügung stellen könnten.

• 
  Können sich nicht gegenseitig anrufen.
  
  
• 
  Können zusammengeschlossenen Besprechungen (federated meetings) nicht beitreten.
  
  
• 
  Audio funktioniert external, aber Bildschirmfreigabe bricht ab.
  

Audio und Video Szenarien



1. Welche Klient Version benutzen Sie?

• 
  Skype for Business
  
  
• 
  Lync 2013
  

• Dritte Partei Programm

2. Welcher Klienttyp benutzen Sie?

• 
  Desktop
  
  
• 
  LRS
  
  
• 
  Mobile
  
  
• 
  Lync Telefon
  

• Telekonferenz

3. Welcher Anruftyp haben Sie versucht?

• 
  Internen zu externen
  
  
• 
  Internen zu internen
  
  
• 
  Externen zu externen
  
  
• 
  Föderierter Anruf
  

• PSTN

4. Wenn es ein PSTN Anruf ist:

• 
  Wo ist der Benutzer lokalisiert?
  
  • 
    Wenn es nicht beim externen Benutzer funktioniert, geht es beim internen Benutzer?
    
• 
  Welche Nummer haben Sie gewählt?
  
  
• 
  Funktionieren alle Nummer nicht?
  
  
• 
  Woran scheitert der Benutzer, Anrufe zu tätigen oder entgegenzunehmen?
  
  
• 
  Gibt es spezifische Fehlermeldung, wenn der Anruf scheitert?
  
  
• 
  Gibt es bestimmte Portale, die das Problem verursachen oder es besteht es mit allen Portalen?
  

5. Die Szenarien, die sich auf P2P in der gleichen Organisation beziehen, erlauben es einer ähnlichen Fragestellung zu folgen.

• 
  Gibt es vor den Edge-Server (interne oder externe Schnittstellen) eine HLB?
  
  
• 
  Gibt es Firewalls zwischen den Benutzern und die Edge Server?
  
  
• 
  Hat es jemals funktioniert?
  
  
• 
  Wenn dieses vorher funktioniert hat, sind Ihnen irgendwelche Änderungen bekannt, als dieses stoppte?
  
  
• Kennen Sie irgendwelche Bedingungen in Ihrem Netzwerk, die zu diesem Problem beitragen könnten?

6.Abhängig davon, wo die Ausfälle auftreten können, wird das Szenario des Föderierten Aufrufs stärker einbezogen.

• 
  Spielt es eine Rolle, wer die Konferenz startet?
  
  • 
    Heißt das, dass ein Skype for Business Gespräch mit föderierte Partner scheitert, aber die Partner können Ihre Gespräche beitreten?
    
• 
  Ist es davon abhängig, wo Ihre Endpunkte physikalisch lokalisiert basiert sind?
  
  • 
    Wenn Sie aus intern oder extern teilnehmen, gibt es eine Änderung Ihrer Erfahrung?
    
• 
  Hat es vorher funktioniert?
  
  
• 
  Wenn es gewisse Zeit funktioniert hat, wissen Sie bestimmte Änderungen, nachdem es nicht mehr funktioniert?
  
  
• 
  Können Sie ein anderes föderiertes Gespräch mit einem anderen Partner durchführen?
  
  
  Bitte überprüfen Sie auch den Artikel Medienqualität und Leistung der Netzwerkkonnektivität in Skype for Business Online.
  
  
  Problembehandlung
  

• 
  Schalten Sie die Fehlerprotokollierung ein (vollständig) in Ihrem Skype for Business Klient.
  
  
• 
  Schritt für Schritt Prozedur
  
  
• 
  Reproduzieren Sie das Problem
  
  • 
    Notieren Sie die SIP Adresse, damit es leichter ist, das Problem mit dem Anruf zu bestimmen.
    
    
  • 
    Sammeln Sie die SIP URI von beiden Benutzern oder die PSTN Nummer. Wenn diese an einem Gespräch teilnehmen, notieren Sie das Gespräch ID/URL.
    
• 
  Untersuchen Sie die gesammelten .uccapilog Datei mit Snooper aus dem Skype for Business Debug Programm oder mit TextAnalysisTool.NET
  
  • 
    Markieren Sie die Nachrichten Registerkarte, damit Sie nur die SIP Nachrichten untersuchen können.
    
• 
  In mehreren Anrufen Szenarien ist das Problem vom Ort des Benutzers abhängig, es ist wichtig zu verstehen, ob der Benutzer intern oder extern angemeldet ist. Überprüfen Sie das, in dem Sie in .uccapilog nach Folgendes suchen:
  
  • 
    Ms-user-logon-data
    
    
  • 
    Wenn dieser Header existiert, wird er mit einem Remote-User-Tag angezeigt, ob der Klient extern angemeldet ist (durch Edge), und wenn es keinen Header mit Remote-User-Tag gibt (es sind keine Suchergebnisse zurückgegeben), dann ist der Benutzer intern angemeldet.
    
• 
  Beim Verbindungsaufbau für Medien gibt es SDP (Session Description Protocol) Information, die in der SIP Datei gespeichert wird.
  
  Abhängig vom Mediatyp (Audio/Video/Desktopfreigabe/Ordner transferieren) gibt es manche Suchparameter, die Ihnen helfen können, den Anruf wo das Problem reproduziert wurde, zu finden.
  
  Diese Parameter werden nach der Medialinie (m=) für den entsprechenden Mediatyp suchen:
  
  
• 
  Audio Anruf m=audio
  
  
• 
  Video Anruf m=video
  
  
• 
  Desktop Freigabeanruf / m=applicationsharing
  
  
• 
  Anwendungsfreigabeanruf
  
  
• 
  Datei Übermittlungsanruf m=data
  
  
• 
  Instant Message Call m=message
  
  
• 
  Wenn Sie die obere Tabelle nutzen, suchen sie nach der bestimmten Media (m=), damit Sie finden können, wo das Problem reproduziert wird.
  
  Finden Sie ein anderer betroffener Benutzer und verwenden Sie die Zeitstempel für Bestätigung des Zeitraums, in dem das Problem aufgetreten ist, führt am besten zur Nullung des Anrufs, in denen das Problem aufgetreten ist. Wenn Sie den Anruf finden, klicken Sie mit der rechten Maustaste auf INVITE und markieren Sie die Option “Find Related”, damit Sie die entsprechenden SIP Pakete für den problematischen Anruf finden.
  
  
• 
  Untersuchen Sie die Kandidaten (candidates) in beiden Seiten vom Anruf (typischerweise die beiden beteiligten Benutzer, aber je nach Szenario kann es sich um einen Benutzer und einen Server handeln).
  
  Überprüfen Sie die SDP Information innerhalb der INVITE für anrufende Benutzer und die 183 Session Progress/200 OK für den empfangenen Benutzer untersuchen.
  
  Wenn Sie SDP untersuchen, ist es leichter die ICEv19 candidates zu lesen anstatt die ICEv6 candidates.
  
  
• 
  Content-Type: application/sdp
  
  Content-Transfer-Encoding: 7bit
  
  Content-ID <Emailaddresse>
  
  Content-Disposition: session; handling=optional; ms-proxy-2007fallback
  
  
  Gegen die gleichen Candidates in ICEv19:
  

• 
  Content-Type: application/sdp
  
  Content-Transfer-Encoding: 7bit
  
  Content-ID <Emailaddresse>
  
  Content-Disposition: session; handling=optional
  
  
• 
  Candidate Analyse (Eine eingeschränkte Form der Optimierungsrisikomodellierung, bei der nur eine endliche Anzahl vordefinierter Entscheidungsoptionen berücksichtigt wird und die beste dieser Optionen durch die Analyse ermittelt wird). Es gibt mehrere Schlüsselpunkte, nach denen Sie bei der Analyse der resultierenden Candidate -Einstellungen für einen Anruf suchen müssen, aber was Sie suchen, hängt vom Medientyp ab. Audio und Videoanrufe können UDP und TCP Candidate anbieten, aber die Modalitäten werden die UDP Candidate als letzte Option bevorzugen, wenn Sie sich mit der Media verbinden.
  
  Desktop / Anwendungen Freigabe und Peer-to-Peer Dateiübertragung können nur die TCP Candidate nutzen und aus diesem Grund werden Sie nur die TCM Candidate als Option in SDP nutzen (UDP Candidate wird für diese Modalitäten nicht angeboten).
  
  
• 
  Die Candidates werden als Portpaare erscheinen (einen für RTP und einen für RTCP) oder als Einzelport für RTP und ein Paar wird durch die erste angegebene Zahl gekennzeichnet in Candidatenattributenlinie (a= line).
  
  
• 
  Zusätzlich, jeder Kandidat hat einen Werttyp, der den gelisteten Candidate Typ bezeichnet. Die gebräuchlichsten Typen sind host, relay und srflx (server reflexive):
  

• 
  Host >- Vom Hostsystem bereitgestellter Candidate (IP-Adresse des Clientsystems)
  
  
• 
  relay >- Vom Edge-Server zur Verfügung gestellter Candidate für Relayzwecke
  
  
• 
  srflx >- Vom Edge-Server bereitgestellter Candidate, der versucht, die öffentliche IP des Clientsystems aufzufinden (dies ist nützlich in Szenarien, in denen Benutzer extern sind, aber immer noch hinter einem NAT stehen).
  

• 
  Wenn der Verbindungsaufbau aufgrund von Medienverhandlungen scheitert, gibt es oft ein Problem, Relay-candidates zu erhalten, da Clients in der Regel nicht im selben Netzwerk sind und daher nicht in der Lage sind, direkt zu kommunizieren.
  
  
• 
  Untersuchen Sie im UccApilog die BYE-Nachricht für den fehlgeschlagenen Aufruf. Speziell im BYE wird es eine MS-Client-Diagnose-Kopfzeile mit einer Fehlerbeschreibung geben. Zusätzlich wird eine ICEWARN in derselben BYE-Nachricht enthalten sein, die anzeigt, ob es irgendwelche Probleme mit den Candidates gab. Verwenden Sie das ICEWarn-Programm, um einige der möglichen Ursachen für Probleme bei Medienverhandlungen zu ermitteln.
  
  
• 
  Nachdem beide Parteien einen vollständigen Candidate Set haben, und der Anruf noch nicht beendet ist, dann die beste Option ist UccApilogs und Netzwerktraces an allen beteiligten Standorten:
  

• 
  UccApilog aus einem der beiden Clientsysteme
  
  
• 
  Netzwerk-Untersuchung aus beiden Clientsystemen
  
  
• 
  Netzwerk-Untersuchung von den beteiligten Edge-Servern.
  

• 
  Nach der Erfassung der Netzwerk-Trace-Daten muss analysiert werden, warum die beiden Clients nicht miteinander kommunizieren können.
  
  Der erste Schritt ist die Verwendung des UccApilog, um die Ports zu bestimmen, die am Gespräch beteiligt sind, so dass die Netzwerkspuren effektiv gefiltert werden können, um festzustellen, warum der Anruf nicht aufgebaut werden kann. Nachdem Sie die Port-Informationen aus dem UccApilog gezogen haben, erstellen Sie Filter für die Netzwerk-Untersuchung, die Sie wie folgt verwenden können.
  

udp.port==X || udp.port==Y //Client A

udp.port==M || udp.port==N //Client B

• 
  Diese kann weiter verfeinert werden, um jeweils nur eine einzige Richtung zu betrachten, indem Sie Filter wie die folgenden verwenden.
  

udp.srcport==X

udp.srcport==X

• 
  Diese Art von Filtern zeigt den Verkehr von Mandant A nach B bzw. Mandant B nach A in jedem Trace an, aber da es während des Verhandlungsprozesses mehrere Kandidatenpaare gibt, ist es wahrscheinlich notwendig, dies für mehrere Kandidaten zu überprüfen.
  
  
• 
  Darüber hinaus ist es für die Isolierung von Problemen mit dem Datenverkehr zu/von Edge-Servern unerlässlich, die gleichen Kandidaten zu verfolgen, wenn Pakete durch Server fließen. Sobald das Problem mit der Medieneinrichtung und dem Sammeln von Netzwerkspuren aufgetreten ist, wird das Problem in der Regel bei einem Gerät im Netzwerk auftreten, und es geht darum, dieses Problem zu finden, um Ihr Netzwerkteam zu unterstützen.