Analysieren der Anrufweiterleitungslogik auf dem Meeting-Server

Einleitung

In diesem Dokument wird die Anrufweiterleitungslogik des Cisco Meeting Server (CMS) (ehemals Acano-Produkt) beschrieben, die in mehrere Anrufweiterleitungstabellen aufgeteilt ist. In diesem Dokument werden die verschiedenen Phasen und Szenarien beschrieben, die bei Anrufen über diese Anrufweiterleitungstabellen durchgeführt werden können.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Cisco Meeting Server Call Bridge-Komponente.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf Cisco Meeting Server 2.3.x.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Was ist die Anrufweiterleitungslogik des Cisco Meeting Server (CMS)?

Die Anrufweiterleitung in CMS umfasst einige Tabellen zur Anrufweiterleitung. Mithilfe des Flussdiagramms, das heruntergeladen werden kann, können Sie der Anrufweiterleitungslogik für jeden Anruf folgen, der im CMS eingeht. Dies gilt für alle Anruftypen: Cisco Meeting App (CMA - Thick Client oder WebRTC), Standard Session Initiation Protocol (SIP)-Anrufe oder Microsoft SIP-Anrufe, sofern nicht anders angegeben.

Hinweis: Die einzige Ausnahme gilt für Anrufe, die vom CMS initiiert wurden (entweder CMS direkt für von der TelePresence Management Suite (TMS) geplante ausgehende Anrufe oder CMA-Client-Anrufe), bei denen die Anrufweiterleitungstabelle umgangen wird.

Dies ist die Reihenfolge des Anrufweiterleitungsprozesses in CMS: 

1. Übereinstimmungstabelle für eingehende Anrufe
2. Tabelle für die Weiterleitung eingehender Anrufe
3. Tabelle der ausgehenden Anrufe

Jede Tabelle wird später im Dokument genauer erläutert. Es enthält die Bilder, die nur den relevanten Teil der zeigen.

Hinweis: Das CMS führt die Anrufweiterleitung nur auf Basis der Domänenweiterleitung durch, d. h. auf Basis der rechten Seite (RHS) des URI (Uniform Resource Identifier). Es gibt keine Funktionen zur Anrufweiterleitung auf der linken Seite (LHS) der URI, wie beim Cisco Unified Communications Manager (CUCM) mit DirectoryNumber-Weiterleitung (Routenmuster).

Hinweis: Jede Tabelle ist eine geordnete Liste, die durch das priority-Attribut festgelegt wird. Höhere Priorität bedeutet, dass zuerst eine Übereinstimmung versucht wird. Wenn sie nicht übereinstimmt, wird mit der nächsten Regel in der Liste fortgefahren. Geben Sie als allgemeine Faustregel eine niedrigere Priorität als die spezifischeren Regeln ein (z. B. ein *, das mit einer Domäne übereinstimmt). Auf diese Weise werden die spezifischen Regeln zuerst behandelt, und Sie haben den Fallback möglicherweise zu den allgemeineren Regeln.

Schritt 1: Übereinstimmungstabelle für eingehende Anrufe

Dies ist der erste Schritt des Prozesses, bei dem CMS bestimmt, ob der eingehende Anruf für den Cisco Meeting Server selbst bestimmt ist und auf diesem weiterverarbeitet werden muss, oder ob es sich um einen Anruf für ein anderes System handelt, in dem CMS der Agent ist, der den Anruf weiterleitet und sowohl die Medien als auch die Signalisierung verarbeitet (z. B. Skype-Gateway-Anrufe an Standard-SIP-Endpunkte oder umgekehrt).

Es überprüft, ob der Domänenteil des eingehenden URI mit der eingehenden übereinstimmenden Tabelle übereinstimmt. Wenn sie übereinstimmt, kann sie den Anruf an Space, Benutzer, IVR weiterleiten oder eine Lync-Konferenzsuche (vor Ort oder außerhalb) gemäß Ihrer Konfiguration für diese Wählplanregel durchführen. Die Tabelle lässt keine Platzhalter-Domänen zu, es ist eine vollständige Übereinstimmung erforderlich.

Hinweis: Wenn keine Domänen für die Zuordnung eingehender Anrufe konfiguriert sind, akzeptiert CMS alle eingehenden URIs von SIP- oder Lync-Anrufen, die auf der Callbridge landen. Für CMA-Clients (WebRTC oder Thick Client), die den Anruf zwar annehmen, aber nicht automatisch an den richtigen Ort oder Benutzer weitergeleitet werden. Daher ist es wichtig, in die richtige Domäne einzugeben, wenn Sie den CMA-Client verwenden, um Leerzeichen oder Benutzer in diesem Fall anzuwählen.

Eine Anrufabgleichungstabelle wird z. B. im Bild angezeigt (aus Gründen der Kürze werden nur die Optionen Zielräume und Zielbenutzer angezeigt):

Hier wird die Domain als acano.steven.lab eingerichtet, die die Clients normalerweise wählen. Sie ermöglicht jedoch auch Ad-hoc-Anrufe oder bestimmte SIP-Routenmuster vom CUCM (oder Expressway-Suchregeln), die nur auf eine bestimmte Anrufbrücke abzielen (im Fall eines Clusters), indem die erste und zweite Fallback-Regel in der Tabelle verwendet werden, die entweder der IP-Adresse der Anrufbrücke (in diesem Fall 10.48.54.160) oder dem vollqualifizierten Domänennamen (FQDN) von die Callbridge (in diesem Fall acano1.acano.steven.lab).

Schritt 2: Tabelle für die Weiterleitung eingehender Anrufe

Wenn der Anruf keine der Regeln in der Übereinstimmungstabelle für eingehende Anrufe erreicht hat oder wenn für den Anruf kein übereinstimmender Wert vorhanden ist (z. B. weil der Benutzer einen nicht vorhandenen oder falschen URI gewählt hat), durchläuft er die zweite Tabelle, die als Anrufweiterleitungstabelle bezeichnet wird. Dies ist ebenfalls nur domänenbasiert und ermöglicht Ihnen, Aufrufe bestimmter Domänen gezielt zu blockieren oder Aufrufe bestimmter Domänen spezifisch zuzulassen. Wenn Sie dies tun möchten, ist es wichtig, dass Sie spezifischere Regeln mit einer höheren Priorität haben, damit diese zuerst überprüft werden.

Dieses Beispiel zeigt, dass Anrufe an dummy.com abgelehnt werden, während Anrufe an tplab.local weitergeleitet werden:

Wenn Sie die Anrufweiterleitungstabelle leer lassen, entsteht ein Zustand, in dem das CMS nicht als Gateway zwischen Skype- und SIP-Teilnehmern fungiert, z. B. weil es keine Anrufweiterleitungsregel gibt. Wenn davon ausgegangen wird, dass entweder die Domäne des eingehenden Anrufs in der Tabelle für den eingehenden Anruf nicht übereinstimmt oder die Domäne übereinstimmt, jedoch in den Leerzeichen, Benutzern oder IVRs (oder Skype-Meetings) nicht übereinstimmt, wird der Anruf in Bezug auf die Tabelle für ausgehende Anrufe nicht weitergeleitet.

Hinweis: Dies geschieht jedoch bei CMA-Clients (Thick Clients und WebRTC), da diese ausgehende Anrufe tätigen können (*Web App in 3.0 kann keine ausgehenden Anrufe tätigen, sondern Anrufe von CMS-Space-out von Callbridge). Auch ausgehende Anrufe über CMS sind möglich, wenn sie z. B. über eine API geführt werden (bei TMS-Konferenzen). Im Allgemeinen dürfen Anrufe, die vom CMS selbst initiiert werden (entweder direkt vom CMS oder über CMA) nicht der Anrufweiterleitungslogik folgen.

Im Ereignisprotokoll können Sie die hervorgehobene Weiterleitungsmeldung sehen, z. B. wenn CMS als Gateway für SIP- und Skype-Anrufe fungiert. Kurz davor sehen Sie den eingehenden und den ausgehenden Anruf.

2018-10-04  06:36:24.612  Info     call 788: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:36:24.624  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@any.com'
2018-10-04  06:36:24.625  Info     call 789: outgoing SIP call to "stejanss@any.com"

Wenn die Weiterleitungstabelle über keine Regel oder eine Ablehnungsregel verfügt, wird dies im Ereignisprotokoll nicht explizit angezeigt. Sie werden lediglich darüber informiert, dass der SIP-Anruf nicht übereinstimmt (kein Leerzeichen, Benutzer, IVR oder Lync-Meeting) und dass Sie die Weiterleitungsregel übersehen haben (oder sie auf "Ablehnen" gesetzt ist), um zum Abschnitt "Ausgehende Regeln" zu wechseln.

2018-10-04  06:47:12.482  Info     call 790: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:47:12.495  Info     call 790: ending; local teardown, destination URI not matched - not connected after 0:00

Für CMA-Client-Anrufe oder ausgehende Anrufe von CMS, die durch von TMS geplante Meetings initiiert werden, werden im Ereignisprotokoll keine eingehenden Anrufe angezeigt. Der Anruf wird sofort an die Wählplantabelle für ausgehende Anrufe weitergeleitet und nicht von der Anrufweiterleitungstabelle verarbeitet.

In der Anrufweiterleitungstabelle gibt es zwei weitere Konfigurationsoptionen: Rewrite Domain (Domäne umschreiben) und Caller ID (Anrufer-ID).

Domäne umschreiben

Mit dieser Option können Sie die Domäne des eingehenden Anrufs in eine andere Domäne umschreiben und den Domänenteil der SIP Request-URI sowie den To-Header der SIP-Nachricht ändern.

Mit der Konfiguration in diesem Bild wird hier beispielsweise das Ereignisprotokoll (mit aktivierter SIP-Ablaufverfolgung) für einen eingehenden Anruf mit der Domäne any.com angezeigt, jedoch ohne Übereinstimmung mit der Tabelle für den eingehenden Anruf (entweder bei Leerzeichen, Benutzern, IVR- oder Skype-Konferenzen):

2018-10-04  07:02:24.818  Info     SIP trace: connection 0: incoming SIP TCP data from 10.48.36.215:56457 to 10.48.80.71:5060, size 1000:
2018-10-04  07:02:24.818  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-04  07:02:24.818  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bK53e4c4ce29394
2018-10-04  07:02:24.818  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=742103~ee545a46-516a-4de6-87d7-7b1f5a5b848a-26001856
2018-10-04  07:02:24.818  Info     SIP trace: To: <sip:stejanss@any.com>
..
2018-10-04  07:02:24.822  Info     call 797: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  07:02:24.834  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-04  07:02:24.835  Info     call 798: outgoing SIP call to "stejanss@newany.com"
..
2018-10-04  07:02:24.838  Info     SIP trace: connection 19: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:57854, size 3286:
2018-10-04  07:02:24.838  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-04  07:02:24.838  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bKefc98b81a2961b37aee24f03c2142d8e
2018-10-04  07:02:24.839  Info     SIP trace: Call-ID: 18644f28-e998-4032-a7df-75325e9d11b0
2018-10-04  07:02:24.839  Info     SIP trace: CSeq: 659590315 INVITE
2018-10-04  07:02:24.839  Info     SIP trace: Max-Forwards: 70
2018-10-04  07:02:24.839  Info     SIP trace: Contact: <sip:1060@10.48.80.71;transport=tcp>
2018-10-04  07:02:24.839  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-04  07:02:24.839  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=2aa2a49bba231a1b

In dieser weiterleitenden Anrufleitung werden die vorgenommenen Änderungen angezeigt. Falls Sie die SIP-Ablaufverfolgung nicht aktiviert haben, wird die Änderung von any.com an newany.com weiterhin angezeigt.

Die häufigste Verwendung dieses Umschreibens der Domäne ist eine standortbasierte Lync-Integration mit einem CMS-Cluster, in dem empfohlen wird, den Contact-Header und den From-Header in den ausgehenden Regeln für Lync/Skype auf die CallBridge-spezifischen vollqualifizierten Domänennamen (Fully Qualified Domain Names, FQDNs) festzulegen. Der Grund hierfür sind die folgenden Weiterleitungsregeln:

• Skype sendet neue Transaktionen innerhalb eines Dialoges (wie z. B. eine ACK nach einer INVITE - 200 OK) an den Contact-Header, der im 200 OK angegeben ist. Für eingehende Verbindungen von Skype zu CMS sendet Skype zunächst eine NEGOTIATE SIP-Nachricht mit einem ms-fe-Header im To-Header, der angibt, wie der Contact-Header sein muss ausgefüllt in die 200 OK Antworten auf die INVITE (da es den gleichen TCP Kanal verwendet)
• Skype sendet neue Dialoge (wie die Inhaltsfreigabe, da es sich um einen separaten Anruf handelt, oder einen Rückruf bei einem verpassten Anruf) an den From-Header der ursprünglichen INVITE-Nachricht.

Wenn die Domäne umgeschrieben wird, ist sie für den Rückruf von Lync-Anrufen relevant. Der Von-Header der verpassten INVITE-Nachricht verweist auf die spezifische Callbridge, von der der Anruf stammt. Lync sendet dann eine neue Anforderung (INVITE) mit einem SIP-Anforderungs-URI, der mit dem Callbridge-FQDN übereinstimmt. Diese werden dann mithilfe dieser Umschreibungsregeln in die SIP-Domäne übersetzt. Sobald der Anruf weitergeleitet wird, verwendet er die ausgehenden Regeln zum CUCM oder Expressway-C, auf dem der SIP-Endpunkt registriert ist.

Anrufer-ID

Es gibt hier zwei Optionen, die für die Weiterleitungsregeln festgelegt werden können. Entweder wird der Durchlauf festgelegt, und dann wird keine Änderung am Von-Header der ausgehenden INVITEs vorgenommen, oder es wird der Wählplan verwendet, mit dem das System den From-Header gemäß den ausgehenden Regeln ändern kann. Diese Einstellung ist unabhängig davon, ob die Domäne neu geschrieben wird, da dies nur den SIP-Anforderungs-URI und den To-Header der ausgehenden INVITE-Nachricht betrifft.

Beispielsweise wurde derselbe Anruf wie zuvor getätigt, aber jetzt gibt es eine ausgehende Wählplanregel an newany.com (wie nach dem Umschreiben auf die Tabelle für die Weiterleitung eingehender Anrufe), die als Lync-Anruf eingerichtet wurde (z. B. Ms-Conversation-ID als zusätzlicher SIP-Header). Zweckmäßigerweise werden die lokale Absenderdomäne (und die lokale Kontaktdomäne) ausgefüllt, um auf den Callbridge-FQDN zu verweisen, wie zuvor für Lync-Anrufe angegeben. Dies spiegelt dann die Änderung des Headers "From" und "Contact" des ausgehenden SIP-INVITEs wider. Wie im Bild gezeigt, werden sie mit dem gleichen Wert gefüllt und können individuell nach Ihrer Anforderung ausgewählt werden.

2018-10-12  09:09:24.488  Info     SIP trace: connection 28: incoming SIP TCP data from 10.48.36.215:44460 to 10.48.80.71:5060, size 1000:
2018-10-12  09:09:24.489  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-12  09:09:24.489  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bKf4a230ec178e
2018-10-12  09:09:24.489  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=118288~ee545a46-516a-4de6-87d7-7b1f5a5b848a-32900729
2018-10-12  09:09:24.489  Info     SIP trace: To: <sip:stejanss@any.com>
2018-10-12  09:09:24.489  Info     SIP trace: Call-ID: 81e67f80-bc0164c4-f2c6-d724300a@10.48.36.215

2018-10-12  09:09:24.494  Info     call 803: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-12  09:09:24.506  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-12  09:09:24.507  Info     call 804: outgoing SIP call to "stejanss@newany.com" (Lync)

2018-10-12  09:09:24.507  Info     SIP trace: connection 33: allocated for outgoing connection to 10.48.36.46:5060
2018-10-12  09:09:24.508  Info     SIP trace: connection 33: outgoing connection successful, 10.48.80.71:39782 to 10.48.36.46:5060
2018-10-12  09:09:24.510  Info     SIP trace: connection 33: outgoing SIP TCP data to 10.48.36.46:5060 from 10.48.80.71:39782, size 2971:
2018-10-12  09:09:24.510  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-12  09:09:24.510  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bK15bdde97ab641b586f162187cfdd98b5
2018-10-12  09:09:24.510  Info     SIP trace: Call-ID: c366ddaf-e602-4fa5-b1d6-2e16ec08534a
2018-10-12  09:09:24.510  Info     SIP trace: CSeq: 1498747095 INVITE
2018-10-12  09:09:24.510  Info     SIP trace: Max-Forwards: 70
2018-10-12  09:09:24.510  Info     SIP trace: Contact: <sip:1060@callbridgefqdn.any.com;transport=tcp>
2018-10-12  09:09:24.510  Info     SIP trace: Ms-Conversation-ID: 3P5Hu8grR1GGDF1BSMZAmw==
2018-10-12  09:09:24.510  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-12  09:09:24.510  Info     SIP trace: From: "EX60 Steven" <sip:1060@callbridgefqdn.any.com>;tag=fb4ae780677e9d9b

Wenn die Weiterleitungsregel nur bei Pass Through festgelegt wurde, findet keine Änderung am From-Header statt, wie im vorherigen Beispiel gezeigt (in diesem Fall wurde Pass Through für die Weiterleitungsregel festgelegt). Der Contact-Header wird immer angepasst, wenn CMS einen neuen CallLeg startet und muss sich daher einen Contact-Header hinzufügen.

Es können verschiedene Kombinationen aus Anrufer-ID und lokaler Kontaktdomäne und lokaler Absenderdomäne verwendet werden. Der Von-Header der ausgehenden SIP-INVITE-Nachricht wird wie in der Tabelle gezeigt erstellt, in der der eingehende Anruf über den Von-Header von usera@from.com in das CMS eingeht.

Schritt 3: Tabelle der ausgehenden Anrufe

Dies ist die letzte Tabelle in der Anrufweiterleitungslogik, die den Anruf an einen anderen Server wie folgt weiterleitet:

• Der eingehende Anruf wird nicht lokal verarbeitet (in der Domäne für den eingehenden Anrufabgleich).
• Dabei handelt es sich um einen ausgehenden Anruf von einem CMS-Bereich (über CMA oder über API im Fall von von TMS geplanten Meetings oder von einem CMA-Client, der vom Cisco Meeting Manager (CMM) angewiesen wurde).

Aus dem Bild können Sie sehen, dass die Logik relativ einfach ist. Wenn die Tabelle keinen Eintrag enthält, werden ausgehende Anrufe weiterhin zugelassen. Es wird jedoch davon ausgegangen, dass der CMS-Server in der Lage ist, SIP-SRV-Datensätze (_sips._tcp / _sip._tcp / _sip._udp) für diese Domäne aufzulösen, wie im SIP-Anforderungs-URI erwähnt. Wenn die Tabelle nicht leer ist, es aber keine Übereinstimmung für die gewählte Domäne gibt, wird dieselbe DNS-Suchlogik ausgeführt. Wenn es eine Übereinstimmung in der Domäne gibt, dann folgt sie der Logik dieser bestimmten Regel. Wenn Sie ausgehende Anrufe von CMA oder über TMS oder CMM blockieren möchten, haben Sie hierzu zwei Möglichkeiten. Verfügen Sie über keine DNS SRV-Einträge (oder können von CMS nicht aufgelöst werden), oder leiten Sie diese Anrufe an Ihre Anrufsteuerung (z. B. CUCM oder Expressway) weiter, und blockieren Sie die Anrufe dort.

Die Abbildung zeigt eine Beispieltabelle für ausgehende Anrufe:

Mit einer allgemeinen <match all domains> Regel am Ende und die erste Regel an die Domain von steven.lab ohne SIP Proxy zu verwenden gefüllt in (so stützt es sich auf DNS SRV-Datensätze für sie).

Beachten Sie, dass es sich hierbei um eine geordnete Liste mit einem Wert höherer Priorität handelt, der zuerst abgedeckt wird. Wenn Sie eine Regel mit dem auf Stopp festgelegten Verhalten abgleichen, durchläuft der Anruf nach dieser Übereinstimmung nicht den Rest der Tabelle, und der Anruf ist fehlgeschlagen, wenn der SIP-Proxy den Anruf beispielsweise nicht weiterleiten konnte. Wenn diese Einstellung auf "Continue" (Weiter) gesetzt ist, können Sie einen Fallback auf eine andere Route oder einen anderen Knoten im Cluster zulassen. Sie können beispielsweise für jede Regel in derselben Domäne einen anderen SIP-Proxy angeben. 

Die Einstellungen für die lokale Kontaktdomäne und die lokale Abgangsdomäne werden im vorherigen Abschnitt der Tabelle für die Weiterleitung eingehender Anrufe behandelt. Mit dem Trunk-Typ können Sie angeben, welcher Anruftyp durchgeführt werden soll. Dabei kann es sich je nach Empfangssystem um Standard-SIP, Lync oder Avaya handeln.

Das Feld Encryption (Verschlüsselung) legt fest, ob die Signalisierung des Anrufs unverschlüsselt oder verschlüsselt sein muss. Beachten Sie jedoch, dass dies keine Medienverschlüsselung impliziert, wie in der Konfiguration für die SIP-Medienverschlüsselung unter Konfiguration > Anrufeinstellungen festgelegt. Bei dieser Konfiguration können Sie auch Auto (Automatisch) auswählen. Hierbei wird versucht, den Anruf zuerst mit einer verschlüsselten Signalisierung und dann mit einem möglichen Fallback zu einer unverschlüsselten Signalisierung zu tätigen. Wenn Sie bereits im Voraus wissen, dass die andere Seite verschlüsselt oder unverschlüsselt ist, wird dringend empfohlen, sie entsprechend zu definieren, um Verzögerungen bei der Anrufeinrichtung aufgrund des Fallback-Prozesses zu vermeiden.

Ein Beispiel für die Ausgabe der Protokolldatei für einen Aufruf an steven.lab (nach dem Umschreiben der Domäne in der Tabelle für die Weiterleitung eingehender Anrufe), bei dem DNS-Trace und SIP-Trace auf "Detailed" gesetzt sind, zeigt die SRV-Datensätze, die abgefragt werden, und den Fallback-Mechanismus für den Fall, dass die Verschlüsselung auf "Auto" gesetzt ist.

2018-10-12  11:25:16.168  Info     call 821: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss@any.com"
2018-10-12  11:25:16.179  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@steven.lab'
2018-10-12  11:25:16.180  Info     call 822: outgoing SIP call to "stejanss@steven.lab"

2018-10-12  11:25:16.180  Info     DNS trace: resolving "steven.lab" (SRV "_sips._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 using 10.48.36.215:5061
2018-10-12  11:25:16.181  Info     SIP trace: connection 45: allocated for outgoing encrypted connection to 10.48.36.215:5061
2018-10-12  11:25:16.201  Info     handshake error 336151576 on outgoing connection 45 to 10.48.36.215:5061 from 10.48.80.71:54864
2018-10-12  11:25:16.201  Info     SIP trace: connection 45: shutting down...

2018-10-12  11:25:16.201  Info     call 822: falling back to unencrypted control connection...

2018-10-12  11:25:16.201  Info     DNS trace: resolving "steven.lab" (SRV "_sip._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 using 10.48.36.215:5060
2018-10-12  11:25:16.202  Info     SIP trace: connection 46: allocated for outgoing connection to 10.48.36.215:5060
2018-10-12  11:25:16.203  Info     SIP trace: connection 46: outgoing connection successful, 10.48.80.71:59776 to 10.48.36.215:5060
2018-10-12  11:25:16.205  Info     SIP trace: connection 46: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:59776, size 3290:
2018-10-12  11:25:16.205  Info     SIP trace: INVITE sip:stejanss@steven.lab SIP/2.0

Hinweis: In einer Cluster-Umgebung mit mehreren Callbridges können Sie bei der Konfiguration über eine API Regeln für ausgehende Nummernpläne pro Callbridge festlegen und für das API-Objekt eine Callbridge-ID (oder callbridgeGroup ID) angeben. Angenommen, Sie möchten alle Anrufe von einer bestimmten Callbridge für eine bestimmte Domäne ausgehen lassen (wenn Sie beispielsweise us.example.com wählen, möchten Sie, dass die Anrufe von Ihren Servern in den USA ausgehen). Stellen Sie dann sicher, dass Sie über eine API-Konfiguration für die outboundDialPlanRules verfügen, sodass jede andere Anrufbrücke als die US-basierte den Anruf an die US-Anrufbrücke weiterleiten kann (in diesem Beispiel).

OutboundDialPlanRule (für US-Callbridge)

• domain = us.example.com
• sipProxy = <leer bei Verwendung von DNS SRV / IP oder FQDN bei manueller Einstellung>
• scope = callbridge
• callbridge = <UScallbridge-ID>

OutboundDialPlanRules (für alle Nicht-US-Callbridges, die diesen Anruf zulassen müssen) (pro Callbridge eine erforderlich)

• domain = us.example.com
• sipProxy = <IP-or-FQDN-of-US-Callbridge>
• scope = callbridge
• callbridge = <Nicht-US-callbridge-ID>

Überprüfung 

Für diese Konfiguration ist derzeit kein Überprüfungsverfahren verfügbar.

Fehlerbehebung 

Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.

Zugehörige Informationen

• Technischer Support und Dokumentation für Cisco Systeme
• Analysetool für Collaboration-Lösungen 
• CMS-Dokumentation

---

HINWEIS: Konfigurationsbeispiele finden Sie in folgenden Handbüchern:

• Konfigurieren und Integrieren eines CMS-Kombinationsleitfadens
• Cisco Meeting Server und CUCM-Leitfaden konfigurieren