Introducción
Este documento describe cómo configurar la partición lógica y la geolocalización en Cisco Unified Communications Manager (CUCM).
Prerequisites
Cisco recomienda que tenga conocimiento sobre estos temas:
- Cisco Unified Communication Manager
Componentes Utilizados
- Cisco Unified Communications Manager 8.6 o posterior
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Antecedentes
La función de partición lógica garantiza que se pueda utilizar un único sistema para admitir ambos tipos de llamadas, siempre y cuando las llamadas que pasan a través de una puerta de enlace de red telefónica pública conmutada (PSTN) no se conecten directamente a un teléfono de voz sobre IP (VoIP) o a una puerta de enlace VoIP PSTN en otra ubicación geográfica (geolocalización) incluso cuando se invoca una función de llamada media.
En algunos países, como la India, hay regulaciones de telecomunicaciones que deben cumplirse a nivel empresarial. Debido a lo cual las empresas pueden configurar una infraestructura de voz. Están configurados de modo que la PSTN local se utiliza exclusivamente al conectar llamadas fuera de la empresa. Según la Autoridad Reguladora de las Telecomunicaciones (TRAI), la red de telefonía PSTN en India nunca debe estar interconectada con la red de telefonía VoIP para fines de Toll ByPass.
Esto requiere que el sistema de voz se divida lógicamente en dos sistemas: un VoIP dentro de la empresa y otro para acceder a la PSTN local.
Fue bastante difícil mantener este tipo de sistema de voz con la función Calling Search Space (CSS) y Partition en CUCM. CSS y Partition pueden restringir las llamadas básicas, pero no restringen las funciones de llamadas intermedias como redirigir y unirse.
Elementos de partición lógica
Geolocalización
CUCM requiere el aprovisionamiento de identificadores para asignarlos a dispositivos como teléfonos, gateways, troncales, etc. La geolocalización es un estándar que se puede utilizar como identificador en la partición lógica.
La geolocalización se utiliza para especificar la ubicación física basada en hasta 17 parámetros: Abreviatura de letras del país 2, Estado (A1), Condado (A2), Ciudad (A3), Distrito (A4), Barrio (A5), Calle (A6), Dirección (PRD), Sufijo de la calle (POD), Número de la Casa (HNO) y Sufijo de número de la casa (HNS), entre otros.
Filtro de geolocalización
Una configuración típica de la política de partición lógica utiliza sólo el subconjunto de campos en el registro de política de geolocalización. Esta selección se reduce mediante el filtro de geolocalización. La función Partición lógica utiliza los campos seleccionados en el filtro de geolocalización.
Política de partición lógica
En CUCM, la partición lógica se define como una función de control de llamada que se puede utilizar para restringir la comunicación entre estas entidades VoIP con la ayuda de políticas de partición lógica.
- Teléfono IP hacia/desde Gateway
- Puerta de enlace a la puerta de enlace
- Teléfono IP desde/hacia troncal (línea troncal ICT/SIP)
- Puerta de enlace hacia/desde el enlace troncal (línea troncal ICT/SIP)
Los dispositivos de la partición lógica se clasifican como interiores y de borde. Estos son los dispositivos clasificados como interiores:
- Teléfonos (SCCP, SIP, terceros)
- Teléfonos analógicos VG224
- Puerto MGCP (FXS)
- Correo de voz de Cisco Unity (SCCP)
- Punto de ruta CTI, puerto CTI
- Gateway QSIG o ICT
Estos dispositivos se clasifican como el borde:
- Gateway
- Troncal entre clústers (ICT)
- troncal H.225
- Enlace troncal SIP
- Puerto MGCP (E1, T1, PRI, BRI, FXO)
Configuración
Paso 1. La geolocalización predeterminada es aplicable a los dispositivos en los que no se ha configurado ninguna geolocalización y no participan en la partición lógica. Para establecer la política de geolocalización predeterminada desempeña un papel importante, si se configura para permitir, entonces es necesario apropiarse de las políticas de partición lógica con funcionalidad de negación y viceversa.


Paso 2. Vaya a System-> Geolocation Configuration y agregue la información relacionada con la ubicación. Esto actúa como un identificador para los dispositivos asociados a esta geolocalización en particular.


Paso 3. Vaya a System-> Geolocation Filter (Filtro de geolocalización) y verifique los campos de la configuración de Geolocalización Filter en función de la política lógica con la que se debe filtrar.


Paso 4. Configure la política de partición lógica. Esta es la parte más importante de la configuración, ya que todas las decisiones para permitir o denegar las llamadas dependen de su configuración.


Paso 5. Vaya a la página de configuración del dispositivo del teléfono y aplique la geolocalización en función de la ubicación del teléfono.
Del mismo modo, vaya al conjunto de dispositivos y agregue la configuración de geolocalización.
Paso 6. A continuación, vaya a la página de configuración del puerto Gateway/Trunk/MGCP que actúa como interfaz a la PSTN y aplica la configuración de geolocalización y el filtro de geolocalización.
Troubleshoot
Paso 1. La opción Comprobar parámetros de empresa que habilita la partición lógica se establece en True.
Paso 2. Asegúrese de que los dispositivos están asociados a una geolocalización válida en el nivel de grupo de dispositivos o dispositivos.
Paso 3. Compruebe en la página de configuración que el dispositivo está asociado a un filtro de geolocalización válido, con la selección de algunos de los campos de geolocalización en el nivel de grupo de dispositivos o dispositivos.
Paso 4. Asegúrese de que la sensibilidad del caso es correcta para los campos de los registros de política de geolocalización de LP y coincide con la configuración de los registros de geolocalización.
Paso 5. La configuración de geolocalización, los filtros y las políticas también se pueden verificar desde la CLI con la ayuda de estos comandos SQL.
run sql select * from geolocationfilter
run sql select * from geolocationpolicy
run sql select * from geolocationpolicymatrix
run sql select * from typelogicalpartitionpolicy
Paso 6. Después de verificar la configuración básica, verifique la relación establecida entre las políticas de geolocalización. Cuando la política predeterminada de partición lógica de parámetro empresarial se establece en Denegar, verifique si se configuran las políticas de partición lógica Permitir entre la política de geolocalización de un sitio de gateway y VoIP. Por el contrario, si la política predeterminada es Allow, verifique si Deny están configuradas las políticas de partición lógica.
Paso 7. Asegúrese de que no haya políticas superpuestas o en conflicto configuradas.
Ejemplo.

LP-India->Interior LP-Pudong->Permiso de frontera
LP-Pudong->Frontera LP-India->Denegación interior
Aquí la relación lógica entre las políticas tiene un conflicto. Si se configura una política lógica interior LP-India a la frontera LP-pudong, implica que esta relación se aplica al pudong de borde-LP a LP-India. Estas políticas son de naturaleza bidireccional.
En este ejemplo, según la primera política, los teléfonos IP internos en la ubicación de Pudong pueden llamar vía PRI-India. Al mismo tiempo, se permiten llamadas PSTN desde PRI-India a los teléfonos IP en la Geolocalización Pudong.
Pero según la segunda política, se niegan las llamadas de India-PRI a teléfonos IP en la ubicación de Pudong y viceversa, pero esto entra en conflicto con la primera política.
En tales casos, recuerde que la política que se agregó por última vez tendrá prioridad.
Paso 8. Realice un seguimiento de las políticas superpuestas con la función Unified Reporting para obtener la matriz de la política de partición lógica. Es muy útil resolver problemas, ya que puede conocer todas las políticas de partición lógica configuradas en CUCM desde una única pantalla. La política de geolocalización de Unified CM con el informe de filtro proporciona una lista completa de registros de la matriz de política de partición lógica de geolocalización para las políticas de geolocalización seleccionadas, mientras que el informe de política de geolocalización de Unified CM proporciona una lista completa de registros de todas las políticas de partición lógica.



Paso 9. Realice algunas llamadas de prueba y compruebe si funciona. La herramienta de supervisión en tiempo real (RTMT) se mejora para realizar un seguimiento del número de fallos debido a las restricciones de políticas de partición lógica en los nuevos contadores de Perfmon. Los contadores Perfmon tienen un nuevo grupo llamado Restricción de llamada de Cisco. A partir de ahí, podemos realizar un seguimiento de una serie de fallas de llamada en diferentes escenarios, como fallas de transferencia, fallas de conferencia ad hoc, fallas de conferencia Meet-Me, fallas de reenvío, fallas de llamada básica, fallas de llamada media, fallas de restricción de llamada total, etc.
Paso 10. Recopile los seguimientos de CUCM de RTMT durante la duración de la llamada. En los seguimientos de la capa de distribución de señalización (SDL) puede ver la política que se está seleccionando y las políticas que se configuran entre el par de políticas de geolocalización.
Comunicación de información de geolocalización en señales CC.
| SdlSig | CcRegisterPartyA | restart0 | LineControl(1,100,139,3) | SIPCdpc(1,100,55,17) | (1,100,45,1).3035-(SEP0019555CBAE3:10.76.253.14)| [R:NP - HP: 0, NP: 2, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI=23624774 CI.branch=0 CSS= cssIns=0 aarCSS= aarDev=T doNotAppendLineCSS=F lrg= ccBearCap.itc=0 ccBearCap.l=3 ccBearCap.itr=1 protected=1 flushCapIns=0 geolocInfo={geolocPkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filterPkid=d5bdda76-6a86-56c5-b5fd-6dff82b37493, geolocVal=, devType=4} locPkid= locName=
Comunicación de información de geolocalización en señales PolicyAndRSVP.
| SdlSig | PolicyAndRSVPRegisterReq | wait | RSVPSessionMgr(1,100,76,1) | SIPCdpc(1,100,55,17) | (1,100,45,1).3035-(SEP0019555CBAE3:10.76.253.14)| [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI= 23624774 Branch= 0 reg=Default cap=5 loc=0 MRGLPkid= PrecLev=5 VCall=F VCapa=F regiState=0 medReq=0 dataCapFl=2 ipAddrMode=0 status=0 geolocInfo={geolocPkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filterPkid=d5bdda76-6a86-56c5-b5fd-6dff82b37493, geolocVal=, devType=4}
| SdlSig | PolicyRegisterReq | await_init | LPSession(1,100,26,21) | RSVPSessionMgr(1,100,76,1) | (1,100,45,1).3035-(SEP0019555CBAE3:10.76.253.14)| [R:NP - HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]CI= 23624774 Branch= 0 geolocInfo={geolocPkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filterPkid=d5bdda76-6a86-56c5-b5fd-6dff82b37493, geolocVal=, devType=4}
Puntos a considerar
- Los dispositivos de medios, es decir, MTP (Media Termination Point), (Conference Bridge) CFB, Annunciator, (Music on Hold) MoH no son necesarios para asociarse a los valores de geolocalización.
- No hay ninguna comprobación de política de LP para la función o llamada de dispositivo VoIP a VoIP con sólo participantes de VoIP. En otras palabras, siempre se permite la política del Interior al Interior.
- LPPolicyManager es un proceso singleton que interactúa con InMemDB y mantiene políticas en el procesamiento de llamadas como árbol de políticas de LP. Durante el inicio del servicio CUCM, LPPolicyManager lee las políticas de las tablas InMemDB y construye el árbol de políticas LP. El resultado de Agregar/Eliminar/Actualizar una Política en la Base de Datos es Notificación de Cambio a LPPolicyManager y el cambio se ve afectado en el árbol de políticas de LP.
Verificación de política de partición lógica.
001853112| 2008/09/26 11:50:39.687| 001| AppInfo | | | | | | LPPolicyManager -getLogicalPartitionPolicy, GeolocInfoA[pkid=31396408-3d83-74a9-1655-d2f0a05dd0a4, filter=d5bdda76-6a86-56c5-b5fd-6dff82b37493, val=, devType=4]
001853113| 2008/09/26 11:50:39.687| 001| AppInfo | | | | | | LPPolicyManager -getLogicalPartitionPolicy, GeolocInfoB[pkid=9dc76052-3a37-78c2-639a-1c02e8f5d3a2, filter=d5bdda76-6a86-56c5-b5fd-6dff82b37493, val=, devType=8]
- El DevType que aparece en los seguimientos describe los tipos de los dispositivos.
El devType =4 (UserDevice) es para estos dispositivos.
- Teléfonos (SCCP, SIP, terceros)
- Teléfonos analógicos VG224
- Puntos de ruta CTI y Puertos CTI
- Correo de voz de Cisco Unity (SCCP)
- Puerto MGCP (FXS)
devType =3 (AccessDevice) si es para estos dispositivos.
- Troncal entre clústers (ICT), controladas por el gatekeeper y no controladas por el gatekeepertroncal H.225
- Puerto MGCP (E1, T1, PRI, BRI, FXO)
- Gateway (por ejemplo, gateway H.323)
El devType =8 (SIPAccessDevice) para este dispositivo.
Referencias
Error de funcionamiento conocido
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsz91044
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuo85770
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsq79192
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsr91423
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsy73509
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtb33479
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtb05434
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsv65724
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsq73894
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsr38397