Begrijp Call Routing Logic op Meeting Server

Inleiding

Dit document beschrijft de logica van de oproeproutering van de Cisco Meeting Server (CMS) (voorheen Acano-product) die in meerdere tabellen voor oproeproutering is opgesplitst. Dit document behandelt de verschillende stadia en scenario's die de vraag door deze vraag kan nemen die lijsten verpletteren.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Cisco Meeting Server Call Bridge-component.

Gebruikte componenten

De informatie in dit document is gebaseerd op Cisco Meeting Server op versie 2.3.x.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Wat is de Call Routing Logic van Cisco Meeting Server (CMS)?

De call routing op CMS omvat een paar call routing verschillende tabellen. Met de stroomgrafiek die kan worden gedownload, kunt u de vraag volgen die logica voor elke vraag verplettert die op CMS aankomt. Dit is geldig voor alle soorten gesprekken: Cisco Meeting App (CMA - dikke client of WebRTC), Standard Session Initiation Protocol (SIP) of Microsoft SIP-gesprekken, tenzij anders gespecificeerd.

Opmerking: de enige uitzondering zou zijn voor door CMS geïnitieerde oproepen (ofwel CMS direct voor TelePresence Management Suite (TMS) geplande uitgaande oproepen of CMA-clientoproepen) waarin de tabel voor doorsturen van oproepen wordt overgeslagen.

Dit is het proces van de vraagroute binnen CMS: 

1. Inkomende overeenkomende tabel voor gesprekken
2. Inkomende tabel voor doorsturen van oproepen
3. Uitgaande gesprekstabel

Elke tabel wordt later in het document meer in detail uitgelegd, waarbij de afbeeldingen worden opgenomen die alleen het relevante deel van de tabel tonen.

Opmerking: CMS voert alleen oproeproutering uit op basis van domeinrouting, dus gebaseerd op de rechterkant (RHS) van de Uniform Resource Identifier (URI). Er is geen functionaliteit voor oproeproutering op basis van de linkerkant (LHS) van de URI zoals u die hebt op Cisco Unified Communications Manager (CUCM) met DirectoryNumber-routing (routepatronen).

Opmerking: Elke tabel is een geordende lijst die is ingesteld door het prioriteitskenmerk. Hogere prioriteit betekent dat het eerst gematcht probeert te worden. Als deze niet overeenkomt, gaat de tabel verder met de volgende regel in de lijst. Als algemene vuistregel geef je meer algemene regels (zoals een * dat overeenkomt met elk domein) een lagere prioriteit dan de meer specifieke regels. Op die manier worden eerst de specifieke regels behandeld, en heb je de mogelijkheid om terug te vallen op de meer algemene regels.

Stap 1. Inkomende overeenkomende tabel voor gesprekken

Dit is de eerste stap in het proces waarin CMS bepaalt of de inkomende oproep bestemd is voor de Cisco Meeting Server zelf en op deze server verder zou moeten verwerken of dat het een oproep is die bestemd is voor een ander systeem waarin CMS de agent is die de oproep interwerkt en zowel de media als de signalering verwerkt (bijv. Skype-gatewayoproepen naar standaard SIP-endpoints of omgekeerd).

Het controleert of het domeindeel van de inkomende URI overeenkomt met de inkomende matchingtabel of niet. Als het wel overeenkomt, is het in staat om de oproep te leiden naar ruimte, gebruiker, IVR of een Lync conferentie lookup (on-prem of off-prem) te doen volgens uw configuratie voor deze dialplan regel. De tabel staat geen wildcarddomeinen toe, het vereist een volledige match.

Opmerking: als u geen inkomende gespreksovereenkomende domeinen hebt geconfigureerd, accepteert CMS alle inkomende URI’s van SIP of Lync-oproepen die op de callbridge landen. Voor CMA-clients (WebRTC of dikke client) accepteert het de aanroep, maar wordt het niet automatisch naar de juiste ruimte of gebruiker gerouteerd. Daarom is het belangrijk om in het juiste domein in te gaan wanneer u de CMA-client gebruikt om in dit geval naar spaties of gebruikers te bellen.

Bijvoorbeeld, wordt een vraag aanpassende lijst getoond in het beeld (het toont slechts de ruimten van Doelstellingen en de gebruikersoptie van Doelstellingen voor beknoptheid):

Hier is het domein ingesteld als acano.steven.lab die de klanten normaal draaien. Het staat echter ook toe voor ad-hoc-oproepen of specifieke SIP-routepatronen van CUCM (of Expressway-zoekregels) die alleen een specifieke callbridge (in het geval van een cluster) richten door de eerste en tweede fallback-regel in de tabel die overeenkomt met ofwel het IP-adres van de callbridge (10.48.54.160 in dit geval) of de volledig gekwalificeerde domeinnaam (FQDN) van de callbridge (acano1.acano.steven.lab in dit geval).

Stap 2. Inkomende tabel voor doorsturen van oproepen

Als de vraag geen regels op de inkomende vraag passende lijst raakte of er geen gelijke voor de vraag was om te werk te gaan (b.v. gebruiker gedraaid niet bestaande of verkeerde ruimte URI), gaat het door de tweede lijst genoemd de vraag door:sturen lijst. Dit is ook alleen op domeinen gebaseerd en stelt u in staat om specifiek oproepen naar bepaalde domeinen te blokkeren of specifiek alleen oproepen naar bepaalde domeinen toe te staan. Als u dit wilt doen, is het belangrijk om meer specifieke regels met een hogere prioriteit te hebben, zodat ze eerst worden gecontroleerd.

Dit voorbeeld toont aan dat de vraag aan dummy.com wordt verworpen, terwijl de vraag aan tplab.local door:sturen:

Wanneer u de call Forwarding-tabel leeg laat, resulteert dit in een toestand waarin CMS niet fungeert als een gateway tussen Skype- en SIP-deelnemers, bijvoorbeeld omdat er geen call Forwarding regel is. In de veronderstelling dat het domein van de inkomende oproep geen match is op de inkomende vraag matching tabel of de domein overeenkomsten maar er is geen match op de spaties, gebruikers of IVR’s (of Skype-vergaderingen), dan wordt de oproep niet doorgestuurd met betrekking tot de uitgaande vraag tabel.

Opmerking: dit gebeurt wel met CMA-clients (dikke clients en WebRTC), aangezien zij in staat zijn om uitgaande gesprekken te voeren (*Web App in 3.0 kan geen uitgaande gesprekken voeren, maar wel oproepen die door CMS-spatie worden gedaan door Callbridge). Op dezelfde manier werken uitgaande oproepen op CMS ook prima wanneer ze bijvoorbeeld via API worden gedaan (in het geval van TMS geplande conferenties). In het algemeen, vraag die van CMS zelf (of CMS direct of via CMA) in werking wordt gesteld moet niet de vraag volgen die logica door:sturen.

In het gebeurtenissenlogboek, kunt u het benadrukte het door:sturen bericht zien zoals bijvoorbeeld wanneer CMS als gateway voor SIP en de vraag van Skype dienst doet. Vlak daarvoor kun je de inkomende oproep zien en de uitgaande oproep daarna.

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"

Als de het door:sturen lijst geen regel of een verwerpingsregel heeft, dan toont het gebeurtenislogboek dit niet uitdrukkelijk. Het vertelt u alleen dat de SIP-oproep niet overeenkwam (enige ruimte, gebruiker, IVR of Lync-vergadering) en dat u de doorsturen regel mist (of het is ingesteld om af te wijzen) om naar de uitgaande regelsectie te gaan.

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

Voor CMA-clientoproepen of uitgaande oproepen van CMS die via TMS-geplande vergaderingen worden geïnitieerd, wordt er geen inkomende oproep in het gebeurtenissenlogboek weergegeven. De vraag gaat onmiddellijk naar de uitgaande lijst van het wijzerplaatplan en niet door de vraag door:sturen lijst verwerkt.

In de tabel voor doorsturen van oproepen zijn er nog twee andere configuratieopties: Domein herschrijven en Nummerherkenning.

Domein herschrijven

Met deze optie kunt u het domein van de inkomende oproep herschrijven naar een andere en wijzigt u het domeindeel van de SIP-request-URI en de To-header van het SIP-bericht.

Met de configuratie op deze afbeelding wordt bijvoorbeeld het gebeurtenissenlogboek (met SIP-tracering ingeschakeld) hier getoond voor een inkomende oproep met domein any.com maar zonder een match op de inkomende call matching tabel (op spaties, gebruikers, IVR- of Skype-conferenties):

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 deze doorbrengende telefoonlijn, toont het de verandering die is gebeurd. Mocht u geen SIP-tracering ingeschakeld hebben, dan wordt nog steeds de wijziging van any.com naar newany.com weergegeven.

Het meest gebruikte gebruik van deze herschrijving van het domein is een on-prem Lync-integratie met een CMS-cluster waar het wordt aanbevolen om de contactheader en van de header in de uitgaande regels naar Lync/Skype in te stellen op de callbridge-specifieke Fully Qualified Domain Names (FQDN’s). Dat is vanwege deze routeringregels:

• Skype verstuurt nieuwe transacties binnen een dialoog (zoals bijvoorbeeld een ACK na een INVITE - 200 OK) naar de Contact header gespecificeerd in de 200 OK ontvangen van de CMS. Voor inkomende verbindingen van Skype naar CMS verstuurt Skype eerst een ONDERHANDELEN SIP bericht met een ms-fe header in de To header die aangeeft hoe de Contact header ingevuld moet worden in de 200 OK antwoorden op de INVITE (omdat het dezelfde TCP-kanaal gebruikt)
• Skype stuurt nieuwe dialogen (zoals het delen van inhoud, aangezien het een afzonderlijke vraag, of een callback in het geval van een gemiste vraag is) naar de Van kopbal van de originele INVITE

Aangezien het domein herschrijft, is het relevant voor de callback van Lync calls. De From-header van de gemiste INVITE wijst naar de specifieke callbridge waar de oproep vandaan komt. Lync stuurt vervolgens een nieuw verzoek (INVITE) met SIP request URI dat overeenkomt met de callbridge FQDN. Het wordt vervolgens vertaald naar het SIP-domein via deze herschrijfregels. Nadat de oproep is doorgestuurd, worden de uitgaande regels gebruikt voor de CUCM of Expressway-C waar het SIP-eindpunt is geregistreerd.

Nummerherkenning

Er zijn hier twee opties die op de uitzendregels kunnen worden ingesteld. Ofwel wordt het ingesteld om door te gaan en dan wordt er geen wijziging gemaakt op de Van kop van de uitgaande INVITEs of het is ingesteld om kiesschema te gebruiken dat het systeem toestaat om de Van header te wijzigen volgens de uitgaande regels. Deze instelling is onafhankelijk van het feit of u een herschrijven van het domein hebt, aangezien dat alleen betrekking heeft op de SIP-request-URI en de To-header van de uitgaande INVITE.

Als voorbeeld, dezelfde oproep als voorheen werd gedaan, maar nu is er een uitgaande kiesschema regel naar newany.com (zoals na de herschrijven op de inkomende oproep doorsturen tabel) ingesteld als een Lync type call (Ms-Conversation-ID als extra SIP header bijvoorbeeld). In de juiste volgorde worden de Local From Domain (en Local Contact Domain) ingevuld om naar de callbridge FQDN te wijzen zoals eerder aangegeven voor Lync-oproepen. Dit weerspiegelt dan de verandering op Van en de kopbal van het Contact van het uitgaande SIP NODIGT UIT. Zoals in de afbeelding wordt getoond, zijn ze gevuld met dezelfde waarde en kunnen ze individueel worden geselecteerd volgens uw behoefte.

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

In het geval dat de het door:sturen regel enkel bij pas door zou worden geplaatst, dan zou er geen wijziging op de Van kopbal zoals die eveneens van het vorige voorbeeld wordt gezien (waarbij de doorgang door op de het door:sturen regel werd geplaatst) zijn. De Contact header wordt altijd aangepast als CMS een nieuwe callLeg start en moet dus in een Contact header aan zichzelf toevoegen.

Verschillende combinaties van Nummerherkenning en Lokaal Contact Domein en Lokaal Van Domein kunnen worden gebruikt. De From-header op de uitgaande SIP INVITE wordt geconstrueerd zoals in de tabel waar de inkomende oproep de CMS ingaat met een From-header van usera@from.com.

Stap 3. Uitgaande gesprekstabel

Dit is de laatste lijst in de vraag die logica die de vraag aan een verschillende server als volgt maakt:

• De inkomende vraag wordt niet lokaal behandeld (op het inkomende vraag aanpassingsdomein).
• Het is een uitgaand gesprek vanuit een CMS-ruimte (via CMA of via API in het geval van TMS-geplande vergaderingen bijvoorbeeld of Cisco Meeting Manager (CMM) geïnstrueerd uitgaand gesprek) of vanuit een CMA-client.

Uit het beeld kan je zien dat de logica relatief makkelijk is. Als er helemaal geen ingang in de tabel is, staat het nog steeds toe voor uitgaande aanroepen, maar veronderstelt dat de CMS server kan oplossen op SIP SRV records (_sips._tcp /_sip._tcp /_sip._udp) voor dat specifieke domein zoals vermeld op de SIP request URI. Als de tabel niet leeg is, maar er is geen overeenkomst voor het gedraaide domein dan wordt dezelfde DNS lookup logica uitgevoerd. Als er een overeenkomst op het domein is, dan volgt het op de logica van die bepaalde regel. In dat opzicht, als u uitgaande vraag van CMA of zoals gemaakt via TMS of CMM wilt blokkeren, kunt u dit op twee manieren doen. Ofwel hebben geen DNS SRV-records (of niet oplosbaar door CMS) of routeer deze oproepen naar uw gespreksbeheer (CUCM of Expressway bijvoorbeeld) en blokkeer de oproepen daar.

Het beeld toont een voorbeeld uitgaande vraaglijst:

Met een algemene <match alle domeinen> regel aan het eind en de eerste regel op het domein van steven.lab zonder een SIP proxy om te gebruiken ingevulde (dus het vertrouwt op DNS SRV records voor het).

Merk op dat dit een geordende lijst is met een hogere prioriteitswaarde die als eerste wordt bestreken. Indien u een regel aanpast met het Gedrag dat is ingesteld op Stoppen, gaat de oproep niet door de rest van de tabel na die overeenkomst en is de oproep mislukt als die SIP Proxy de oproep niet kan routeren. Wanneer die instelling zou worden ingesteld op Doorgaan, kunt u een terugval naar een andere route of ander knooppunt in het cluster toestaan. U kunt bijvoorbeeld een andere SIP proxy opgeven voor elke regel naar hetzelfde domein. 

De instellingen van Local Contact Domain en Local From Domain worden behandeld in de vorige sectie van de inkomende call Forwarding-tabel. Met het type Trunk kunt u specificeren welk type oproep moet worden gedaan, wat standaard SIP, Lync of Avaya kan zijn, dat afhankelijk is van het ontvangende systeem.

Het veld Encryptie bepaalt of de signalering van de oproep moet worden versleuteld of ontsleuteld. Dit impliceert echter geen media-encryptie, omdat die is ingesteld in de configuratie voor SIP-media-encryptie zoals gevonden in het menu Configuration > Call Settings. In deze configuratie, hebt u ook de optie om Auto te selecteren die probeert om de vraag eerst met een gecodeerde signalering met een mogelijke reserve aan unencrypted signalering te maken. Als u vooraf weet dat de andere kant versleuteld of niet-versleuteld is, wordt het ten zeerste aanbevolen om het dienovereenkomstig te definiëren om vertragingen bij de gespreksinstallatie als gevolg van het terugvalproces te voorkomen.

Een voorbeelduitvoer van het logbestand voor een oproep naar steven.lab (na het herschrijven van het domein op de inkomende call Forwarding tabel), met DNS-spoor en SIP-spoor ingesteld op gedetailleerd laat ons de SRV-records zien die worden gevraagd en het terugvalmechanisme voor het geval dat de Encryptie is ingesteld op Auto.

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

Opmerking: in het geval van een geclusterde omgeving met meerdere callbridges kunt u uitgaande dialplan regels per callbridge instellen wanneer u deze via API configureert en op het API-object een callbridge-id (of callbridgeGroup-id) opgeven. Neem bijvoorbeeld aan dat u alle oproepen uit één bepaalde callbridge voor een bepaald domein wilt laten gaan (bijvoorbeeld als u naar us.example.com belt, zou u willen dat het uitgaat van uw in de VS gebaseerde servers). Zorg er dan voor dat u een API-configuratie hebt voor de uitgaande DialPlanRules, zodat elke andere callbridge dan de in de VS gebaseerde kan de oproep naar de US callbridge (in het geval van dit voorbeeld) leiden.

OutboundDialPlanRule (voor US callbridge)

• domein = us.example.com
• sipProxy = <leeg bij gebruik van DNS SRV / IP of FQDN indien handmatig ingesteld>
• scope = callbridge
• callbridge = <UScallbridge-ID>

OutboundDialPlanRules (voor alle niet-Amerikaanse callbridges die het mogelijk moeten maken om die oproep te doen) (nodig één per callbridge)

• domein = us.example.com
• sipProxy = <IP-of-FQDN-of-US-CallBridge>
• scope = callbridge
• callbridge = <non-US-callbridge-ID>

Verifiëren 

Er is momenteel geen verificatieprocedure beschikbaar voor deze configuratie.

Problemen oplossen 

Er is momenteel geen specifieke informatie over probleemoplossing beschikbaar voor deze configuratie.

Gerelateerde informatie

• Technische ondersteuning en documentatie – Cisco Systems
• Collaboration Solution Analyzer-tool 
• CMS-documentatie

---

OPMERKING: Voor configuratievoorbeelden raadpleegt u deze handleidingen:

• CMS enkele gecombineerde handleiding configureren en integreren
• Cisco Meeting Server en CUCM-handleiding configureren