Analyse der Anrufweiterleitungslogik auf dem Meeting-Server

Einführung

Dieses Dokument beschreibt die Anrufweiterleitungslogik des Cisco Meeting Server (CMS) (ehemals Acano-Produkt), der in mehrere Anrufweiterleitungstabellen aufgeteilt ist. In diesem Dokument werden die verschiedenen Phasen und Szenarien beschrieben, die Anrufe durch diese Anrufweiterleitungstabellen führen 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 (Version 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 potenziellen Auswirkungen eines Befehls verstehen.

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

Die Anrufweiterleitung auf dem CMS umfasst einige verschiedene Tabellen für die Anrufweiterleitung. Mit dem Flussdiagramm, das heruntergeladen werden kann, können Sie die Anrufweiterleitungslogik für jeden Anruf befolgen, der im CMS eingeht. Dies gilt für alle Arten von Anrufen: 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 bilden ausgehende CMS-Anrufe (CMS direkt für die TelePresence Management Suite (TMS) oder CMA-Client-Anrufe), bei denen die Anrufweiterleitungstabelle umgangen wird.

Dies ist die Reihenfolge des Anrufweiterleitungsprozesses in CMS: 

1. Tabelle für die Übereinstimmung eingehender Anrufe
2. Tabelle für die Weiterleitung eingehender Anrufe
3. Tabelle ausgehender Anrufe

Jede Tabelle wird später im Dokument genauer erläutert. Dazu gehören auch Bilder, die nur den entsprechenden Teil des enthalten.

Hinweis: CMS führt nur die Anrufweiterleitung basierend auf der Domänen-Weiterleitung durch, also basierend auf der rechten Seite (RHS) des URI (Uniform Resource Identifier). Auf der linken Seite (LHS) des URI gibt es keine Anrufweiterleitungsfunktion, wie sie es bei Cisco Unified Communications Manager (CUCM) mit DirectoryNumber Routing (Routenmuster) der Fall ist.

Hinweis: Jede Tabelle ist eine geordnete Liste, die durch das priority-Attribut festgelegt wird. Höhere Priorität bedeutet, dass zuerst eine Übereinstimmung erzielt werden muss. Wenn sie nicht übereinstimmt, wird die nächste Regel in der Liste ausgeführt. Als allgemeine Regel des Daumens, geben Sie allgemeinere Regeln (wie ein *, das jeder Domäne entspricht) eine niedrigere Priorität als die spezifischeren Regeln. Auf diese Weise werden die spezifischen Regeln zuerst behandelt, und Sie haben möglicherweise den Fallback zu den allgemeineren Regeln.

1. Tabelle für die Übereinstimmung eingehender Anrufe

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

Es überprüft, ob der Domänenteil des eingehenden URI mit der eingehenden Übereinstimmungstabelle übereinstimmt oder nicht. Bei einer Übereinstimmung kann der Anruf gemäß der Konfiguration für diese Wählplanregel an Leerzeichen, Benutzer, IVR weitergeleitet werden oder eine Lync-Konferenzsuche (am Standort oder extern) durchgeführt werden. Die Tabelle lässt keine Platzhalterdomänen zu, sondern erfordert eine vollständige Übereinstimmung.

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

Beispielsweise wird im Bild eine Tabelle für die Anrufzuordnung angezeigt (es werden nur die Option Targets and Targets Users (ZielLeerzeichen und Zielbenutzer für die Kürzung):

Hier wird die Domäne als acano.steven.lab eingerichtet, die die Clients normalerweise wählen. Sie ermöglicht jedoch auch Ad-hoc-Anrufe oder spezifische SIP-Routenmuster von CUCM (oder Expressway-Suchregeln), die nur auf eine bestimmte Callbridge (bei einem Cluster) abzielen, indem die erste und zweite Fallbackregel in der Tabelle entweder der IP-Adresse der Callbridge (in diesem Fall 10.48.54.160) oder dem Fully Qualified Domain Name (FQDN) entsprechen. Callbridge (in diesem Fall acano1.acano.steven.lab).

2. Tabelle für die Weiterleitung eingehender Anrufe

Wenn der Anruf keine der Regeln in der Tabelle für die Übereinstimmung eingehender Anrufe erreicht hat oder keine Übereinstimmung für den Anruf zum Fortfahren vorhanden ist (z. B. durch den Benutzer eine nicht vorhandene oder falsche URI-Nummer gewählt wurde), durchläuft er die zweite Tabelle, die so genannte Anrufweiterleitungstabelle. Dies ist auch nur auf Domänen basiert und ermöglicht Ihnen, Anrufe gezielt in bestimmte Domänen zu blockieren oder speziell nur Anrufe an bestimmte Domänen zuzulassen. Wenn Sie dies tun möchten, ist es wichtig, dass Sie spezifischere Regeln mit einer höheren Priorität haben, daher werden diese zuerst überprüft.

Im folgenden Beispiel wird gezeigt, dass Anrufe bei dummy.com abgelehnt werden, während Anrufe bei tplab.local weitergeleitet werden:

Wenn Sie die Anrufweiterleitungstabelle leer lassen, führt dies zu einem Zustand, in dem das CMS nicht als Gateway zwischen Skype- und SIP-Teilnehmern fungiert, da es z. B. keine Anrufweiterleitungsregel gibt. Wenn angenommen wird, dass entweder die Domäne des eingehenden Anrufs nicht mit der Tabelle für die Übereinstimmung eingehender Anrufe übereinstimmt oder die Domäne übereinstimmt, es jedoch keine Übereinstimmung in den Räumen, Benutzern oder IVRs (oder Skype-Meetings) gibt, wird der Anruf nicht in Bezug auf die Tabelle ausgehender Anrufe weitergeleitet.

Hinweis: Dies ist jedoch bei CMA-Clients (Thick Clients und WebRTC) der Fall, da diese ausgehende Anrufe tätigen können (*Web-App in 3.0 kann keine ausgehenden Anrufe tätigen, sondern Anrufe, die von Callbridge aus dem CMS-Bereich ausgeführt werden). Ebenso funktionieren ausgehende Anrufe auf dem CMS auch gut, wenn sie z. B. über eine API erfolgen (bei geplanten TMS-Konferenzen). Im Allgemeinen sollten Anrufe, die vom CMS selbst (entweder direkt über CMS oder über CMA) initiiert werden, nicht der Anrufweiterleitungslogik folgen.

Im Ereignisprotokoll wird die hervorgehobene Weiterleitungsmeldung angezeigt, z. B. wenn das 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 keine Regel oder Ablehnungsregel enthält, wird dies im Ereignisprotokoll nicht explizit angezeigt. Sie informiert lediglich, dass der SIP-Anruf nicht übereinstimmt (kein Platz, Benutzer, IVR oder Lync-Meeting), und dass Sie die Weiterleitungsregel (oder die Ablehnungsregel) verpassen, um zum Bereich für 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 Anrufe von CMA-Clients oder ausgehende Anrufe vom CMS, die über geplante TMS-Meetings eingeleitet werden, wird kein eingehender Anruf im Ereignisprotokoll angezeigt. Der Anruf geht sofort an die Wählplantabelle für ausgehende Anrufe und wird nicht von der Anrufweiterleitungstabelle verarbeitet.

In der Anrufweiterleitungstabelle gibt es zwei weitere Konfigurationsoptionen: Domäne und Anrufer-ID neu schreiben.

Domäne umschreiben

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

Mit der Konfiguration in diesem Bild wird beispielsweise das Ereignisprotokoll (mit aktivierter SIP-Ablaufverfolgung) für einen eingehenden Anruf mit domain any.com angezeigt, jedoch ohne Übereinstimmung in der Tabelle für die Übereinstimmung eingehender Anrufe (entweder in 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 Rufumleitung werden die vorgenommenen Änderungen angezeigt. Falls Sie die SIP-Ablaufverfolgung nicht aktiviert haben, wird die Änderung von any.com auf newany.com weiterhin angezeigt.

Die häufigste Verwendung dieser Neufassung der Domäne liegt in einer Integration von On-Prem Lync mit einem CMS-Cluster, bei dem empfohlen wird, den Contact-Header und den From-Header in den Outbound-Regeln auf Lync/Skype auf die Call Bridge-spezifischen Fully Qualified Domain Names (FQDNs) festzulegen. Das liegt an den folgenden Routingregeln:

• Skype sendet neue Transaktionen in einem Dialog (z. B. ein ACK nach einer INVITE - 200 OK) an den Contact-Header, der im 200 OK angegeben ist, den es vom CMS erhalten hat.  Für eingehende Verbindungen von Skype zu CMS sendet Skype zunächst eine NEGOTIATE SIP-Nachricht, die einen ms-fe-Header im To-Header enthält. Dieser gibt an, wie der Contact-Header in den 200 OK-Antworten auf der INVITE-Nachricht ausgefüllt werden muss (da er denselben TCP-Kanal verwendet).
• Skype sendet neue Dialoge (z. B. Content Sharing, da es sich um einen separaten Anruf oder einen Rückruf bei einem verpassten Anruf handelt) an den From-Header der ursprünglichen INVITE-Nachricht.

Beim Umschreiben der Domäne ist dies 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 SIP Request URI, die mit dem Callbridge-FQDN übereinstimmt. Diese Regeln werden dann mithilfe dieser Umschreibregeln in die SIP-Domäne übersetzt. Nach der Weiterleitung des Anrufs werden die Regeln für ausgehende Anrufe zum CUCM oder Expressway-C verwendet, wo der SIP-Endpunkt registriert ist.

Anrufer-ID

Hier gibt es zwei Optionen, die auf den Weiterleitungsregeln festgelegt werden können. Entweder ist sie auf Passthrough festgelegt, und dann wird keine Änderung am Von-Header der ausgehenden INVITEs vorgenommen, oder es wird festgelegt, dass Wählplan verwendet wird, der dem System ermöglicht, den Von-Header gemäß den ausgehenden Regeln zu ändern. Diese Einstellung ist unabhängig davon, ob Sie die Domäne neu schreiben, da dies nur den SIP-Anforderungs-URI sowie den To-Header der ausgehenden INVITE-Nachricht betrifft.

Beispielsweise wurde derselbe Anruf wie zuvor getätigt, aber jetzt gibt es eine Wählplanregel für ausgehende Anrufe auf newany.com (wie nach der Neufassung auf der Weiterleitungstabelle für eingehende Anrufe), die als Lync-Typanruf (z. B. MS-Conversation-ID als zusätzlicher SIP-Header) eingerichtet wurde. Bei Lync-Anrufen werden ggf. die Local From Domain (Lokale Aus-Domäne und Lokale Kontaktdomäne) ausgefüllt, um auf den CallBridge-FQDN zu verweisen. Dies spiegelt die Änderung des Von- und Kontakt-Headers des ausgehenden SIP-INVITE-Nachricht wider. Wie im Bild gezeigt, werden sie mit dem gleichen Wert gefüllt und können individuell nach Ihren Anforderungen 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

Falls die Weiterleitungsregel nur bei der Weiterleitung festgelegt wird, gibt es keine Änderungen am Von-Header, wie sie auch im vorherigen Beispiel dargestellt wurden (in diesem Fall wurde die Weiterleitung auf der Weiterleitungsregel festgelegt). Der Contact-Header wird immer angepasst, wenn CMS einen neuen CallLeg startet und sich somit selbst einen Contact-Header hinzufügen muss.

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

3. Tabelle ausgehender Anrufe

Dies ist die letzte Tabelle in der Anrufweiterleitungslogik, die den Anruf an einen anderen Server ausführt:

• Der eingehende Anruf wird nicht lokal verarbeitet (in der Domäne für die Übereinstimmung eingehender Anrufe).
• Ein ausgehender Anruf aus einem CMS-Bereich (über CMA oder über API bei geplanten TMS-Meetings z. B. oder einem von Cisco Meeting Manager (CMM) angerufenen ausgehenden Anruf) oder von einem CMA-Client

Aus dem Diagramm können Sie sehen, dass die Logik relativ einfach ist. Wenn in der Tabelle überhaupt kein Eintrag vorhanden ist, können weiterhin ausgehende Anrufe getätigt werden. Es wird jedoch davon ausgegangen, dass der CMS-Server in SIP SRV-Datensätzen (_sips._tcp / _sip._tcp / _sip._udp) für diese bestimmte Domäne auflösen kann, wie im SIP Request URI erwähnt. Wenn die Tabelle nicht leer ist, aber keine Übereinstimmung für die gewählte Domäne besteht, wird dieselbe DNS-Suchlogik ausgeführt. Wenn eine Übereinstimmung in der Domäne vorhanden ist, folgt sie der Logik dieser bestimmten Regel. Wenn Sie ausgehende Anrufe von der CMA oder über TMS oder CMM blockieren möchten, haben Sie zwei Möglichkeiten. Sie verfügen entweder nicht über DNS-SRV-Datensätze (oder können nicht über das CMS aufgelöst werden) oder leiten diese Anrufe an die Anrufsteuerung (z. B. CUCM oder Expressway) weiter und sperren die Anrufe dort.

Das Bild zeigt eine Beispieltabelle für ausgehende Anrufe:

mit einer allgemeinen <Match all domains>-Regel am Ende und der ersten Regel zur Domäne von steven.lab ohne SIP-Proxy, der ausgefüllt wird (für die Verwendung sind DNS-SRV-Datensätze erforderlich).

Beachten Sie, dass es sich um eine geordnete Liste mit einem Prioritätswert mit einer höheren Priorität handelt, der zuerst abgedeckt wird. Wenn Sie eine Regel mit dem Behavior abgleichen, das auf Stopp festgelegt ist, 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 (Fortfahren) festgelegt wird, können Sie ein Fallback auf eine andere Route oder einen anderen Knoten im Cluster zulassen. Sie können beispielsweise für jede Regel einen anderen SIP-Proxy für dieselbe Domäne angeben. 

Die Einstellungen für die lokale Kontaktdomäne und die lokale Von-Domäne werden im vorherigen Abschnitt der Tabelle für die Weiterleitung eingehender Anrufe behandelt. Mit dem Trunk-Typ können Sie festlegen, welche Art von Anruf durchgeführt werden muss. Dabei kann es sich um Standard-SIP, Lync oder Avaya handeln, je nach dem empfangenden System.

Das Verschlüsselungsfeld bestimmt, ob die Signalisierung des Anrufs unverschlüsselt oder verschlüsselt sein muss. Beachten Sie jedoch, dass dies keine Medienverschlüsselung impliziert, wie dies in der Konfiguration der SIP-Medienverschlüsselung festgelegt ist, die im Menü Konfiguration > Anrufeinstellungen angezeigt wird. Bei dieser Konfiguration können Sie auch Auto auswählen, das versucht, den Anruf zuerst mit einer verschlüsselten Signalisierung und einem möglichen Fallback auf eine unverschlüsselte Signalisierung zu tätigen. Wenn Sie im Vorfeld 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.

Eine Beispielausgabe der Protokolldatei für einen Anruf bei steven.lab (nach dem Umschreiben der Domäne in die Tabelle für die Weiterleitung eingehender Anrufe) mit detaillierter DNS-Ablaufverfolgung und SIP-Ablaufverfolgung zeigt die abgefragten SRV-Datensätze und den Fallbackmechanismus, falls die Verschlüsselung auf Auto (Automatisch) festgelegt 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: Im Fall einer Cluster-Umgebung mit mehreren Callbrücken können Sie bei der Konfiguration über die API ausgehende Wählplanregeln für jede Callbridge einrichten und im API-Objekt eine Callbridge-ID (oder CallbridgeGroup-ID) angeben. Nehmen Sie beispielsweise an, dass alle Anrufe von einer bestimmten Anrufbrücke für eine bestimmte Domäne ausgeführt werden sollen (z. B. wenn Sie sich bei us.example.com einwählen, möchten Sie, dass diese von Ihren Servern in den USA ausgeht). Stellen Sie dann sicher, dass Sie über eine API-Konfiguration für die ausgehende DialPlanRules verfügen, sodass jede andere als die US-basierte Callbridge den Anruf an die US-Callbridge weiterleiten kann (in diesem Beispiel).

OutboundDialPlanRule (für US-Callbridge)

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

OutboundDialPlanRules (für alle nicht US-Anrufbrücken, die diesen Anruf tätigen müssen) (Benötigen Sie einen pro Anruf-Bridge)

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

Überprüfung 

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

Fehlerbehebung 

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

Zugehörige Informationen 

• Technischer Support und Dokumentation für Cisco Systeme
• Collaboration Solutions Analyzer-Tool 
• CMS-Dokumentation