Contenido

Introducción

Términos asociados a la geolocalización

GeoLocation

Filtro de geolocalización

Identificador de geolocalización

Registro de políticas de geolocalización (GLP)

Envío de ubicación

Implementar la geolocalización en todo el clúster de CUCM

Antecedentes

Teoría

Diseño

Configuración en CUCM

Configuración de la geolocalización

Habilitar geolocalización

Asignación de geolocalización a dispositivos

Configurar políticas de partición lógica

Configurar relaciones entre políticas de partición lógica

Política lógica de TIC

Política lógica de India

Escenarios

Escenario 1: Teléfono IP en India llama a teléfono IP en Estados Unidos

Escenario 2: Teléfono IP en India llama a teléfono IP en Estados Unidos, teléfono IP de India transfiere llamada a usuario PSTN

Escenario 3: Teléfono IP en India llama a teléfono IP en EE. UU., India IP Phone Conferencia a usuario PSTN

Escenario 4: Teléfono IP en India llama a teléfono IP en EE. UU., US Ext lo transfiere al usuario PSTN

Situación 5: el teléfono IP de la India llama al teléfono IP en EE. UU.; el usuario PSTN de las conferencias externas de EE. UU.

Configuración del clúster de US

Configuración de la geolocalización

Habilitar geolocalización

Asignación de geolocalización a dispositivos

Configurar políticas de partición lógica

Política lógica de US

Ampliación en el futuro

Adición de un nuevo clúster a la red empresarial

¿Qué hacer si tiene una PYME?

Limitación

Información Relacionada

Introducción

Este documento trata sobre cómo extender la geolocalización a través de la implementación de varios clústeres con Location Connection. Con esta nueva información sobre cómo hacer que Closed User Group (CUG) funcione entre un clúster regulado y no regulado con una configuración mínima. También garantiza cómo cumplir las normas reglamentarias.

Términos asociados a la geolocalización

GeoLocation

Por definición, GeoLocation es una descripción del área geográfica física donde existe algo actualmente. En CUCM, la geolocalización asigna los detalles de la ubicación a dispositivos como el teléfono IP, el troncal SIP, la puerta de enlace troncal entre clientes (ICT), etc., lo que podría tener sentido en toda la empresa, en los clústeres y los sitios.

RFC 4119 especifica 17 elementos de ubicación cívica y la función de partición lógica de UCM implementada la configuración manual de estos 17 campos/elementos de las configuraciones de administración. Se recomienda rellenar los 17 campos. Los campos se deben denominar lógicos y cortos.

Filtro de geolocalización

El filtro de geolocalización es una regla para seleccionar determinados campos de geolocalización para construir una cadena de geolocalización, que se puede utilizar para hacer coincidir las políticas de la función de partición lógica. es decir,  daría conjuntos de campos de geolocalización para los que se deben configurar políticas

Identificador de geolocalización

Identificador construido a partir de una combinación de geolocalización, filtro y tipo de dispositivo. Este identificador se utiliza para comparar con LP y la llamada se permitiría o denegaría

Geolocalización de dispositivos: filtro de geolocalización + tipo de dispositivo = identificador de geolocalización

Es decir, un troncal SIP en CUCM se puede representar lógicamente como

Frontera:País:IN:A1:KAR:A2:BAN

Registro de políticas de geolocalización (GLP)

Las políticas no se configuran directamente entre geolocalizaciones, porque las geolocalizaciones normalmente tienen los 17 campos configurados y posiblemente serían únicas para cada dispositivo UCM en un clúster. Por lo tanto, la configuración de políticas entre geolocalizaciones puede ser una sobrecarga para un administrador, dado el número de geolocalizaciones.

A fin de elaborar políticas, Admin necesita construir registros que tengan los datos necesarios para los campos de geolocalización. Con este fin, la configuración proporciona la disposición para seleccionar datos de los desplegables que muestran los campos de geolocalización.

Estos registros se denominan registros de GeolocationPolicy (GLP).

Nota: Los registros de GeolocationPolicy se deben realizar de modo que los datos correspondientes coincidan con los campos seleccionados en los filtros. La jerarquía de campos es importante y los campos no deben perderse al principio ni al medio, pero podrían perderse al final.

Si los campos específicos para el filtro no están en la política, el algoritmo de búsqueda elimina el campo del final y busca una posible coincidencia en las políticas.

Ejemplo: Si he seleccionado un campo C, A1, A2, A6 para un LP y otro LP solamente tiene C, A1, A6, entonces el CUCM entre este 2 LP sólo toma C, A1 aunque A6 está presente en ambos CUCM lo ignora.

Envío de ubicación

- La transmisión de GeoLocation de un agente de usuario SIP a otra entidad que utiliza SIP se denomina Conveyance de ubicación.

- Para soportar los requerimientos de LP, la implementación de UCM comunica adicionalmente la información del tipo de dispositivo en PIDF-LO. Esto se basa en User Agent Capability Presence Status, según lo especificado en la extensión SIP draft-ietf-simple-prescaps-ext-08.

- El troncal SIP de UCM admite la transmisión de ubicación según estas especificaciones.

- Para permitir que las TIC sean compatibles con el troncal SIP y permitan las mismas capacidades, el troncal ICT/H225 también soporta el transporte de ubicación a través del clúster usando PIDF-LO.

- El UCM admite la transmisión de información de ubicación tanto en el establecimiento de llamadas como en los cambios de ubicación debido al cambio en la parte conectada en la participación a las uniones y redirecciones de llamadas intermedias.

Implementar la geolocalización en todo el clúster de CUCM

Suposición: Tener un entendimiento básico de la geolocalización y por qué es necesaria.

Para este documento, hemos utilizado 2 clústeres de CUCM. Se supone que un clúster reside en Estados Unidos y otro en la India. Utilizamos las versiones 11.5 y 10.5 de CUCM con fines de demostración. Tenemos un enlace troncal SIP entre los clústeres. El plan de marcación está configurado de modo que sólo se permiten llamadas internas en este troncal ICT/SIP desde ambos clústeres mediante CSS y partición. El plan de marcación se ha configurado de modo que las llamadas VOIP a PSTN utilicen la puerta de enlace local para realizar llamadas PSTN mediante CSS y partición.

El clúster de India es un clúster con reconocimiento/habilitado de partición lógica. El clúster de Estados Unidos es una partición lógica inhabilitada/no consciente. El filtro de geolocalización y geolocalización se configura y se aplica a todos los dispositivos de ambos clústeres. Por ahora, configure la partición lógica solamente en el clúster de India, más tarde se encuentra una limitación debido a la cual la geolocalización está habilitada y configura la partición lógica también en el clúster de US.

Extensión VOIP de India : 7XXX (7001, 7002)

Extensión USA VOIP: 5XXX (5005)

Extensión PSTN: 1XXX (1005)

Esta es la imagen con identificadores de geolocalización.

Antecedentes

En el lado de la India, se aplica la regulación TRAI. En términos simples, no mezcle llamadas VoIP no locales con llamadas PSTN locales. Se permiten llamadas de grupos de usuarios cerrados (CUG), es decir, se permiten llamadas VoIP dentro de la misma red empresarial.

Cuando tenga varios clústeres de CUCM en una ubicación geográfica diferente y uno de ellos esté regulado, el objetivo será

1. Cumplir con el TRAI o las normas reglamentarias

2. Hacer que CUG funcione

Teoría

Para que CUG funcione, la transmisión de ubicación se utiliza para ampliar la aplicación de políticas de partición lógica, es decir, la información de geolocalización se envía a otros clústeres, ya que Send Geolocation Data se verifica en el troncal de ICT y SIP en ambos clústeres. Esto permite enviar y recibir información de geolocalización de los dispositivos y, junto con eso, también puede saber si el dispositivo es un interior o un borde.

Para la configuración inicial de la llamada, necesita una política que permita la comunicación entre el teléfono IP A y las TIC. Una vez que se envía SIP INVITE a otros clústeres, detecta el dispositivo de destino B y, una vez que este dispositivo está sonando o contestando la llamada, la información de geolocalización del dispositivo B se envía al clúster de origen a través de un mensaje SIP INVITE/UPDATE. Una vez que el clúster de origen recibe información de geolocalización válida en el mensaje INVITE/UPDATE que reemplaza la configuración de geolocalización del troncal SIP local y la reemplaza por la geolocalización recibida.

Con esta nueva información de geolocalización, puede tener una política de partición lógica configurada para permitir VOIP a llamadas VOIP y denegar llamadas VOIP desde el clúster que llega al dispositivo de borde de un clúster diferente.

Nota: En este escenario, todos los clústeres deben tener geolocalizaciones y filtros de geolocalización configurados y aplicados a todos los grupos de dispositivos. Las llamadas entre clústeres incluyen datos de geolocalización y si el participante se considera interior o fronterizo. Si los datos de geolocalización no se reciben en una llamada entre clústeres, se utiliza en su lugar el filtro de geolocalización y geolocalización en la configuración troncal o heredado del grupo de dispositivos del tronco.

Diseño

Para diseñar geolocalización y partición lógica, piense en

- ¿Cómo identificar de forma única el lugar físico del dispositivo que realiza la llamada y el dispositivo que la recibe?

- Recopile información sobre entre qué geolocalización/lugar físico debo tener restricciones de llamadas en vigor.

- De los 17 campos seleccionados, puede decidir si desea permitir o denegar la llamada.

En los campos de geolocalización tiene 17 campos, que van desde A1 hasta A6 hasta código zip. Para rellenar desde A1 es como acercar a un mapa. Cuantos más detalles ponga, más exactamente se puede identificar la ubicación del dispositivo, a la que se asigna esta geolocalización. Lo que hay que tener en cuenta es, de todos los campos de geolocalización, qué campos deberían incluir un par de dispositivos presentes en CUCM con los que se puede tomar una decisión de partición lógica efectiva.

Cuando se configura la política de particiones lógicas, tiene la opción de seleccionar un conjunto de campos de geolocalización, seleccione esos campos de geolocalización de modo que cuando un dispositivo realiza una llamada, presenta un conjunto de identificadores de geolocalización a CUCM y el dispositivo de destino recibe una llamada que presenta un conjunto de identificadores de geolocalización a CUCM. Si estos campos coinciden con una política de partición lógica predefinida, podrá aplicar restricciones a las llamadas.

Ejemplo. Si el dispositivo A tiene una información de geolocalización A1=IN,A2=BAN,NAM=BGL14 y el dispositivo B tiene una geolocalización A1=IN,A2=MUM,NAM=BAN1. Cree una política de geolocalización 1 de forma que A=IN,A2=BAN,NAM=BGL14. Cree la política 2 A=IN,A2=MUM,NAM=BAN1. Debe permitir o denegar entre dispositivos que coincidan con las políticas 1 y 2.

Si se realiza una llamada y el dispositivo de origen tiene información de geolocalización A1=IN,A2=BAN,NAM=BGL14, entonces CUCM sabe que se puede seleccionar la política 1. Si el dispositivo de destino también tiene información de geolocalización A1=IN,A2=MUM,NAM=BAN1, entonces CUCM sabe que es una coincidencia perfecta para la relación lógica de partición entre la política 1 y 2.

Nota: Se recomienda que los campos Filtrado de geolocalización y Política de Partición Lógica seleccionados tengan los mismos campos seleccionados y coincidentes o que el campo Política de Partición Lógica sea un subconjunto de campos de Filtro de geolocalización de modo que cuando se realiza una llamada tenga la política de Partición Lógica coincidente en la primera iteración. Debe intentar una coincidencia perfecta cuando se realizan llamadas.

Configuración en CUCM

La configuración del clúster de India se puede dividir en estas partes:

Configuración de la geolocalización

En este caso, se crean tres geolocalizaciones.

- Para dispositivos en India: India_GL

- Para troncal SIP en ICT: India_ICT_GL

- Para dispositivos en EE. UU.: US_GL

Nota: En el clúster de India, se configura un Empty_GL y esto se da como geolocalización predeterminada. Esto se hace de modo que en caso de que olvide agregar geolocalización a cualquier dispositivo a través del conjunto de dispositivos, esta geolocalización se utiliza para denegar llamadas a cualquier dispositivo de borde.

Esta imagen muestra la configuración de India_GL.

Esta imagen muestra la configuración India_ICT_GL.

Esta imagen muestra la configuración US_GL.

Como se muestra en la imagen, para los campos de filtro de geolocalización, País, A1, A2, NAM se utilizan.

Habilitar geolocalización

Habilitar partición lógica en el parámetro de empresa, establecer una política predeterminada en Denegar, aplicar geolocalización predeterminada como Empty_GL.

Asignación de geolocalización a dispositivos

- En el grupo de dispositivos CUCM para teléfono IP, asigne India_GL.

- En el Troncal SIP de ICT asigne India_ICT_GL y verifique para enviar información de geolocalización.

Una vez hecho esto, pase al clúster de UC. Debe crear una política de geolocalización de EE. UU. y asociarla a los dispositivos del clúster de EE. UU.  Asegúrese de que la casilla de verificación Enviar información de geolocalización esté activada en el troncal SIP o en las TIC entre el clúster de Estados Unidos e India.

Después de que la configuración en el clúster de Estados Unidos haya finalizado, vuelva al clúster de India.

Configurar políticas de partición lógica

Se crean tres políticas lógicas.

- Política de TIC: Country=IN,A1=KAR,A2=BAN,NAM=ICT

- Política India : Country=IN,A1=KAR,A2=BAN,NAM=BGL14

- Política estadounidense: Country=US,A1=TEX,A2=SAN,NAM=BGL1

Configurar relaciones entre políticas de partición lógica

Una vez configurada la partición lógica, rellene las relaciones entre las dos políticas.

Política lógica de TIC

Tipo de dispositivo, política y su relación con otras tablas de políticas.

Tipo de dispositivo

Política

tipo de dispositivo

Política

Resultado

Borde

Country=IN,A1=KAR,A2=BAN,NAM=ICT(Política de TIC)

Borde

Country=IN,A1=KAR,A2=BAN,NAM=ICT(Política de TIC)

Permiso

Borde

Country=IN,A1=KAR,A2=BAN,NAM=ICT(Política de TIC)

Interior

Country=IN,A1=KAR,A2=BAN,NAM=BGL14(Política de la India)

Permiso

- Se necesita un teléfono IP interno para llegar a las TIC antes de obtener la actualización del dispositivo desde el lado de EE. UU., por lo que tiene Border:Country=IN,A1=KAR,A2=BAN,NAM=ICT (ICT SIP trunk) a Interior:Country=IN,A1=KAR,A2=BAN,NAM=BGL14 (Teléfonos IP en India) como Allow (Permitir).

- En caso de que necesite volver a realizar la llamada a EE. UU. Entonces necesita las llamadas ICT a las TIC, como se permite, para tener la relación Frontera:País=IN,A1=KAR,A2=BAN,NAM=ICT a la frontera:País=IN,A1=KAR,A2=BAN,NAM=ICT como permitir.

Política lógica de India

Tipo de dispositivo, política y su relación con otras tablas de políticas.

Tipo de dispositivo

Política

tipo de dispositivo

Política

Resultado

Interior

Country=IN,A1=KAR,A2=BAN,NAM=BGL14(Política de la India)

Borde

Country=IN,A1=KAR,A2=BAN,NAM=BGL14(Política de la India)

Permiso

Con esta configuración, tiene la partición lógica configurada sólo en el clúster de India y tiene la transmisión de ubicación entre los clústeres de Estados Unidos e India. Debe ser capaz de bloquear las llamadas entre el clúster de Estados Unidos y la India para que no se mezcle con PSTN y para que CUG funcione. Pruebe esta configuración realizando algunas llamadas.

Escenarios

- IP Phone en India llama a un teléfono IP en Estados Unidos.

- Teléfono IP en India llama a un teléfono IP en EE. UU., India IP Phone Transfiere una llamada al usuario PSTN.

- IP Phone en India llama a un teléfono IP en EE. UU., India IP phone Conference PSTN User (Usuario PSTN de conferencias de teléfonos IP en India).

- Teléfono IP en India llama a un teléfono IP en EE. UU., US Ext lo transfiere al usuario PSTN.

- El teléfono IP de India llama a un usuario PSTN de EE. UU., conferencias externas de EE. UU.

Escenario 1: Teléfono IP en India llama a teléfono IP en Estados Unidos

Comportamiento esperado: Permitir la llamada

Comportamiento observado: La llamada está permitida

El teléfono IP de la India Ext 7001 nos llama Ext 5005.

Aquí está el diagrama de la escalera troncal SIP

Puede dividir la llamada en dos partes.

- Antes de obtener la información de geolocalización del clúster de Estados Unidos.

- Después de obtener la información de geolocalización del clúster de Estados Unidos.

Si observa que primero hay 200 OK y ACK para la invitación SIP inicial. Si observa más de cerca el 200 OK que obtuvo del clúster de Estados Unidos, se observa que el puerto RTP es un puerto ficticio, es decir, 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 no ha comenzado a fluir todavía. Después de ACK verá otra SIP INVITE y, en esta, se enviará información de geolocalización a sí mismo.

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--

En esta invitación, verá el número de puerto RTP que utilizará el teléfono IP de EE. UU. La información de geolocalización del teléfono IP e información sobre si se trata de una puerta de enlace o no se envía al clúster de India. Con esta nueva información de geolocalización, una vez más las particiones lógicas coinciden en el clúster de India para ver si la llamada debe ser permitida o denegada. Como se trata de llamadas interiores, la partición lógica no se aplica y se permite la llamada

Escenario 2: Teléfono IP en India llama a teléfono IP en Estados Unidos, teléfono IP de India transfiere llamada a usuario PSTN

Comportamiento esperado: Denegar la llamada

Comportamiento observado: Se niega la llamada

El teléfono IP de India Ext 7001 nos llama Ext 5005, toca la tecla programada transfer la primera vez, marca PSTN número 1005, presiona la tecla de transferencia pero no pasa nada.

En los seguimientos de CUCM, ya ven.

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.

En la parte de clúster de India, A va a un dispositivo PSTN, es decir, un elemento de borde. No ha establecido ningún permiso entre la frontera de la India y el interior de EE. UU., por lo que utiliza la política predeterminada establecida para denegar y bloquear la llamada.

Escenario 3: Teléfono IP en India llama a teléfono IP en EE. UU., India IP Phone Conferencia a usuario PSTN

Comportamiento esperado: Denegar la llamada

Comportamiento observado: Se niega la llamada

El teléfono IP de la India Ext 7001 llama al Ext 5005, el teléfono IP de la India Ext 7001 hace clic en la tecla programada Confr. la primera vez, marca el número PSTN 1005, hace clic en la tecla programada Confr., como se muestra en la imagen. Sin embargo, verá que Conferencia no está disponible.

En los registros de CUCM, verá lo siguiente:

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

En la parte de clúster de India, A va a un dispositivo PSTN, es decir, un elemento de borde. No ha establecido ningún permiso entre la frontera de la India y el interior de EE. UU., por lo que utiliza la política predeterminada que está configurada para denegar y la llamada está bloqueada.

Escenario 4: Teléfono IP en India llama a teléfono IP en EE. UU., US Ext lo transfiere al usuario PSTN

Comportamiento esperado: Denegar la llamada

Comportamiento observado: Se niega la llamada

El teléfono IP de la India Ext 7001 llama al teléfono IP de EE. UU. Ext 5005, el teléfono IP de EE. UU. Ext 5005 hace clic en la tecla programada transfer la primera vez, marca el número PSTN 1005, hace clic en transfer de nuevo.

Cuando la extensión de US transfiere la llamada a PSTN, obtiene una actualización del clúster de US.

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>

En la actualización, verá que el dispositivo con el que interactúa es un elemento de borde. Con esta información, CUCM en el lado de India aplica una nueva partición lógica en esta llamada y el resultado es negar la llamada.

En los registros de CUCM, verá lo siguiente:

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]

La Parte B, es decir, el dispositivo de Estados Unidos se actualiza ahora del elemento interno al elemento fronterizo. La política predeterminada coincide y la política predeterminada en el clúster de India es Deny.

Situación 5: Teléfono IP en India llama al teléfono IP en EE. UU., EE. UU. Ext Conences usuario PSTN

Comportamiento esperado: Denegar la llamada

Comportamiento observado: La llamada está permitida

En este último escenario funciona la llamada, solo con la transmisión de ubicación no podremos bloquear la llamada de conferencia iniciada en EE. UU. por las particiones lógicas configuradas en el clúster de India. Esta es una limitación de esta configuración. Para superar esta limitación, debe configurar la partición lógica también en el clúster de UC.

La siguiente sección de configuración debe realizarse en el lado del cliente de US.

Configuración del clúster de US

La configuración del clúster de US se puede dividir en estas partes.

- Configuración de la geolocalización

- Habilitación de la geolocalización

- Asignación de geolocalización a dispositivos

- Configuración de políticas de partición lógica

- Configuración de la relación entre las políticas de partición lógica

Configuración de la geolocalización

En este caso, se crean tres geolocalizaciones.

- Para dispositivos en India: India_GL

- Para troncal SIP en ICT: US_ICT_GL

- Para dispositivos en EE. UU.: US_GL

Esta imagen muestra la configuración US_GL.

Esta imagen muestra la configuración US_ICT_GL.

Esta imagen muestra la configuración India_GL.

Para el filtro, se utilizan los campos País A1, A2, NAM, como se muestra en la imagen.

Habilitar geolocalización

Habilitar partición lógica en parámetro de empresa, Política predeterminada como Permitir.

Asignación de geolocalización a dispositivos

Nota: A estas alturas, ya habría configurado el conjunto de dispositivos del teléfono IP de US con US_GL de geolocalización.

Asigne US_ICT_GL al troncal SIP de ICT en el clúster de US.

Configurar políticas de partición lógica

En el clúster de EE. UU. se crean dos políticas lógicas.

- Política de India: Country=IN,A1=KAR,A2=BAN,NAM=BGL14

- Política de EE. UU.: Country=US,A1=TEX,A2=SAN,NAM=BGL1

Política lógica de US

Tipo de dispositivo, política y su relación con otras tablas de políticas.

Tipo de dispositivo

Política

tipo de dispositivo

Política

Resultado

Borde

Country=US,A1=TEX,A2=SAN,NAM=BGL1(Política de EE. UU.)

Interior

Country=IN,A1=KAR,A2=BAN,NAM=BGL14(Política de la India)

Denegar

Esta configuración aplica el caso de teléfono IP en India que llama a teléfono IP en EE. UU., el usuario PSTN de conferencias de teléfono IP de EE. UU. está bloqueado.

Aparece este mensaje de error en el teléfono IP de EE. UU. cuando intentamos establecer una conferencia con un usuario PSTN de EE. UU. con un teléfono IP de India.

Una vez que la geolocalización se ha configurado en el clúster de Estados Unidos, el comportamiento para las situaciones 2 y 4 es el mismo. El clúster de India no tiene que esperar a una ACTUALIZACIÓN/INVITACIÓN SIP del clúster de EE. UU., ya que la denegación de llamadas ocurrirá en el propio clúster de EE. UU. debido a que la partición lógica entrará en vigor en el lado de EE. UU.

Con esto, debe tener CUG trabajando entre el clúster de India y Estados Unidos y asegurarse de que no mezcle la llamada VOIP de un clúster con la llamada PSTN de otro clúster.

Ampliación en el futuro

Adición de un nuevo clúster a la red empresarial

Para ampliar y dar cabida a nuevos clústeres, suponga que tiene 2 nuevos clústeres que agregar. Clúster del Reino Unido y Clúster de Francia.

En términos de configuración con la configuración existente, usted agrega estos

En el lado de la India

- Solo tienes que añadir una Geolocalización del Reino Unido y una Geolocalización de Francia en el Clúster de la India.

- Asigne la geolocalización de las TIC a la línea troncal SIP que va a Reino Unido y Francia.

- Asegúrese de que la casilla de verificación Enviar información de geolocalización esté marcada en el troncal SIP o en las TIC.

Clúster del Reino Unido

- Cree una geolocalización para el Reino Unido, las TIC y la India con el mismo filtro que otros clústeres (similar a la configuración del clúster de EE. UU.).

- Mantenga la política predeterminada como permitida.

- Asegúrese de que la casilla de verificación Enviar información de geolocalización esté marcada en el troncal SIP o en las TIC.

- Asigne el filtro de geolocalización y geolocalización al troncal SIP/ICT como ICT.

- Cree 2 políticas lógicas para la política del Reino Unido y la política de la India.

- En la política del Reino Unido, configure como deny la relación lógica de partición entre la frontera del Reino Unido y el interior de la India.

El clúster de Francia

- Cree una geolocalización para Francia, las TIC y la India con el mismo filtro que otros clústeres (similar a la configuración del clúster de EE. UU.).

- Mantenga la política predeterminada como permitida.

- Asegúrese de que la casilla de verificación Enviar información de geolocalización esté marcada en el troncal SIP o en las TIC.

- Asigne el filtro de geolocalización y geolocalización al troncal SIP/ICT como ICT.

- Cree una política lógica 2, la política de Francia y la política de la India.

- En Francia, la política configura la relación lógica de partición entre la frontera de Francia y el interior de la India como negación.

La adición de cualquier nuevo clúster de un país diferente seguiría los pasos anteriores. Esto mantiene la configuración al mínimo y puede ampliarse si agrega más clústeres

¿Qué hacer si tiene una PYME?

Las PYME actúan como portadoras de información de geolocalización sin participar en ninguna partición lógica en el grupo de PYME.

- Marque la casilla de verificación Enviar información de geolocalización en el troncal SIP o ICT.

- No se necesita configuración de geolocalización en SME.

.

Toda la configuración de geolocalización y la partición lógica se realizan solamente en el nodo de hoja. La configuración en el nodo de hoja es similar a una configuración de geolocalización entre 2 clústeres sobre ICT. La PYME simplemente pasa la información de geolocalización que recibe en un tronco a otro, ya que actúa como proxy.

Nota: La lista no es en modo alguno exhaustiva. Como administrador, debe probar el aparcamiento de llamadas y la captura de llamada (local y remota), SNR, EM, EMCC, Huntpilot, la transferencia y conferencia relacionadas con CTI, Adhoc, Meet-Me Conference en el clúster y probarlo.

Limitación

encadenamiento de conferencia: por ejemplo, la conferencia MeetMe y la conferencia ad hoc en cadena puede tener participantes que se niegan a LP pero no se les puede impedir que estén en comunicación.

Recomendación - Deshabilitar el encadenamiento de conferencia de su parámetro de servicio.

Corner case of CBarge/Barge: Cuando la parte conectada es un puente de conferencia debido a una función activa, como Conference o Meet-Me, y un dispositivo de línea compartida activo se asocia a la geolocalización permitida para todos los dispositivos de la Conferencia, el dispositivo de línea compartida remoto en uso muestra información de instancia de llamada. En este caso, el teléfono remoto en uso siempre puede realizar la función Intrus./IntruCf aunque un participante no autorizado participe en la conferencia. Para los participantes en IntruCf/IntruCf, no existe ninguna comprobación lógica de la política de particionamiento y no se pueden evitar los escenarios con partición lógica-denegada.

Información Relacionada

- 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

- Soporte Técnico y Documentación - Cisco Systems