Fehlerbehebung: CUCM MediaSense Call Recording

Einleitung

In diesem Dokument wird die Fehlerbehebung für MediaSense beschrieben, wenn bei der Anrufaufzeichnung für eine integrierte Bridge ein Fehler auftritt.

Grundlegender MediaSense-Anrufablauf mit integrierter Bridge

Dieses Bild veranschaulicht den grundlegenden MediaSense-Anruffluss bei Verwendung einer integrierten Bridge: 

Hinweis: Bei IP-Telefon A ist die Aufzeichnung aktiviert.

Diese Schritte beschreiben den Anruffluss:

1. Das IP-Telefon auf der rechten Seite ruft das IP-Telefon auf der linken Seite an und initiiert den Anruf über den Cisco Unified Communications Manager (CUCM).
   
   
2. Der CUCM sendet ein Signal an das Zieltelefon und schließt die Anrufeinrichtung ab.
   
   
3. Die Verbindung zwischen IP-Telefon A und IP-Telefon B ist nun eingerichtet.
   
   
4. Das Aufzeichnungsprofil auf IP-Telefon A besagt, dass der CUCM eine Sitzung mit MediaSense einrichten muss, sobald er einen Anruf erhält. Dieser Vorgang ist Millisekunden nach Beginn von Schritt 3 abgeschlossen.
   
   
5. Der Anruf wird nun zwischen den beiden Telefonen eingerichtet, der Anruf wird über die integrierte Bridge weitergeleitet, und die integrierte Bridge sendet zwei RTP-Streams (Real-time Transport Protocol) an den MediaSense-Server.

Keine Aufzeichnung auf MediaSense

Wenn Sie eine Fehlermeldung erhalten, die besagt, dass keine Aufzeichnung auf MediaSense erfolgt, müssen Sie die Protokolle anzeigen und nach dieser Sitzungs-ID suchen:

0000049583: 10.201.227.136: May 28 2014 11:27:09.022 -0400: %CCBU_COMMON-6-VSMS
 HTTP Info: {Thrd=Pool-capture-thread-2800} %[HTTP Response Body=<Session>
   <diskusage>
      <recording name="78e146437088a93-TRACK0" size="0" repository="/
       recordedMedia" />
      <recording name="78e146437088a93-TRACK1" size="0"repository="/
       recordedMedia" />
   </diskusage>
</Session>][HTTP Response Content Type=application/xml][HTTP Response Status
 Code=200][logId=close-25668]: VSMS Received HTTP Response

Die Größe="0" in dieser Ausgabe zeigt an, dass für diesen Anruf kein Audio auf dem Server aufgezeichnet wurde. Dies bedeutet in der Regel, dass der RTP-Stream vom Telefon nicht zum MediaSense-Server gelangt ist. In diesem Fall besteht der nächste Schritt darin, zu überprüfen, ob das Telefon den RTP-Verkehr sendet.

Überprüfung, ob IP-Telefon Datenverkehr sendet

Eine schnelle Möglichkeit, zu überprüfen, ob das IP-Telefon den RTP-Verkehr sendet, besteht darin, die Webseite des IP-Telefons anzuzeigen. Dies ist auf CUCM manuell auf der Seite für die Telefonkonfiguration oder über den Bulk-Administrator aktiviert.

Stream 1 ist der Hauptruf mit der Remote-Adresse des anderen IP-Telefons oder Gateways. Diese besteht aus zwei Streams: Der erste ist der Ton, der auf dem IP-Telefon empfangen wird, und der zweite ist der Ton, der an das andere Ende gesendet wird.

Um zu überprüfen, ob MediaSense beide Anrufabschnitte aufzeichnet, klicken Sie auf Stream 2 und Stream 3, um zu überprüfen, ob sich die Absenderpakete erhöhen, wenn die Seite mehrmals aktualisiert wird. Die Remoteadresse sollte den MediaSense-Server sowohl für Stream 2 als auch für Stream 3 anzeigen. Der Grund, warum es zwei Streams zum MediaSense-Server gibt, liegt darin, dass einer von ihnen die auf Stream 1 (Receiver Packets) empfangene Audiodatei und der andere die auf Stream 1 gesendete Audiodatei (Sender Packets) ist.

Hinweis: In Bezug auf das zuvor beschriebene Anrufflussdiagramm ist Schritt 3 Stream 1 und jede Etappe von Schritt 5 bezieht sich auf Stream 2 und Stream 3.

Diese Aufzeichnung zeigt Stream 1 an:

Diese Aufzeichnung zeigt Stream 2:

Hinweis: Es ist wichtig, die IP-Adresse und den Port im Abschnitt Remote Address (Remote-Adresse) auf der Seite zu beachten. Dies ist sehr wichtig, wenn Sie die Paketerfassung für Testanrufe durchführen.

Diese Aufzeichnung zeigt Stream 3:

Wenn Sie die Daten für Stream 2 und Stream 3 überprüfen, sind folgende Hauptaspekte zu beachten:

• Die Remote-Adresse ist die IP-Adresse des MediaSense-Servers.
  
  
• Die Portnummer jedes Streams ist eindeutig.
  
  
• Wenn Sie die Seite aktualisieren, erhöht sich die Anzahl der Absenderpakete.

Dies zeigt an, dass die RTP-Pakete vom IP-Telefon gesendet werden.

Paketerfassung durchführen

Wenn Sie sich immer noch nicht sicher sind, ob das IP-Telefon die RTP-Pakete sendet, besteht der nächste Schritt darin, eine Paketerfassung durchzuführen und die Streams erneut abzuspielen.

Bevor Sie die Paketerfassung durchführen, stellen Sie sicher, dass die folgenden Einstellungen in der IP-Telefonkonfiguration für CUCM aktiviert sind:

• Von PC-Port
• Sprach-VLAN-Zugriff auf PCs
• PC-Port

Wenden Sie dann die Konfiguration an, und setzen Sie das IP-Telefon zurück. Öffnen Sie nach Abschluss dieses Vorgangs Wireshark, und führen Sie eine Paketerfassung mit einer Dauer von 30 Sekunden durch. Stellen Sie sicher, dass Sie die Remote-Adresse sowie den Port für Stream 2 und Stream 3 des betreffenden IP-Telefons aufzeichnen. Beispiele:

• Stream 2 - 10.201.227.147/40676
• Stream 3 - 10.201.227.147/33358

Wenn die Paketerfassung abgeschlossen ist, öffnen Sie die Paketerfassung, und führen Sie die folgenden Schritte für jeden Stream aus:

1. Filtern Sie nach ip.addr == 10.201.227.147 && udp.port == 40676.
   
   
2. Navigieren Sie zu Analysieren > Decodieren als.
   
   
3. Wählen Sie im Popup-Fenster RTP aus, und klicken Sie auf OK.
   
   
4. Navigieren Sie zu Telefonie > RTP > Stream Analysis (Datenverkehrsanalyse).
   
   
5. Navigieren Sie in der RTP-Stream-Analyse zu Player > Decode > Play, und überprüfen Sie, ob beide Teile des Anrufs gehört wurden.
   
   
6. Wiederholen Sie die Schritte 1 bis 4 für den anderen Stream und Port.

Fehlerbehebung

Nachdem Sie die Paketerfassung durchgeführt und sichergestellt haben, dass MediaSense ordnungsgemäß konfiguriert ist und dass das IP-Telefon einen gültigen RTP-Stream an den MediaSense-Server sendet und weiterhin Probleme auftreten, sollte der Pfad zwischen dem Server und dem IP-Telefon überprüft werden.

Stellen Sie sicher, dass der Pfad über keine Zugriffskontrolllisten (ACLs) verfügt und den RTP-Verkehr nicht blockiert oder filtert.

Wichtige Hinweise

Wenn der mit CUCM eingerichtete Anruf in Frage gestellt wird, überprüfen Sie die detaillierten CUCM-Protokolle, und öffnen Sie die MediaSense-Protokolle, um die Anruf-ID zu ermitteln. Die Sitzungs-ID sieht in den Anrufsteuerungsprotokollen ähnlich aus:

CallId: 74acba00-38c1ea2d-3a2937-f183000a@10.0.131.241
CallId: 74acba00-38c1ea2d-3a2938-f183000a@10.0.131.241

Da das IP-Telefon zwei Streams mit MediaSense einrichtet, einen für jeden Abschnitt des ursprünglichen Anrufs, durchsuchen Sie die CUCM-Protokolle mit einer der Anruf-IDs, um zu überprüfen, ob die MediaSense-Sitzung ordnungsgemäß eingerichtet ist.