Contenu

Introduction

Termes associés à la géolocalisation

Géolocalisation

Filtre de géolocalisation

Identificateur de géolocalisation

Enregistrement des politiques de géolocalisation (GLP)

Transport de l'emplacement

Implémentation de la géolocalisation dans la grappe CUCM

Informations générales

Théorie

Conception

Configuration sur CUCM

Configurer la géolocalisation

Activer la géolocalisation

Affecter la géolocalisation aux périphériques

Configurer les stratégies de partition logique

Configurer les relations entre les stratégies de partition logique

Politique logique des TIC

Politique logique indienne

Scénarios

Scénario 1 : Le téléphone IP en Inde appelle le téléphone IP aux États-Unis

Scénario 2 : Le téléphone IP en Inde appelle le téléphone IP aux États-Unis, le téléphone IP en Inde transfère l'appel à l'utilisateur RTPC

Scénario 3 : Le téléphone IP en Inde appelle le téléphone IP aux États-Unis, Inde Conférences téléphoniques IP Utilisateur RTPC

Scénario 4 : Le téléphone IP en Inde appelle le téléphone IP aux États-Unis, US Ext le transfère à l'utilisateur RTPC

Scénario 5 : le téléphone IP en Inde appelle le téléphone IP aux États-Unis, utilisateur RTPC des conférences externes américaines

Configuration du cluster US

Configurer la géolocalisation

Activer la géolocalisation

Affecter la géolocalisation aux périphériques

Configurer les stratégies de partition logique

Politique logique américaine

Évoluer à l'avenir

Ajout d'un nouveau cluster au réseau d'entreprise

Que faire si vous avez une PME?

Limite

Informations connexes

Introduction

Ce document traite de la manière d'étendre la géolocalisation à un déploiement multicluster avec la solution de communication de localisation. Avec ces nouvelles informations sur la façon d'obtenir que le groupe d'utilisateurs fermés (CUG) fonctionne entre un cluster qui est réglementé et non réglementé avec une configuration minimale. Elle veille également à respecter les règles réglementaires.

Termes associés à la géolocalisation

Géolocalisation

Par définition, le GeoLocation est une description de la zone géographique physique où il existe actuellement quelque chose. Dans CUCM, la géolocalisation attribue les détails de l'emplacement aux périphériques tels que les téléphones IP, les liaisons SIP, les passerelles de liaison inter-clients (ICT), etc., qui peuvent avoir un sens dans une entreprise, dans les clusters et les sites.

La RFC 4119 spécifie 17 éléments de localisation civique et la fonctionnalité de partitionnement logique UCM implémentée la configuration manuelle de ces 17 champs/éléments à partir des configurations d'administration. Il est recommandé de remplir les 17 champs. Les champs doivent être nommés logiques et courts.

Filtre de géolocalisation

Le filtre de géolocalisation est une règle permettant de sélectionner certains champs de géolocalisation afin de construire une chaîne de géolocalisation, qui peut être utilisée pour correspondre aux stratégies de la fonction de partitionnement logique. i.e.  il donne des jeux de champs de géolocalisation pour lesquels les stratégies doivent être configurées

Identificateur de géolocalisation

Identificateur constitué d'une combinaison de géolocalisation, de filtre et de type de périphérique. Cet identificateur est utilisé pour la comparaison avec LP et l'appel est autorisé ou refusé

Un filtre de géolocalisation de périphérique + type de périphérique = identificateur de géolocalisation

Par exemple, une liaison SIP dans CUCM peut être représentée logiquement comme

Bordure:Pays:IN:A1:KAR:A2:BAN

Enregistrement des politiques de géolocalisation (GLP)

Les stratégies ne sont pas configurées directement entre les géolocalisations, car les géolocalisations ont normalement les 17 champs configurés et seraient peut-être uniques pour chaque périphérique UCM d'un cluster. Ainsi, la configuration des politiques entre les géolocalisations peut représenter une surcharge importante pour un administrateur, compte tenu du nombre de géolocalisations.

Pour établir des politiques, Admin doit construire des enregistrements ayant besoin de données pour les champs de géolocalisation. À cette fin, la configuration fournit la possibilité de sélectionner des données dans les listes déroulantes affichant les champs de géolocalisation.

Ces enregistrements sont appelés enregistrements GLP (GeolocationPolicy).

Note: Les enregistrements GeolocationPolicy doivent être effectués de manière à ce que les données correspondantes correspondent aux champs sélectionnés dans les filtres. La hiérarchie des champs est importante et les champs ne doivent pas être manqués au début ou au milieu, mais peuvent être manqués à la fin.

Si les champs spécifiques au filtre ne sont pas dans la stratégie, l'algorithme de recherche supprime le champ de la fin et recherche une correspondance possible dans les stratégies.

Exemple : Si j'ai sélectionné un champ C, A1, A2, A6 pour un LP et un autre LP n'a que C, A1, A6 alors le CUCM entre ce LP 2 prend seulement C, A1 même si A6 est présent dans les deux CUCM ne l'ignore pas.

Transport de l'emplacement

- Le transfert de GeoLocation d'un agent utilisateur SIP à une autre entité à l'aide de SIP est appelé Location Conveyance.

- Afin de prendre en charge les exigences LP, la mise en oeuvre de l'UCM communique en outre les informations sur le type de périphérique dans PIDF-LO. Ceci est basé sur l'état de présence des capacités de l'agent utilisateur, conformément aux spécifications de l'extension SIP draft-ietf-simple-prescaps-ext-08.

- La liaison SIP de l'UCM prend en charge le transport d'emplacement conformément à ces spécifications.

- Afin de permettre aux TIC d'être compatibles avec la ligne principale SIP et d'offrir les mêmes fonctionnalités, la ligne principale ICT/H225 prend également en charge le transfert de localisation dans le cluster à l'aide de PIDF-LO.

- L'UCM prend en charge la transmission des informations de localisation à l'établissement de l'appel ainsi que les modifications de localisation en raison de la modification de la partie connectée dans la participation aux jointures et redirections de mi-appel.

Implémentation de la géolocalisation dans la grappe CUCM

Hypothèse : Avoir une compréhension de base de la géolocalisation et pourquoi elle est nécessaire.

Pour ce document, nous avons utilisé 2 clusters CUCM. Un cluster est censé résider aux États-Unis et un autre cluster résidant en Inde. Nous utilisons CUCM versions 11.5 et 10.5 à des fins de démonstration. Nous avons une liaison SIP entre les clusters. Le plan de numérotation est configuré de telle sorte que seuls les appels internes sont autorisés sur cette liaison ICT/SIP à partir des deux clusters à l'aide de CSS et de la partition. Le plan de numérotation a été configuré de sorte que les appels VOIP vers RTPC utilisent la passerelle locale pour passer des appels RTPC à l'aide de CSS et de la partition.

India Cluster est un cluster compatible/compatible avec les partitions logiques. Le cluster États-Unis est une partition logique désactivée/ignorée. Le filtre de géolocalisation et de géolocalisation est configuré et appliqué à tous les périphériques des deux clusters. Pour l'instant, configurez la partition logique dans le cluster Inde uniquement, après une limitation, en raison de laquelle la géolocalisation est activée et configure la partition logique même sur le cluster États-Unis également.

Extension VoIP Inde : 7XXX (7001, 7002)

Extension VOIP USA : 5XXX (5005)

Poste RTPC : 1 XXX (1005)

Voici l'image avec les identificateurs de géolocalisation.

Informations générales

Du côté de l'Inde, la réglementation relative aux TCI s'applique. En termes simples, ne combinez pas les appels VOIP non locaux aux appels RTPC locaux. Les appels de groupe d'utilisateurs fermés (CUG) sont autorisés, c'est-à-dire les appels VOIP au sein du même réseau d'entreprise.

Lorsque vous avez plusieurs clusters CUCM dans un emplacement géographique différent et que l'un d'eux est réglementé, l'objectif serait

1. Respecter les règles d'échange d'informations ou de réglementation

2. Faire fonctionner CUG

Théorie

Pour que CUG fonctionne, le moyen de transport de localisation est utilisé pour étendre l'application de la politique de partitionnement logique, c'est-à-dire que les informations de géolocalisation sont envoyées à d'autres clusters lorsque les données de géolocalisation sont vérifiées sur les liaisons ICT et SIP sur les deux clusters. Cela permet d'envoyer et de recevoir des informations de géolocalisation des périphériques et, de plus, vous pouvez savoir si le périphérique est un périphérique intérieur ou une frontière.

Pour la configuration initiale de l'appel, vous avez besoin d'une politique permettant la communication entre le téléphone IP A et les TIC. Une fois l'invitation SIP envoyée à d'autres clusters, il détecte le périphérique de destination B et une fois que ce périphérique sonne ou/et répond à l'appel, les informations de géolocalisation du périphérique B sont envoyées au cluster d'origine par le biais d'un message SIP INVITE/UPDATE. Une fois que le cluster d'origine reçoit des informations de géolocalisation valides dans le message INVITE/UPDATE qui remplace la configuration de géolocalisation de la liaison SIP locale et remplace cette information par la géolocalisation reçue.

Avec ces nouvelles informations de géolocalisation, vous pouvez avoir une politique de partition logique configurée pour autoriser les appels VOIP vers VOIP et refuser les appels VOIP du cluster qui atteint le périphérique Border d'un autre cluster.

Note: Dans ce scénario, tous les clusters doivent avoir des filtres de géolocalisation et de géolocalisation configurés et appliqués à tous les pools de périphériques. Les appels interclusters incluent des données de géolocalisation et indiquent si ce participant est considéré comme étant à l'intérieur ou à la frontière. Si les données de géolocalisation ne sont pas reçues lors d'un appel inter-cluster, le filtre de géolocalisation et de géolocalisation de la configuration de liaison ou hérité du pool de périphériques de la liaison est utilisé à la place.

Conception

Afin de concevoir la géolocalisation et la partition logique, pensez à

- Comment identifier de manière unique l'emplacement physique du périphérique qui passe l'appel et le périphérique qui reçoit l'appel ?

- Collecte d'informations sur la géolocalisation/l'emplacement physique entre lesquels les restrictions d'appel doivent être en place.

- Sur les 17 champs sélectionnés, vous pouvez décider d'autoriser ou de refuser l'appel.

Dans les champs de géolocalisation, vous avez 17 champs, qui vont de A1 à A6 jusqu'au code postal. Pour remplir à partir de A1, c'est comme zoomer sur une carte. Plus vous mettez de détails, plus précisément l'emplacement du périphérique peut être identifié, auquel cette géolocalisation est attribuée. La chose à considérer est, de tous les champs de géolocalisation, quels champs doivent être une paire de périphériques présents à CUCM avec lequel vous pouvez prendre une décision de partition logique efficace.

Lorsque la stratégie de partitions logiques est configurée, vous avez la possibilité de sélectionner un ensemble de champs de géolocalisation, sélectionnez ces champs de géolocalisation de sorte que lorsqu'un périphérique passe un appel présente un ensemble d'identificateurs de géolocalisation à CUCM et que le périphérique de destination reçoit un appel qui présente un ensemble d'identificateurs de géolocalisation à CUCM. Si ces champs correspondent à une stratégie de partition logique prédéfinie, il est alors en mesure d'appliquer des restrictions aux appels.

Exemple . Si le périphérique A a des informations de géolocalisation A1=IN, A2=BAN, NAM=BGL14 et le périphérique B a une géolocalisation A1=IN, A2=MUM, NAM=BAN1. Créez une stratégie de géolocalisation 1 telle que A=IN, A2=BAN, NAM=BGL14. Créer la stratégie 2 A=IN, A2=MUM, NAM=BAN1. Vous devez autoriser ou refuser entre les périphériques qui correspondent aux stratégies 1 et 2.

Si un appel est effectué et que le périphérique d'origine possède les informations de géolocalisation A1=IN, A2=BAN, NAM=BGL14, CUCM sait que la stratégie 1 peut être sélectionnée. Si le périphérique de destination possède également les informations de géolocalisation A1=IN, A2=MUM, NAM=BAN1, CUCM sait qu'il s'agit d'une correspondance parfaite pour la relation de partition logique entre les stratégies 1 et 2.

Note: Il est recommandé que les champs de filtre de géolocalisation et de stratégie de partition logique sélectionnés aient les mêmes champs sélectionnés et appariés ou que le champ de stratégie de partition logique soit un sous-ensemble de champs de filtre de géolocalisation de sorte que, lorsqu'un appel est passé, la stratégie de partition logique soit appariée dans la première itération. Vous devriez essayer de trouver une correspondance parfaite lors des appels.

Configuration sur CUCM

Inde La configuration des clusters peut être divisée en deux parties :

Configurer la géolocalisation

Dans ce cas, trois géolocalisations sont créées.

- Pour les périphériques en Inde : Inde_GL

- Pour la liaison SIP dans ICT : Inde_ICT_GL

- Pour les périphériques aux États-Unis : GL_US

Note: Dans le cluster Inde, un Empty_GL est configuré et il est indiqué comme géolocalisation par défaut. Cette opération est effectuée de sorte que, si vous oubliez d'ajouter la géolocalisation à n'importe quel périphérique via le pool de périphériques, cette géolocalisation est utilisée pour refuser les appels à n'importe quel périphérique périphérique périphérique frontalier.

Cette image montre India_GL Configuration.

Cette image montre la configuration India_ICT_GL.

Cette image montre la configuration US_GL.

Comme l'illustre l'image, pour le filtre de géolocalisation, les champs Country, A1, A2 et NAM sont utilisés.

Activer la géolocalisation

Activez le partitionnement logique dans le paramètre d'entreprise, définissez une stratégie par défaut sur Refuser, appliquez la géolocalisation par défaut en tant que Empty_GL.

Affecter la géolocalisation aux périphériques

- Dans le pool de périphériques CUCM pour le téléphone IP, affectez India_GL.

- Sur la ligne principale SIP ICT, affectez India_ICT_GL et vérifiez pour envoyer des informations de géolocalisation.

Une fois cette opération effectuée, passez au cluster UC. Vous devez créer une politique de géolocalisation américaine et l'associer aux périphériques du cluster américain.  Assurez-vous que la case Envoyer les informations de géolocalisation est cochée sur la ligne SIP ou les TIC entre les clusters États-Unis et Inde.

Une fois la configuration du cluster américain terminée, revenez au cluster Inde.

Configurer les stratégies de partition logique

Trois stratégies logiques sont créées.

- Politique des TIC : Pays=IN, A1=KAR, A2=BAN, NAM=TIC

- Politique indienne : Pays=IN, A1=KAR, A2=BAN, NAM=BGL14

- Politique américaine : Pays = US, A1=TEX, A2=SAN, NAM=BGL1

Configurer les relations entre les stratégies de partition logique

Une fois la partition logique configurée, renseignez les relations entre les deux stratégies.

Politique logique des TIC

Type de périphérique, stratégie et sa relation avec d'autres tables de stratégies.

Type de périphérique

Politique

Type de périphérique

Politique

Résultat

Frontière

Country=IN, A1=KAR, A2=BAN, NAM=ICT(ICT Policy)

Frontière

Country=IN, A1=KAR, A2=BAN, NAM=ICT(ICT Policy)

Allow

Frontière

Country=IN, A1=KAR, A2=BAN, NAM=ICT(ICT Policy)

Intérieur

Country=IN, A1=KAR, A2=BAN, NAM=BGL14(Politique indienne)

Allow

- Un téléphone IP interne est nécessaire pour accéder aux TIC avant d'obtenir la mise à jour du périphérique du côté des États-Unis. Vous avez donc Border : Country=IN, A1=KAR, A2=BAN, NAM=ICT (ICT SIP trunk) à Interior : Country=IN, A1=KAR, A2=BAN, NAM=BGL14 (IP Phones in India) comme Allow.

- Au cas où vous auriez besoin de renvoyer l'appel aux États-Unis Alors vous avez besoin d'appels ICT to ICT comme autorisé pour avoir la relation Border : Country=IN, A1=KAR, A2=BAN, NAM=ICT to Border : Country=IN, A1=KAR, A2=BAN, NAM=ICT as Allow.

Politique logique indienne

Type de périphérique, stratégie et sa relation avec d'autres tables de stratégies.

Type de périphérique

Politique

Type de périphérique

Politique

Résultat

Intérieur

Country=IN, A1=KAR, A2=BAN, NAM=BGL14(Politique indienne)

Frontière

Country=IN, A1=KAR, A2=BAN, NAM=BGL14(Politique indienne)

Allow

Avec cette configuration, vous avez une partition logique configurée sur le cluster Inde uniquement et vous avez un moyen de transport entre les clusters États-Unis et Inde. Vous devriez être en mesure de bloquer les appels entre le cluster des États-Unis et de l'Inde de se mélanger au RTPC et de faire fonctionner CUG. Testez cette configuration en effectuant quelques appels.

Scénarios

- Le téléphone IP en Inde appelle le téléphone IP aux États-Unis.

- IP Phone in India appelle le téléphone IP aux États-Unis, India IP phone Transfère l'appel à l'utilisateur RTPC.

- Le téléphone IP en Inde appelle le téléphone IP aux États-Unis, le téléphone IP Inde Conférences utilisateur RTPC.

- Le téléphone IP en Inde appelle le téléphone IP aux États-Unis, US Ext le transfère à l'utilisateur RTPC.

- Le téléphone IP en Inde appelle le téléphone IP aux États-Unis, utilisateur PSTN des conférences extérieures aux États-Unis.

Scénario 1 : Le téléphone IP en Inde appelle le téléphone IP aux États-Unis

Comportement attendu : Autoriser l'appel

Comportement observé : Appel autorisé

Le poste 7001 du téléphone IP indien nous appelle poste 5005.

Voici le schéma de l'échelle de liaison SIP

Vous pouvez diviser l'appel en deux parties.

- Avant d'obtenir les informations de géolocalisation du cluster américain.

- Après avoir obtenu les informations de géolocalisation du cluster américain.

Si vous remarquez qu'il y a 200 OK et ACK pour l'invitation SIP initiale. Si vous regardez de plus près le 200 OK que vous avez obtenu du cluster américain, il est remarqué que le port RTP est un port factice, c'est-à-dire 4000

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.106.97.137:5060;branch=z9hG4bK68935124bc7a

From: <sip:7001@10.106.97.137>;tag=26724~771bfd92-7ded-4e46-8bd8-6830680e49b2-18365227

To: <sip:5005@10.106.97.135>;tag=16120~7e829a6c-a04d-4a5f-8048-8b0b0ec17d7b-18364848

Date: Sat, 16 Mar 2019 19:52:55 GMT

Call-ID: 15e0cb00-c8d15417-6828-89616a0a@10.106.97.137

CSeq: 101 INVITE

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Allow-Events: presence, kpml

Supported: replaces

Server: Cisco-CUCM10.5

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires:  1800;refresher=uas

Require:  timer

P-Asserted-Identity: <sip:5005@10.106.97.135>

Remote-Party-ID: <sip:5005@10.106.97.135>;party=called;screen=yes;privacy=off

Remote-Party-ID: <sip:5005@10.106.97.135;user=phone>;party=x-cisco-original-called;privacy=off

Contact: <sip:5005@10.106.97.135:5060>

Content-Type: application/sdp

Content-Length: 340

v=0

o=CiscoSystemsCCM-SIP 16120 1 IN IP4 10.106.97.135

s=SIP Call

c=IN IP4 10.65.43.112

b=TIAS:64000

b=AS:64

t=0 0

m=audio 4000 RTP/AVP 9 0 8 116 3 18

a=rtpmap:9 G722/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:116 iLBC/8000

a=maxptime:60

a=fmtp:116 mode=20

a=rtpmap:3 GSM/8000

a=rtpmap:18 G729/8000

a=sendonly

RTP n'a pas encore commencé à circuler. Après l'ACK, vous voyez une INVITE SIP de plus et dans ce, vous avez des informations de géolocalisation envoyées à vous-même.

INVITE sip:7001@10.106.97.137:5060 SIP/2.0

Via: SIP/2.0/UDP 10.106.97.135:5060;branch=z9hG4bK11f6de9436

From: <sip:5005@10.106.97.135>;tag=16120~7e829a6c-a04d-4a5f-8048-8b0b0ec17d7b-18364848

To: <sip:7001@10.106.97.137>;tag=26724~771bfd92-7ded-4e46-8bd8-6830680e49b2-18365227

Date: Sat, 16 Mar 2019 19:53:00 GMT

Call-ID: 15e0cb00-c8d15417-6828-89616a0a@10.106.97.137

Supported: timer,resource-priority,replaces

Cisco-Guid: 0367053568-0000065536-0000000033-2304862730

User-Agent: Cisco-CUCM10.5

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

CSeq: 101 INVITE

Max-Forwards: 70

Expires: 180

Allow-Events: presence, kpml

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires:  1800;refresher=uac

Min-SE:  1800

Geolocation:

;inserted-by="10.106.97.135"

P-Asserted-Identity: <sip:5005@10.106.97.135>

Remote-Party-ID: <sip:5005@10.106.97.135>;party=calling;screen=yes;privacy=off

Contact: <sip:5005@10.106.97.135:5060>

Content-Type: multipart/mixed;boundary=uniqueBoundary

Mime-Version: 1.0

Content-Length: 1219

--uniqueBoundary

Content-Type: application/sdp

v=0

o=CiscoSystemsCCM-SIP 16120 2 IN IP4 10.106.97.135

s=SIP Call

c=IN IP4 10.65.43.112

b=TIAS:64000

b=AS:64

t=0 0

m=audio 25344 RTP/AVP 9

a=ptime:30

a=rtpmap:9 G722/8000

--uniqueBoundary

Content-Type: application/pidf+xml

Content-ID: <5005@10.106.97.135>

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"

xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"

xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"

xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"

xmlns:cisco="http://www.cisco.com"

entity="pres:geotarget@example.com">

<dm:device id="sg89ae">

<caps:devcaps>

false

</caps:devcaps>

<gp:geopriv>

<gp:location-info>

<cl:civicAddress>

US

TEX

SAN

BGL1

</cl:civicAddress>

</gp:location-info>

<gp:usage-rules>

<gp:retransmission-allowed>yes</gp:retransmission-allowed>

<gp:retention-expiry>2019-03-17T19:53:00Z</gp:retention-expiry>

</gp:usage-rules>

</gp:geopriv>

<timestamp>2019-03-16T19:53:00Z</timestamp>

</dm:device>

</presence>

--uniqueBoundary--

Dans cette invitation, vous voyez le numéro de port RTP que le téléphone IP américain utilisera. Les informations de géolocalisation du téléphone IP et les informations sur le fait qu'il s'agit d'une passerelle ou non sont envoyées à la grappe indienne. Avec ces nouvelles informations de géolocalisation, une fois de plus les partitions logiques sont appariées dans le cluster indien pour voir si l'appel doit être autorisé ou refusé. Comme il s'agit d'appels intérieurs, la partition logique n'est pas appliquée et l'appel est autorisé

Scénario 2 : Le téléphone IP en Inde appelle le téléphone IP aux États-Unis, le téléphone IP en Inde transfère l'appel à l'utilisateur RTPC

Comportement attendu : Refuser l'appel

Comportement observé : Appel refusé

Le téléphone IP indien Ext 7001 nous appelle Ext 5005, touche la touche de fonction de transfert la première fois, compose le numéro RTPC 1005, appuie sur la touche de transfert mais rien ne se passe.

Dans les traces de CUCM, vous voyez.

01192372.012 |01:51:49.984 |AppInfo  |LPPolicyManager -getLogicalPartitionPolicy, devtypeA[Border], devtypeB[Interior]

01192372.013 |01:51:49.984 |AppInfo  |LogicalPolicyTree -searchPolicy devTypeA[Border], devTypeB[Interior]

01192372.014 |01:51:49.984 |AppInfo  |GeolocNamValPair -printList: country = IN, A1 = KAR, A2 = BAN, NAM = BGL14,

01192372.015 |01:51:49.984 |AppInfo  |GeolocNamValPair -printList: country = US, A1 = TEX, A2 = SAN, NAM = BGL1,

01192372.074 |01:51:49.984 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, DEFAULT POLICY found is [2]

01192372.075 |01:51:49.984 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, POLICY found is [9]

01192372.076 |01:51:49.984 |AppInfo  |Transferring - LPPolicy Result [9]

01192372.077 |01:51:49.984 |AppInfo  |LPPolicyManager -incLogicalPPerfmon, perfMon[0]

01192372.078 |01:51:49.984 |AppInfo  |Transferring - handleTransferErrorPreStart, ERROR fid=[4], Retaining Calls, xferring[1, 18365238], xferred[1, 18365239]. infoCause=53, clearCause=63

01192668.001 |01:51:56.765 |AppInfo  |StationD:    (0000019) DisplayNotify timeOutValue=10 notify='a' content='External Transfer Restricted' ver=8560000c.

Sur le groupe Inde, A va vers un périphérique RTPC, c'est-à-dire un élément de frontière. Vous n'avez défini aucune autorisation entre la frontière indienne et l'intérieur des États-Unis. Par conséquent, vous utilisez la stratégie par défaut définie pour refuser et bloquer l'appel.

Scénario 3 : Le téléphone IP en Inde appelle le téléphone IP aux États-Unis, Inde Conférences téléphoniques IP Utilisateur RTPC

Comportement attendu : Refuser l'appel

Comportement observé : Appel refusé

Le téléphone IP indien Ext 7001 nous appelle Ext 5005, le téléphone IP indien Ext 7001 clique pour la première fois sur la touche de fonction Confrn, compose le numéro RTPC 1005, clique sur la touche de fonction Confrn, comme l'illustre l'image. Cependant, vous voyez que la conférence n'est pas disponible.

Dans les journaux CUCM, vous voyez ceci :

01213687.146 |02:00:35.806 |AppInfo  |LogicalPolicyTree -searchPolicy devTypeA[Border], devTypeB[Interior]

01213687.147 |02:00:35.806 |AppInfo  |GeolocNamValPair -printList: country = IN, A1 = KAR, A2 = BAN, NAM = BGL14,

01213687.148 |02:00:35.806 |AppInfo  |GeolocNamValPair -printList: country = US, A1 = TEX, A2 = SAN, NAM = BGL1,

01213687.207 |02:00:35.806 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, DEFAULT POLICY found is [2]

01213687.208 |02:00:35.806 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, POLICY found is [9]

01213687.209 |02:00:35.806 |AppInfo  |Conference: processGeoLocationResultListForConfRequest:ci=18365306,status=9

Sur le groupe Inde, A va vers un périphérique RTPC, c'est-à-dire un élément de frontière. Vous n'avez défini aucune autorisation entre la frontière indienne et l'intérieur des États-Unis. Vous utilisez donc la stratégie par défaut définie sur Refuser et l'appel bloqué.

Scénario 4 : Le téléphone IP en Inde appelle le téléphone IP aux États-Unis, US Ext le transfère à l'utilisateur RTPC

Comportement attendu : Refuser l'appel

Comportement observé : Appel refusé

Le téléphone IP indien Ext 7001 appelle le téléphone IP américain Ext 5005, le téléphone IP américain Ext 5005 clique sur la touche de fonction transfer first time, compose le numéro RTPC 1005, clique à nouveau sur la touche transfer.

Lorsque le poste américain transfère l'appel vers le RTPC, vous recevez une mise à jour du cluster américain.

UPDATE sip:7001@10.106.97.137:5060 SIP/2.0

Via: SIP/2.0/UDP 10.106.97.135:5060;branch=z9hG4bKbe39bb25ad

From: <sip:5005@10.106.97.135>;tag=6376~7e829a6c-a04d-4a5f-8048-8b0b0ec17d7b-18364784

To: <sip:7001@10.106.97.137>;tag=9968~771bfd92-7ded-4e46-8bd8-6830680e49b2-18365199

Date: Wed, 13 Mar 2019 10:57:03 GMT

Call-ID: b6619180-c881e1f8-26cd-89616a0a@10.106.97.137

User-Agent: Cisco-CUCM10.5

Max-Forwards: 70

Supported: timer,resource-priority,replaces

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

CSeq: 103 UPDATE

Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=MIXED

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires:  1800;refresher=uac

Min-SE:  1800

Geolocation:

;inserted-by="10.106.97.135"

P-Asserted-Identity: <sip:1005@10.106.97.135>

Remote-Party-ID:

;party=calling;screen=yes;privacy=off

Contact: <sip:1005@10.106.97.135:5060>

Content-Type: application/pidf+xml

Content-ID: 1005@10.106.97.135

Content-Length: 872

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"

xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"

xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"

xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"

xmlns:cisco="http://www.cisco.com"

entity="pres:geotarget@example.com">

<dm:device id="sg89ae">

<caps:devcaps>

true

</caps:devcaps>

<gp:geopriv>

<gp:location-info>

<cl:civicAddress>

US

TEX

SAN

BGL1

</cl:civicAddress>

</gp:location-info>

<gp:usage-rules>

<gp:retransmission-allowed>yes</gp:retransmission-allowed>

<gp:retention-expiry>2019-03-14T10:57:14Z</gp:retention-expiry>

</gp:usage-rules>

</gp:geopriv>

<timestamp>2019-03-13T10:57:14Z</timestamp>

</dm:device>

</presence>

Dans la mise à jour, vous voyez que le périphérique avec lequel il interagit est un élément de bordure. Avec cette information, CUCM du côté indien applique une nouvelle fois une partition logique sur cet appel et le résultat est refuser l'appel.

Dans les journaux CUCM, vous voyez ceci :

00443670.032 |16:27:14.830 |AppInfo  |LPPolicyManager -getLogicalPartitionPolicy, devtypeA[Interior], devtypeB[Border]

00443670.033 |16:27:14.830 |AppInfo  |LogicalPolicyTree -searchPolicy devTypeA[Interior], devTypeB[Border]

00443670.034 |16:27:14.830 |AppInfo  |GeolocNamValPair -printList: country = IN, A1 = KAR, A2 = BAN, NAM = BGL14,

00443670.035 |16:27:14.830 |AppInfo  |GeolocNamValPair -printList: country = US, A1 = TEX, A2 = SAN, NAM = BGL1,

00443670.064 |16:27:14.830 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, DEFAULT POLICY found is [2]

00443670.065 |16:27:14.830 |AppInfo  |LPPolicyManager -findLogicalPartitionPolicyUsingVals, POLICY found is [9]

Partie B, c'est-à-dire que l'appareil des États-Unis est maintenant mis à jour de l'élément Interne à la frontière. La stratégie par défaut est mise en correspondance et la stratégie par défaut dans le cluster Inde est Deny.

Scénario 5 : téléphone IP en Inde appelle le téléphone IP aux États-Unis, utilisateur RTPC des conférences externes américaines

Comportement attendu : Refuser l'appel

Comportement observé : Appel autorisé

Ce dernier scénario fonctionne, juste avec le moyen de transport Location, nous ne serons pas en mesure de bloquer la conférence téléphonique qui est initiée aux États-Unis par les partitions logiques configurées dans le cluster Inde. Ceci est une limite de cette configuration. Pour surmonter cette limitation, vous devez configurer la partition logique sur le cluster UC.

La section suivante de la configuration doit être effectuée du côté US Cluster.

Configuration du cluster US

La configuration du cluster US peut être divisée en ces parties.

- Configuration de la géolocalisation

- Activation de la géolocalisation

- Affectation de la géolocalisation aux périphériques

- Configuration des politiques de partition logique

- Configuration de la relation entre les politiques de partition logique

Configurer la géolocalisation

Dans ce cas, trois géolocalisations sont créées.

- Pour les périphériques en Inde : Inde_GL

- Pour la liaison SIP dans ICT : US_ICT_GL

- Pour les périphériques aux États-Unis : GL_US

Cette image montre la configuration US_GL.

Cette image montre la configuration US_ICT_GL.

Cette image montre la configuration India_GL.

Pour le filtre, les champs A1, A2 et NAM sont utilisés, comme l'illustre l'image.

Activer la géolocalisation

Activer la partition logique sur le paramètre d'entreprise, Stratégie par défaut sur Autoriser.

Affecter la géolocalisation aux périphériques

Note: Vous auriez déjà configuré le pool de périphériques de téléphones IP US avec la géolocalisation US_GL.

Attribuez US_ICT_GL à la ligne principale SIP ICT du cluster US.

Configurer les stratégies de partition logique

Deux politiques logiques sont créées dans le cluster américain.

- Politique indienne : Country=IN, A1=KAR, A2=BAN, NAM=BGL14

- Politique américaine : Pays = US, A1=TEX, A2=SAN, NAM=BGL1

Politique logique américaine

Type de périphérique, stratégie et sa relation avec d'autres tables de stratégies.

Type de périphérique

Politique

Type de périphérique

Politique

Résultat

Frontière

Pays=États-Unis, A1=TEX, A2=SAN, NAM=BGL1(Politique américaine)

Intérieur

Country=IN, A1=KAR, A2=BAN, NAM=BGL14(Politique indienne)

Refuser

Cette configuration en place dans le cas d'un téléphone IP en Inde appelle téléphone IP aux États-Unis, téléphone IP États-Unis Conférences utilisateur PSTN est maintenant bloqué.

Ce message d'erreur s'affiche sur le téléphone IP américain lorsque nous tentons de mettre en conférence un utilisateur PSTN américain avec un téléphone IP indien.

Une fois la géolocalisation configurée dans le cluster américain, le comportement des scénarios 2 et 4 est identique. Le cluster indien n'a pas à attendre une mise à jour/invitation SIP de la grappe américaine car le refus des appels se produira sur la grappe américaine elle-même en raison de la partition logique qui entrera en vigueur du côté américain.

Avec cela, CUG doit fonctionner entre le cluster Inde et États-Unis et assurez-vous de ne pas mélanger l'appel VOIP d'un cluster à l'appel PSTN d'un autre cluster.

Évoluer à l'avenir

Ajout d'un nouveau cluster au réseau d'entreprise

Pour mettre à niveau et prendre en charge de nouveaux clusters, supposez que vous avez 2 nouveaux clusters à ajouter. Cluster Royaume-Uni et cluster France.

En termes de configuration avec la configuration existante, vous ajoutez ces éléments

Du côté indien

- Il suffit d'ajouter une géolocalisation du Royaume-Uni et de France dans le cluster de l'Inde.

- Affectez la géolocalisation des TIC à la ligne SIP allant au Royaume-Uni et en France.

- Assurez-vous que la case Envoyer les informations de géolocalisation est cochée sur la ligne principale SIP ou ICT.

Grappe britannique

- Créer une géolocalisation pour le Royaume-Uni, les TIC et l'Inde avec le même filtre que les autres clusters (similaire à la configuration de cluster américaine).

- Conservez la stratégie par défaut comme autorisé.

- Assurez-vous que la case Envoyer les informations de géolocalisation est cochée sur la ligne principale SIP ou ICT.

- Attribuez le filtre de géolocalisation et de géolocalisation au SIP trunk/ICT en tant que TIC.

- Créer 2 politiques logiques Politique du Royaume-Uni et Politique de l'Inde.

- Dans la politique du Royaume-Uni configurer la relation de partition logique entre la frontière du Royaume-Uni à l'intérieur de l'Inde comme refus.

Le pôle France

- Créer une géolocalisation pour la France, les TIC et l'Inde avec le même filtre que les autres clusters (similaire à la configuration de cluster américaine).

- Conservez la stratégie par défaut comme autorisé.

- Assurez-vous que la case Envoyer les informations de géolocalisation est cochée sur la ligne principale SIP ou ICT.

- Attribuez le filtre de géolocalisation et de géolocalisation au SIP trunk/ICT en tant que TIC.

- Créer 2 politiques logiques, la politique de la France et la politique de l'Inde.

- En France, la politique configure la relation de partage logique entre la frontière française et l'intérieur de l'Inde comme refus.

L'ajout d'un nouveau cluster à partir d'un autre comté suivrait les étapes ci-dessus. Cela permet de limiter la configuration et de l'adapter si vous ajoutez des clusters supplémentaires

Que faire si vous avez une PME?

Les PME sont porteuses d'informations de géolocalisation sans participer à aucun partitionnement logique sur le cluster des PME.

- Cochez la case Envoyer des informations de géolocalisation sur la ligne SIP ou les TIC.

- Pas besoin de configuration de géolocalisation sur SME.

.

Toute la configuration de géolocalisation et le partitionnement logique sont effectués uniquement sur le noeud leaf. La configuration sur le noeud leaf est similaire à une configuration de géolocalisation entre 2 clusters sur ICT. La PME transmet simplement les informations de géolocalisation qu’elle reçoit sur une liaison à une autre liaison lorsqu’elle agit comme un mandataire.

Note: La Liste n'est en aucun cas exhaustive. En tant qu'administrateur, vous devez tester le parcage d'appels et la prise d'appels (locale et distante), SNR, EM, EMCC, HuntPilot, le transfert et la conférence liés à CTI, Adhoc, la conférence Meet-Me sur le cluster et le tester.

Limite

Le chaînage de conférence - par exemple, MeetMe et la conférence en chaîne ad hoc peuvent avoir des participants qui sont refusés mais qui ne peuvent pas être empêchés d'être en communication.

Recommandation - Désactivez le chaînage de conférence à partir de son paramètre Service.

Cas d'angle de CBarge/Barge - Lorsque la partie connectée est un pont de conférence en raison d'une fonctionnalité active, telle que Conférence ou Meet-Me, et qu'un périphérique de ligne partagée actif est associé à la géolocalisation autorisée pour tous les périphériques de la conférence, le périphérique de ligne partagée utilisé à distance affiche les informations d'instance d'appel. Dans ce cas, le téléphone utilisé à distance peut toujours exécuter la fonction InsConf/Ins même si un participant non autorisé participe à la conférence. Pour les participants dans InsConf/Ins, aucune vérification de stratégie de partitionnement logique n'existe et les scénarios de partitionnement logique refusé ne peuvent pas être empêchés.

Informations connexes

- https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/11_5_1/sysConfig/11_5_1_SU1/cucm_b_system-configuration-guide-1151su1/cucm_b_system-configuration-guide-1151su1_chapter_01010001.html

- https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/11_5_1/sysConfig/11_5_1_SU1/cucm_b_system-configuration-guide-1151su1/cucm_b_system-configuration-guide-1151su1_chapter_01010000.html

- https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-callmanager/116038-logical-partition-geolocation-00.html

- https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmfeat/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100/CUCM_BK_F3AC1C0F_00_cucm-features-services-guide-100_chapter_011100.html

- https://tools.ietf.org/html/rfc6442

- Support et documentation techniques - Cisco Systems