Zie Call Routing Logic op vergaderserver

Inleiding

Dit document beschrijft de roep Routing Logic van de Cisco Meeting Server (CMS) (voorheen Acano-product) die is opgesplitst in meerdere oproepen routing tabellen. Dit document bestrijkt de verschillende fasen en scenario's die de oproepen door deze oproeproutering tabellen kunnen uitvoeren.

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 levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

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

De vraag die op CMS routeert omvat een paar vraag die verschillende tabellen routeert. Met het stroomschema dat kan worden gedownload, kunt u de vraag routinglogica volgen voor elke vraag die op CMS aankomt. Dit is geldig voor alle soorten oproepen: Cisco Meeting App (CMA - thick client of WebexRTC), Standard Session Initiation Protocol (SIP) roept of Microsoft SIP-oproepen, tenzij anders gespecificeerd.

Opmerking: De enige uitzondering zou zijn voor CMS geïnitieerde oproepen (of CMS direct voor TelePresence Management Suite (TMS) geplande uitgaande gesprekken of CMA client-aanroepen) waarin de aanroep-expedentiatietabel wordt omzeild.

Dit is de volgorde van het oproeprouteproces binnen CMS: 

1. Overeenkomende tabel met inkomende oproepen
2. Tabel voor doorsturen van inkomende oproepen
3. Tabel voor uitgaande gesprekken

Elke tabel wordt later in detail uitgelegd in het document, dat de afbeeldingen bevat die alleen het betreffende gedeelte van het document weergeven.

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 routingfunctionaliteit gebaseerd op de linkerkant (LHS) van de URI zoals u op Cisco Unified Communications Manager (CUCM) met DirectoryNumber Routing (Routepatronen) hebt.

Opmerking: Elke tabel is een geordende lijst die is ingesteld door de eigenschap prioriteit. Hogere prioriteit betekent dat het eerst probeert te worden afgestemd. Als het niet overeenkomt met de volgende regel in de lijst. Als algemene vuistregel: geef meer algemene regels (zoals een * die met elk domein overeenkomt) een lagere prioriteit dan de specifiekere regels. Op die manier worden de specifieke regels eerst afgehandeld, en je hebt mogelijk de gevolgen voor de meer algemene regels.

Stap 1. Overeenkomende tabel met inkomende oproepen

Dit is de eerste stap in het proces waarin CMS bepaalt of de inkomende oproep voor de Cisco Meeting Server zelf is bestemd en deze verder moet verwerken of of of het een oproep is die voor een ander systeem is bestemd, waarin CMS de agent is die de oproep samenwerkt en zowel de media als de signalering verwerkt (bijv. Skype-portwachtgesprekken naar standaardservice SIP-endpoints of omgekeerd).

Het controleert of het domeindeel van de inkomende URI met de inkomende matching tabel overeenkomt of niet. Als het overeenkomt, kan het de aanroep naar de ruimte, gebruiker, IVR leiden of een Lync conference lookup (on-prem of off-prem) doen zoals in uw configuratie voor deze dialplanregel. De tabel laat geen wildkaartdomeinen toe, maar vereist een volledige match.

Opmerking: Als u geen inkomende vraag overeenkomende domeinen hebt ingesteld, accepteert CMS alle inkomende URIs van SIP of Lync die land op de callbridge. Voor CMA clients (WebexRTC of dikke client) accepteert deze de aanroep, maar wordt deze niet automatisch naar de juiste ruimte of gebruiker gestuurd. Daarom is het belangrijk om in het juiste domein in te gaan wanneer u de CMA client gebruikt om naar spaties of gebruikers in dit geval te bellen.

Bijvoorbeeld, wordt een vraag matching tabel getoond in de afbeelding (het toont slechts de Gebieden van doelstellingen en de optie van gebruikers van Targets voor beknoptheid):

Hier wordt het domein ingesteld als acano.steven.lab, dat de klanten normaal gesproken bellen. Er kunnen echter ook ad-hocoproepen of specifieke SIP-routepatronen van CUCM (of expressway zoekregels) worden ontvangen die alleen een specifieke callbridge (in het geval van een cluster) mikken op de eerste en tweede terugvalregel in de tabel die overeenkomen met het IP-adres van de callbridge (10.48.54.160 in dit geval) of de Fully Qualified Domain Name (FDN) van de callbridge (in dit geval acano1.acano.steven.lab).

Stap 2. Tabel voor het doorsturen van inkomende oproepen

Als de oproep geen van de regels op de binnenkomende aanroep-afstemmingstabel heeft geraakt of er geen match was voor de aanroep om verder te gaan (bijv. door een gebruiker gedraaid niet bestaande of foute space URI) gaat de tweede tabel door, die de aanroep-verzendtabel wordt genoemd. Dit is ook slechts op domein gebaseerd en staat u toe om zeer specifiek vraag naar bepaalde domeinen te blokkeren of om specifiek slechts verbindingen naar bepaalde domeinen toe te staan. Als je dat wilt doen, is het belangrijk om specifiekere regels te hebben met een hogere prioriteit, dus ze worden eerst gecontroleerd.

Dit voorbeeld laat zien dat oproepen naar dummy.com worden afgewezen en oproepen naar tplab.local worden verstuurd:

Wanneer u de verbinding van de call door te sturen tabel leeg verlaat, resulteert dit in een status waar CMS niet als gateway tussen Skype en SIP deelnemers werkt, bijvoorbeeld omdat er geen oproep door te sturen regel is. In de veronderstelling dat of het domein van de inkomende oproep geen match is op de inkomende vraag of de domeinovereenkomsten maar er geen match is op de ruimtes, gebruikers of IVR's (of Skype-vergaderingen) wordt de oproep niet verzonden met betrekking tot de uitgaande calltabel.

Opmerking: Dit gebeurt echter met CMA-clients (dikke klanten en WebexRTC) omdat ze uitgaande gesprekken kunnen uitvoeren (*Web App in 3.0 kan geen uitgaande gesprekken maken, maar eerder oproepen die door CMS-ruimte uitgezet zijn door Callbridge). Op dezelfde manier werken uitgaande oproepen op CMS ook prima als ze bijvoorbeeld via API worden gedaan (in het geval van geplande TMS-conferenties). In het algemeen mogen oproepen die van CMS zelf worden geïnitieerd (ofwel CMS direct of via CMA) niet de aanroep-expediteurslogica volgen.

In het eventlogbestand kunt u het gemarkeerde verzendbericht zien als bijvoorbeeld CMS fungeert als gateway voor SIP en Skype-gesprekken. Vlak daarvoor zie je de inkomende oproep en de uitgaande oproep.

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 verzendlijst geen regel of een afwijzende regel heeft, dan toont het eventlogboek dit niet expliciet. Het vertelt u enkel dat de SIP vraag niet kwam (om het even welke ruimte, gebruiker, IVR of Lync vergadering) en dat u de het verzenden regel (of het wordt geplaatst om te verwerpen) mist om naar de uitgeweken regelsectie te bewegen.

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 worden geïnitieerd via geplande TMS-vergaderingen, wordt in het evenement geen inkomende oproep gezien. De vraag gaat onmiddellijk naar de uitgaand kiesschema tabel en wordt niet verwerkt door de aanroep die door tabel wordt verzonden.

In de aanroep die tabel doorstuurt, zijn er twee andere configuratieopties: Domain en Nummerherkenning opnieuw schrijven.

Domain herschrijven

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

Bijvoorbeeld, met de configuratie op deze afbeelding, wordt het eventlogbestand (met SIP-spoor ingeschakeld) hier getoond voor een inkomende oproep met domein any.com maar zonder een match in de inkomende aanroep-matching tabel (of op ruimtes, 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 verzendende telefoonlijn toont het de verandering die is gebeurd. Heeft u geen SIP-sporen ingeschakeld, dan toont dit nog de wijziging van any.com naar newany.com.

Het meest gebruikelijke gebruik van deze herschrijven van het domein wordt geleverd met een Lync-integratie on-prem met een CMS-cluster waarin wordt aanbevolen de Contactheader en From-header in de uitgaande regels in te stellen op Lync/Skype naar de callbridge-specifieke FQDN-namen (FQDN's) met volledig gekwalificeerd domein. Dat komt door deze routingregels:

• Skype stuurt nieuwe transacties binnen een dialoogvenster (zoals een ACK na een INVITE - 200 OK) naar de contactknop die is gespecificeerd in de 200 OK-pagina die van de CMS is ontvangen.  Voor inkomende verbindingen van Skype naar CMS stuurt Skype eerst een ONDERHANDELD SIP-bericht met een MS-fe header in de To header die specificeert hoe de contactkop moet worden ingevuld in de 200 OK-antwoorden op de INVITE (omdat deze hetzelfde TCP-kanaal gebruikt)
• Skype stuurt nieuwe dialogen (zoals het delen van content, omdat het een aparte oproep is, of een callback in het geval van een gemiste oproep) naar de Van kop van de oorspronkelijke INVITE

Aangezien het het domein herschrijft, is het relevant voor de callback van Lync-oproepen. The 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-aanvraagURI dat overeenkomt met de callbridge FQDN. Het wordt vervolgens vertaald naar het SIP-domein via deze herschrijfregels. Zodra de oproep wordt verzonden, gebruikt het de uitgaande regels naar het CUCM of Expressway-C waar het SIP-eindpunt is geregistreerd.

Nummerherkenning

Er zijn hier twee opties die op de verzendingsregels kunnen worden ingesteld. Ofwel wordt deze ingesteld om door te gaan en er wordt geen wijziging aangebracht in de vanaf-kop van de uitgaande INVITE's of er wordt ingesteld op gebruik van een kiesschema waarmee het systeem de vanaf-kop kan wijzigen volgens de regels die aan het einde van de taak worden toegekend. Deze instelling is onafhankelijk van het feit of u een herschrijven van het domein hebt, omdat dit alleen de URI van het SIP-verzoek en de To header van de uitgaande INVITE betreft.

Als voorbeeld werd de zelfde vraag als vroeger gemaakt maar nu is er een uitgaande kiesschema regel naar newany.com (zoals na het herschrijven op de inkomende call expediteur) ingesteld als een Lync type aanroep (Ms-Conversation-ID als extra SIP header). Passend wordt Local From Domain (en Local Contact Domain) ingevuld om naar de callbridge FQDN te wijzen zoals eerder aangegeven voor Lync-oproepen. Dit geeft vervolgens de wijziging op From and Contact header van de uitgaande SIP INVITE weer. Zoals in de afbeelding wordt getoond, worden ze bevolkt met dezelfde waarde en kunnen ze afzonderlijk worden geselecteerd zoals in 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

Indien de expediteurenregel gewoon zou worden ingesteld om door te gaan, dan zou er geen verandering in de Van header zijn zoals te zien ook van het vorige voorbeeld (in welk geval doorgeven is ingesteld op de verzendingsregel). De contactkop is altijd aangepast omdat CMS een nieuw aanroepen been start en dus een contactkop aan zichzelf moet toevoegen.

Er kunnen verschillende combinaties van nummerherkenning en Local Contact Domain en Local From Domain worden gebruikt. De vanaf kop op de uitgaande SIP INVITE is geconstrueerd zoals in de tabel weergegeven, waar de inkomende oproep in het CMS komt met een Van kop van usera@from.com.

Stap 3. Tabel voor uitgaande gesprekken

Dit is de laatste tabel in de oproeproutering-logica die de oproep naar een andere server doet als:

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

Uit het beeld kan je zien dat de logica relatief simpel is. Als er helemaal geen entry in de tabel is, staat het nog steeds toe voor uitgaande gesprekken maar gaat ervan uit dat de CMS server in staat is om op SIP SRV records (_sips._tcp / _sip._tcp / _sip._udp) op dat specifieke domein op te lossen zoals aangegeven op de URI met SIP-aanvraag. Als de tabel niet leeg is maar er geen match is voor het gedialineerde domein, dan wordt de zelfde DNS lookup-logica uitgevoerd. Als er een match is op het domein, dan volgt die op de logica van die specifieke regel. In dat opzicht, als je uitgaande gesprekken van CMA wilt blokkeren of zoals gemaakt via TMS of CMM, kan je dit op twee manieren doen. Of hebben geen DNS SRV records (of niet oplosbaar door CMS) of routeren die oproepen naar uw Call Control (CUCM of Expressway bijvoorbeeld) en blokkeren de oproepen daar.

De afbeelding toont een voorbeeld van uitgaande aanspreektabel:

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

Merk op dat dit een geordende lijst is met een hogere prioriteit die eerst wordt bestreken. Heeft u een regel met het Gedrag op Stop afgestemd, dan gaat de oproep niet door de rest van de tabel na die match en de aanroep is mislukt als die SIP Proxy de aanroep bijvoorbeeld niet heeft geleid. Als die instelling is ingesteld op Doorgaan, kunt u een back-up toestaan naar een andere route of ander knooppunt in het cluster. U kunt bijvoorbeeld een andere SIP-proxy voor elke regel op hetzelfde domein instellen. 

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

Het veld Encryptie bepaalt of de signalering van de oproep niet versleuteld of versleuteld moet worden. Houd er echter rekening mee dat dit geen media-encryptie impliceert, aangezien deze is ingesteld op de configuratie van de SIP-mediaconcentratie zoals in het menu Configuration > Call Settings wordt gevonden. Op deze configuratie hebt u ook de optie om Auto te selecteren die probeert om eerst de oproep te maken met een gecodeerd signaal met een mogelijke back-up naar een niet gecodeerd signaal. Als u vooraan weet dat de andere kant versleuteld of niet versleuteld is, wordt deze sterk aanbevolen om de andere kant dienovereenkomstig te definiëren, om vertragingen bij de callinstelling te voorkomen als gevolg van het back-upproces.

Een voorbeelduitvoer van het logbestand voor een vraag naar steven.lab (na het herschrijven van het domein in de inkomende Call Forwardelijst), met DNS-spoor en SIP-overtrek die ingesteld is om gedetailleerd de SRV-records te tonen die gevraagd zijn en het backmechanisme 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 callbruggen, kunt u uitgaande dialplanregels per callbridge instellen wanneer u deze via API configureren en op het API-object een callbridge-ID (of callbridgeGroup ID) specificeren. Stel bijvoorbeeld dat je wilt dat alle oproepen uitgaan van een bepaalde callbridge voor een bepaald domein (bijvoorbeeld wanneer je naar us.voorbeeld.com draait, zou je willen dat deze oproepen uitgaan van je in de VS gevestigde servers). Zorg er vervolgens voor dat u een API-configuratie hebt voor de uitgaandeDialPlanRules, zodat elke andere callbridge dan de op de VS gebaseerde is in staat is de oproep naar de Amerikaanse callbridge te sturen (in het geval van dit voorbeeld).

OutboundDialPlanRule (voor de V.S.)

• domein = us.voorbeeld.com
• SIPProxy = <leeg wanneer u DNS SRV/IP of FQDN gebruikt, indien handmatig ingesteld>
• scope = callbridge
• callbridge = <UScallbridge-ID>

OutboundDialPlanRules (voor alle niet-Amerikaanse oproepen die moeten toestaan om die oproep te maken) (heb één per callbridge nodig)

• domein = us.voorbeeld.com
• SIPProxy = <IP-of-FQDN-van-US-Callbridge>
• scope = callbridge
• callbridge = <niet-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
• Analyzer voor Collaboration-oplossingen 
• CMS-documentatie

---

OPMERKING: Raadpleeg voor configuratievoorbeelden deze gidsen:

• Enkelvoudige CMS-gids configureren en integreren
• Cisco-vergaderserver en CUCM-gids configureren