Bedienungs-, Konfigurations- und Fehlerbehebungsleitfaden für CUBE

Einführung

Dieses Dokument beschreibt Informationen zu Betrieb, Konfiguration und Fehlerbehebung für Multicast Music-on-Hold (MoH) durch Cisco Unified Border Element (CUBE).

Obwohl der Schwerpunkt dieses Dokuments auf Multicast Music-on-Hold (MoH) liegt, widmet sich ein wesentlicher Teil der Beschreibung der allgemeinen Funktionsweise der Warteschleifenmusik. Diese zusätzlichen Informationen tragen dazu bei, ein Basiswissen für den Anfänger aufzubauen, um Probleme, die spezifisch für den Einsatz im Stadium sind, besser erkennen und einschätzen zu können.

Hinweis: Obwohl die Prinzipien identisch sind, fällt die Cisco Unified Border Element-Service Provider Edition (CUBE-SP) nicht in den Geltungsbereich dieses Dokuments, noch wird CUBE in Umgebungen eingesetzt, in denen Cisco Unified Communications Manager (CUCM) nicht involviert ist.

Voraussetzungen

Anforderungen 

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrund

Hinweis: Mit Ausnahme einiger Szenarien, die für H.323 veranschaulicht werden, wird die SIP-Signalisierung (Session Initiation Protocol) in den meisten Teilen dieses Dokuments verwendet.

Warteschleifenmusik - Übersicht

Die Warteschleifenmusik wird immer wiedergegeben, wenn ein Anrufer in die Warteschleife gestellt wird. Die Anruf-Halten-Funktion wird entweder vom Benutzer oder vom Netzwerk initiiert, wenn ein zusätzlicher Serviceprozess wie Anrufweiterleitung oder -weiterleitung implementiert wird. Erstere werden als vom Benutzer initiierte Warteschleifen, Benutzerzugriffe oder Benutzerzugriffe bezeichnet. Letzteres wird als vom Netzwerk initiierte Warteschleife, Netzwerk-Halten oder Netzwerkhold bezeichnet.

Im Folgenden wird die Funktionsweise von Warteschleifenmusik mit TDM-Gateways (Time Division Multiplexing) beschrieben. Dieses Bild zeigt die Komponenten und Verbindungen, die in einem Anrufhaltezenario enthalten sind:

 

Um einen Anruf in die Haltestellung zu versetzen, ist ein zweistufiger Prozess erforderlich. Dieses Bild zeigt die beiden Schritte:

 

Tipp: Denken Sie an diesen zweistufigen Prozess, wenn Sie versuchen, die Warteschleifenmusik zu sortieren und Probleme zu beheben.

Warteschleifenmusik-Quellen

Der Benutzer, der einen Anruf in die Warteschleife setzt, wird als Inhaber bezeichnet, und der Benutzer, der in die Warteschleife gestellt wird (und die Warteschleifenmusik hört), wird als Gesprächspartner bezeichnet. Jede Seite entscheidet über bestimmte Aspekte der abgespielten Musik.

 

Die Musikquelle wird vom Inhaber bestimmt. Die Bestimmung folgt dieser Hierarchie:

1. Die für den Domänennamen (DN) konfigurierte Musikquelle
2. Die auf dem Gerät konfigurierte Musikquelle
3. Die Musikquelle im Geräteprofil (nur Quelle für Warteschleifenmusik)
4. Die Musikquelle auf globaler Ebene (Serviceparameter oder Beispiel)

Es gibt zwei Musikquellen, die als "User-Hold" und "Network-Hold" bezeichnet werden. Bei jedem Verweis auf die Musikquelle kann es sich um eine Quelle für "user-hold" oder "network-hold" handeln.

Warteschleifenmusik-Endgeräte

Für Warteschleifenmusik ist der Endpunkt auf der CUCM-Seite der Warteschleifenmusik-Server. Dies ist wichtig zu verstehen, da die Codec-Bestimmung (basierend auf der Codec-Konfiguration für mehrere Regionen) auf folgenden Komponenten basiert:

• Der Serverbereich für Warteschleifenmusik
• Der Trunk-/Gateway-Bereich

Generell wird empfohlen, dem Warteschleifenmusik-Server eine dedizierte Region zuzuweisen, sodass der regionale Codec zwischen dieser Region und allen anderen Regionen g.711 lautet (oder ein anderer Codec, den Sie für Warteschleifenmusik freisetzen möchten).

Aus CUCM-Sicht sind die Endpunkte, an denen der Anruf stattfindet, nicht die beiden Telefone, sondern vielmehr:

• Das beim CUCM registrierte IP-Telefon
• Gateway/CUBE

Daher behandelt CUCM den Trunk, der auf das betreffende Gateway/CUBE verweist, als Endgerät und untersucht die ihm zugeordneten Ressourcen, um zu bestimmen, wie der Musikstream wiedergegeben wird.

Warteschleifenmusik - VoIP-Protokoll

Warteschleifenmusik ist per Definition ein unidirektionales Audiogespräch. Die Signalisierung hängt vom verwendeten VoIP-Protokoll ab. Auf SIP wird dies beispielsweise über das richtung-Attribut übermittelt. Auf H.323 gibt der CUCM 0000000 als Netzwerkadresse und 0 als Port (tsapIdentifier) des MoH-Servers in der H.245-Nachricht Open Logical Channel Ack (OLCAck) an.

Hinweis: Für Warteschleifenmusik sendet CUCM die Multicast-Adresse (z. B. 239.1.1.1) als Netzwerkadresse.

Bei Anrufströmen, die CUBE beinhalten, hat der CUCM keine Kenntnisse über die Anrufverbindung zwischen CUBE und dem Internet Telefony Service Provider (ITSP). Der CUCM befasst sich nur mit dem Anrufabschnitt zwischen dem IP-Telefon und dem SIP-Trunk (führt zu CUBE).

Der Prozess der Signalisierung für Warteschleifenmusik ähnelt der Signalisierung für ein neues Gespräch mit geringerem Umfang. In SIP beispielsweise findet die Konversation im Kontext des bereits bestehenden Dialogs statt.[1]

Deaktivieren Sie den Media Stream.

Der erste Schritt des oben genannten zweistufigen Prozesses ist die Deaktivierung des Medien-Streams.

Dieses Bild zeigt, wie der Medienstream in SIP deaktiviert ist:

 

SIP-Implementierungen variieren, ob ein oder beide Attribute (?a=? und ?C=IN ?) verwendet werden, um anzugeben, dass der Medien-Stream deaktiviert ist.

Dieses Bild zeigt, wie der Medienstream im H.323 deaktiviert ist:

  

Verbindung mit Warteschleifenmusik

Der zweite Schritt des zuvor erwähnten zweistufigen Prozesses ist die Verbindung mit Warteschleifenmusik. Sobald der Audio-Stream deaktiviert ist, signalisiert der CUCM die unidirektionale Warteschleifenmusik-Konversation, die den Hörer auf die Warteschleifenmusikquelle veranlasst.

Im Rahmen dieses Prozesses berücksichtigt CUCM die Medienfunktionen des Holdes und die MRGL (Media Resource Group List), die dem Trunk zugeordnet sind, bevor die Parameter für das Streaming festgelegt werden. Entsprechend ist die Signalisierung dafür immer verzögertes Angebot (DO)[2] (in SIP).

Die tatsächliche Anzahl der INVITE-Transaktionen variiert. Beispielsweise verbindet CUCM den Besitzer mit Warteschleifenmusik mit nur einer DO INVITE-Transaktion. Alternativ dazu wird die DO-INVITE-Nachricht verwendet, um die Medienfunktionen des Gesprächspartners zu erfassen, und es wird eine weitere EO-EINLADUNG verwendet, um den Gesprächspartner mit Warteschleifenmusik zu verbinden.

Dieses Bild zeigt die Transaktion für SIP:

Dieses Bild zeigt die Transaktion für H.323:

Dieses Bild zeigt die Signalisierungsnachrichten-Sequenz in einer Interworking-Umgebung (wenn eine Seite von CUBE beispielsweise SIP und die andere Seite H.323 ist):

 

Wenn Medienressourcen in einem Anruf verwendet werden

Medienressourcen (MediaTermination Point (MTP)/Transcoder) schützen größtenteils den CUBE-to-IT Service Provider (ITSP)-Anrufbereich. Wenn eine Medienressource bei einem Anruf über CUBE verwendet wird, umfasst die Signalisierung für Warteschleifenmusik meist SCCP-Nachrichten (Skinny Client Control Protocol) zwischen dem CUCM und der Medienressource. Beachten Sie, dass es sich um die Medienressource handelt, die in die Warteschleife gestellt wird, nicht um den CUBE-Trunk. Nachdem der MTP/Transcoder signalisiert wurde, die Warteschleifenmusik zu hören (vorausgesetzt, SIP ist vorhanden), sendet der CUCM eine SIP-UPDATE-Nachricht an CUBE. Dadurch wird der Zweigstellenparameter aktualisiert, der die neue Transaktion identifiziert (die MOH-Konversation).

Anruf fortsetzen

Der Resume-Prozess ähnelt dem Hold-Prozess, mit der Ausnahme, dass die Bestellung rückgängig gemacht wird:

1. Der aktuelle Audio-Stream ist deaktiviert.
2. Es wird eine weitere DO re-INVITE-Nachricht gesendet, um den Gesprächspartner wieder mit dem Telefon zu verbinden, das den Anruf gehalten hat. 

SDP-Attribut

Das X-cisco-media:umoh-Attribut im Session Description Protocol (SDP) wurde eingeführt, um die Warteschleifenmusik-Signalisierung über Intercluster-Trunks (ICTs)[3] zu vereinfachen. Bei der Interaktion zwischen Endpunkten, die verschiedene Protokolle verwenden, führt CUCM oft eine unangenehme und intermediäre Signalisierung durch, die nicht intuitiv ist. Um Mutmaßungen zu vermeiden und den Signalisierungskontext explizit zu definieren, wird ein proprietäres SDP-Attribut mit dem Namen X-cisco-media verwendet.

Bei CUCM-Versionen 8.5 und höher kann Warteschleifenmusik [4] signalisiert werden, wobei dieses Attribut entweder auf Unicast Music on Hold (UMoH) oder MoH festgelegt ist, wodurch die Abhängigkeit von einem gefälschten Port-Wert für die Anzeige eines Warteschleifenmusik-Szenarios für den gehaltenen Teilnehmer aufgehoben wird.

Hinweis: Dies wirkt sich nicht auf die Warteschleifenmusik-Signalisierung mit CUBE aus.

Warteschleifenmusik auf CUBE

Mit CUBE bleibt der grundlegende Prozess unverändert. Es ist jedoch wichtig zu bedenken, dass [5] CUBE die Warteschleifenmusik erst nach Cisco IOS transcodiert^? Version 15.3T Dies bedeutet, dass Sie mit den Faktoren, die die Codec-Auswahl im CUCM-to-CUBE-Bereich beeinflussen, vorsichtig sein müssen, damit kein Transcoder benötigt wird.

Hinweis: Der hier genannte Transcoder wird von CUBE (im Gegensatz zu CUCM) eingefügt. Für CUCM ist das CUBE das Ziel, und es umfasst keinen Transcoder im MoH-Server-zu-CUBE-Pfad.

Codec-Überlegungen

Im Allgemeinen wirken sich mehrere Faktoren auf den Codec aus, der im CUCM-to-CUBE-Bereich verwendet wird. Diese Überlegungen gelten jedoch für Warteschleifenmusik:

• Warteschleifenmusik kann nicht transkodiert werden.[5]
• Warteschleifenmusik klingt nur bei G.711 gut.

Hinweis: Dieses Thema ist nicht Bestandteil dieses Dokuments, da bereits viele gute Dokumente zu Codec-Überlegungen vorliegen und es nicht erforderlich wäre, es hier zu behandeln.

MMoH

Hinweis: Die meisten der in diesem Dokument bisher beschriebenen Informationen sind relevant, ob die Warteschleifenmusik mit Unicast- oder Multicast-IP-Paketen gestreamt wird.

Durch Warteschleifenmusik werden Systemressourcen und Bandbreite eingespart. Mit Multicast können mehrere Benutzer denselben Audio-Quell-Stream verwenden, um Warteschleifenmusik bereitzustellen. In allen Unternehmensnetzwerken, in denen Bandbreiteneinsparungen wichtig sind, ist Warteschleifenmusik wünschenswert.

Im Folgenden sind einige Bedenken und Probleme aufgeführt, wenn CUBE den Warteschleifenmusik über das Internet an den ITSP weiterleitet:

• Erreichbarkeit von Multicast-Datenverkehr - Cisco verwendet für Multicast-Musik den Bereich 239.0.0.0 bis 239.255.255.255. Dieser Bereich wird als Adressen mit administrativem Zuständigkeitsbereich bezeichnet. Dieser Block wird als privat betrachtet, d. h. er wird von Unternehmensnetzwerken verwendet und sollte niemals außerhalb des Unternehmens weitergeleitet werden. Die Begrenzungsrouter werden in der Regel entsprechend konfiguriert.
• Multicast over VPN - Die IP-Sicherheit unterstützt standardmäßig kein Warteschleifenmusik.

So unterstützt CUBE Warteschleifenmusik:

1. CUBE empfängt die Warteschleifenmusik-Pakete vom Warteschleifenmusik-Server.
2. Die Pakete werden in Unicast-IP-Pakete konvertiert.
3. CUBE leitet die Pakete an den ITSP weiter.

SIP-Richtungsattribut-Manipulation

Wie in RFC 3264 beschrieben:

"Wenn eine Sitzungsbeschreibung einen Multicast-Medienstream enthält, der nur als Empfänger (Senden) aufgeführt ist, bedeutet dies, dass die Teilnehmer, einschließlich des Angebots und des Antworters, nur in diesem Stream empfangen (senden) können. Dies unterscheidet sich von der Unicast-Ansicht, bei der sich die Direktionalität auf den Medienfluss zwischen Anbieter und Antwort bezieht. Über diese Klarstellung hinaus entspricht die Semantik eines angebotenen Multicast-Streams genau der Beschreibung in RFC 2327 [1]"

Wenn der CUCM eine Re-INVITE-Nachricht mit einer Multicast-IP-Adresse sendet, legt er dementsprechend das direction-Attribut auf recvonly fest. Da CUBE die Multicast-Pakete jedoch in Unicast-Pakete konvertiert, muss das direction-Attribut so festgelegt werden, dass es mit dem ITSP nur auf der Strecke sendet.

Dieses Bild veranschaulicht die Logik:

  

Adressenmanipulation

Im gesendeten DO[6] Re-INVITE-Nachricht, um den ITSP-Anrufer mit der Warteschleifenmusik-Quelle zu verbinden, sendet CUBE seine eigene IP-Adresse im SIP SDP C=IN-Feld. Dies ist eine Unicast-Adresse.

Dieses Bild bietet eine End-to-End-Ansicht:

 

Hinweis: CUBE muss Cisco IOS Version 15.2(2)T oder höher ausführen, um Warteschleifenmusik zu unterstützen. 

Stream aus einem Flash

Durch das Streaming der Multicast-Musik direkt vom Gateway aus werden mit TDM-Gateways zusätzliche WAN-Bandbreiteneinsparungen realisiert. Wenn sich der Warteschleifenmusik-Server im Hauptsitz befindet und sich das Gateway in einer Zweigstelle über eine WAN-Verbindung befindet, muss Multicast-Datenverkehr, der die Warteschleifenmusik überträgt, nicht das WAN (vom Hauptsitz zur Zweigstelle) passieren und die wertvolle WAN-Bandbreite nutzen.

CUBE ist ein Trunk-seitiges Gerät, das kein Streaming von Warteschleifenmusik zulässt, das vom lokalen Flash-Speicher oder einer analogen TDM-Schnittstelle stammt. Die WAN-Bandbreite lässt sich noch realisieren. Dies wird durch die Verwendung eines anderen sprachfähigen Routers in der Außenstelle als Quelle des Warteschleifenmusik-Streams erreicht. Dieser Router streamt die Warteschleifenmusik aus dem Flash-Speicher. Das CUBE kann dann signalisiert werden, um diese Pakete zu empfangen, zu konvertieren und als Unicast-Pakete weiterzuleiten.

Stream aus einem Live-Feed

Um von einem Live-Feed zu streamen, muss ein anderer Router konfiguriert werden, da CUBE kein Line-Side-Gerät ist, wie im vorherigen Abschnitt beschrieben.

Konfigurieren von Warteschleifenmusik

In diesem Abschnitt wird die Konfiguration von Warteschleifenmusik auf CUBE-, CUCM- und L3-fähigen Switches beschrieben.

Konfigurieren von Warteschleifenmusik auf CUBE

Verwenden Sie diese Befehle, um Warteschleifenmusik auf CUBE zu konfigurieren:

ccm-manager music-on-hold
ip multicast-routing

Konfigurieren von Warteschleifenmusik auf CUCM

Führen Sie die folgenden Schritte aus, um das Warteschleifenmusik auf dem CUCM zu konfigurieren:

1. Aktivieren Sie Multicast-Funktionen an der Warteschleifenmusik-Quelle, am Warteschleifenmusik-Server und in der Media Resource Group (MRG).
2. Weisen Sie dem Trunk eine MRGL zu, wobei die in Schritt 1 konfigurierte MRG konfiguriert ist.
3. Konfigurieren Sie den Codec in den Dienstparametern der IP-Sprach-Streaming-Anwendung.

Hinweis: Ausführliche Konfigurationsschritte finden Sie im Abschnitt "Music on Hold" (Warteschleifenmusik) im Artikel Cisco Unified Communications System 9.0 SRND - Media Resources (Cisco Unified Communications System 9.0 SRND - Medienressourcen).

Konfigurieren von Warteschleifenmusik auf L3-fähigen Switches

Verwenden Sie diese Befehle, um Warteschleifenmusik auf L3-fähigen Switches zu konfigurieren:

ip routing
ip multicast-routing

Wenn MTP in einem Anruf verwendet wird

MTPs unterstützen keine Multicast-Musik. Der Holder erhält nur tote Luft.[7]

Hinweis: Transcoder sind auch MTPs.

Überlegungen zur Leistung

Alle MMOH-Pakete werden in Cisco IOS prozessgesteuert. Dies ist gut für kleine Bereitstellungen, hat jedoch erhebliche Auswirkungen auf die Leistung von CUBE für große Installationen.

Einschränkungen

Im Folgenden finden Sie eine Liste von Einschränkungen für die Verwendung von Warteschleifenmusik:

• CUBE muss die Cisco IOS-Version 15.2(2)T oder höher aufweisen.
• Das ModemH wird auf AS54xx nicht unterstützt.
• Warteschleifenmusik wird auf ISR-G1 nicht unterstützt (28xx-, 38xx-Serie)
• Beachten Sie die unterstützten Codecs.

Fehlerbehebung

In diesem Abschnitt finden Sie eine Fehlerbehebung für Warteschleifenmusik. 

Befehle anzeigen und debuggen

Im Folgenden finden Sie eine Liste mit Befehlen zum Anzeigen und Debuggen sowie deren Bedeutung:

• Show ccm-manager music - Hilft zu bestätigen, dass CUBE weiß, wo Multicast-Musikpakete zu hören sind und ob sie empfangen werden. .

  R1#show ccm-manager music
  Current active multicast sessions : 1
  
   Multicast       RTP port   Packets       Call   Codec    Incoming
  
   Address         number     in/out        id              Interface
  
  ===================================================================
  
  239.176.201.1     16384   956/956          237  g711ulaw  Se0/1/0 

• Show ip igmp members - Wird verwendet, um zu überprüfen, ob CUBE der Multicast-Gruppe erfolgreich beitritt, wenn signalisiert wird, Multicast-Musik abzuspielen.
  
  
• Diese drei Befehle werden verwendet, um den ausgehandelten Codec, die IP-Adresse und die Portnummern der Endpunkte zu überprüfen:

  Show call active voice compact
  Show voip rtp conn
  Show sip calls

  Hier eine Beispielausgabe des ersten Befehls:

  R1#show call active voice compact
  
   <callID>  A/O FAX T<sec> Codec       type        Peer Address       IP R<ip>:<udp>
  
  Total call-legs: 2
  
         236 ANS     T53    g711ulaw    VOIP        P1003    239.176.201.1:16384
  
         237 ORG     T53    g711ulaw    VOIP        P919789362814    200.200.200.2:17808

• Anzeige der Gesprächsverbindung für aktive Sprachverbindungen: Führen Sie diesen Befehl aus, wenn der Anruf gehalten wird, um zu überprüfen, ob die RX/Tx-Zählung erhöht wird.

  0    : 236 29262010ms.1 (*22:34:23.659 UTC Fri May 10 2013)
   +4190 pid:1000 Answer 1003 connected
   dur 00:01:38 tx:919/147040 rx:918/146880 dscp:0 media:0 audio tos:0xB8 video tos:0x0
   IP 239.176.201.1:16384 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
   g711ulaw TextRelay: off Transcoded: No
   media inactive detected:n media contrl rcvd:n/a timestamp:n/a
   long duration call detected:n long duration call duration:n/a timestamp:n/a
  
  0    : 237 29262010ms.2 (*22:34:23.659 UTC Fri May 10 2013)
   +4190 pid:2000 Originate 919789362814 connected
   dur 00:01:38 tx:8910/1425600 rx:919/147040 dscp:0 media:0 audio tos:0xB8 video tos:0x0
   IP 200.200.200.2:17808 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
   g711ulaw TextRelay: off Transcoded: No
   media inactive detected:n media contrl rcvd:n/a timestamp:n/a
   long duration call detected:n long duration call duration:n/a timestamp:n/a

• Perf-Abfrageklasse "Cisco MOH Device"- Dieser CUCM-CLI-Befehl wird verwendet, um schnell zu überprüfen, ob eine Warteschleifenmusik-Ressource zugewiesen ist und welche Art (Unicast oder Multicast). Dieser Befehl ist nicht sehr nützlich, wenn mehrere Anrufe nicht gehalten werden, da sich die Anzahl dynamisch ändert, wenn Anrufe in die Warteschleife gestellt und wieder aufgenommen werden.

  admin:show perf query class "Cisco MOH Device"
  
  ==>query class :
  
   - Perf class (Cisco MOH Device) has instances and values:
  
      MOH_2           -> MOHHighestActiveResources      = 0
  
      MOH_2           -> MOHMulticastResourceActive     = 0
  
      MOH_2           -> MOHMulticastResourceAvailable  = 250000
  
      MOH_2           -> MOHOutOfResources              = 1
  
      MOH_2           -> MOHTotalMulticastResources     = 250000
  
      MOH_2           -> MOHTotalUnicastResources       = 250
  
      MOH_2           -> MOHUnicastResourceActive       = 0
  
      MOH_2           -> MOHUnicastResourceAvailable    = 250

• Debug ccm-manager music-on-hold - Mit diesem Befehl wird verfolgt, wie sich die Anrufabschnitte geändert haben (z. B. wenn Sie die aktuelle Audioverbindung deaktivieren und die Warteschleifenmusik verbinden). Außerdem wird geprüft, ob CUBE der IGMP-Gruppe (Internet Group Management Protocol) gemäß den Anweisungen des CUCM beitritt.
• Debug ip Packet - Dieser Befehl wird als Alternative zu Wireshark für Prüfungen verwendet. Dieser Befehl kann die CPU jedoch schnell überlasten. Verwenden Sie sie nur, wenn es unbedingt erforderlich ist. die Konsolenprotokollierung ausschalten und nicht länger als eine Sekunde ausführen.

Szenario 1

Symptom: Ein Anruf vom öffentlichen Telefonnetz (PSTN) funktioniert einwandfrei mit bidirektionalem Audio. Wenn das IP-Telefon jedoch den Anrufer im PSTN in die Warteschleife setzt und den Anruf dann wieder aufnimmt, werden unidirektionale Audioergebnisse angezeigt: Das IP-Telefon hört die Audioübertragung vom PSTN, aber der PSTN-Benutzer kann das IP-Telefon nicht hören.

Vergewissern Sie sich zuerst, dass der Befehl "SDP Inactive Exchange for Mid-Call Media Change anfordern" auf dem betreffenden SIP-Trunk NICHT deaktiviert ist[5]. Auf diese Weise kann CUCM eine Re-INVITE-Nachricht mit a=inactive in SDP senden, um den bestehenden Medienpfad zu unterbrechen.

Wenn der Anruf gehalten wird, sendet der CUCM kein Re-INVITE mit inaktivem SDP, um den Medienpfad zu unterbrechen, wenn das Kontrollkästchen SDP für Sende-Empfang bei einer INVITE-Anfrage während eines Anrufs für den SIP-Trunk aktiviert ist[8]. Diese Konfiguration ist nur für Geräte aktiviert, die kein vollständiges (Sende-Recv-)Angebot bereitstellen können, nachdem der Medienmodus auf inaktiv gesetzt wurde.

Die folgenden Bilder veranschaulichen die verfügbaren Kontrollkästchen:

Hinweis: Weitere Informationen finden Sie unter Cisco Bug ID CSCtx84013.

Szenario 2

Symptom: Es gibt nur einen Ton, wenn Anrufer statt im Warteschleifenmodus gehalten werden.

Generell deutet dies darauf hin, dass CUCM den Warteschleifenmusik nicht zugewiesen hat.

• Verwenden Sie die show perf query class?Cisco MOH Device? CUCM-CLI-Befehl, um zu überprüfen, ob die Anzahl MOHOutOfResources erhöht wird.
• Stellen Sie sicher, dass Multicast auf der Quelle, dem Server und der Gruppe für Warteschleifenmusik aktiviert ist.

Szenario 3

Symptom: Nur Funklöcher werden hörbar, wenn ein Anrufer gehalten wird.

Stellen Sie sicher, dass  

• Multicast-Routing ist auf dem CUBE und anderen Routern im Audio-Pfad aktiviert.
• IP-Routing und Multicast-Routing sind auf den L3-Switches im Audiopfad aktiviert.
• Die ttl (Hop Count) wird auf dem MoH-Server auf dem CUCM konfiguriert und ist groß genug, um die Hops abzudecken.
• Wenn ein Transcoder erforderlich ist, wird er erfolgreich zugewiesen.
• Die Liste der in der IP Voice Streaming-Anwendung konfigurierten Codecs unterstützt den für Warteschleifenmusik verwendeten Codec.

Szenario 4

Symptom: Ein Anruf schlägt im Flow-around-Modus für Halten und Wiederaufnehmen von Anrufen fehl.

Um eine Umgehung zu unterstützen, müssen Sie eine Re-INVITE- oder eine Aktualisierung von IPGW senden. Dies wird jedoch derzeit nicht unterstützt. Daher wird kein Flow-around für DO-EO-Anrufe unterstützt. Wenn eine solche Call-Flow-Anforderung aus dem Marketing besteht, wird ein Support in Betracht gezogen. Der Cisco Bug, SIP SIP SS DO-EO: Anrufe fehlschlagen im Flow-around-Modus für Halten und Wiederaufnehmen von Anrufen, wird als Erweiterung zur späteren Berücksichtigung markiert.

Zugehörige Informationen

• Multicast-Warteschleifenmusik-Unterstützung für Cisco UBE
• Warteschleifenmusik von CallManager - Häufig gestellte Fragen
• Technischer Support und Dokumentation - Cisco Systems

---

[1] Dies kann verwirrend sein. Wie können Sie in einem Dialog eine andere Konversation führen? In SIP bezieht sich der Dialog auf die 3-Tupe <To-Tag, From-Tag und Call-ID>. Dieser 3-Tupe bleibt während der Haltephase gleich.

[2] DO - Verzögertes Angebot.

[3] Intercluster-Trunk

[4] Ab CUCM 8.5.

[5] Die Transkodierung funktioniert für Warteschleifenmusik in Cisco IOS-Versionen 15.3T und höher. 

[6] DO - Verzögertes Angebot

[7] Cisco Unified Communications Manager - Funktionen und Services-Leitfaden, Version 8.6(1)

[8] Dies sind die Einstellungen des SIP-Profils, die zum Konfigurieren des SIP-Trunks verwendet werden.