el 11-19-2013 06:54 AM
Hola.
Quisieran si me pudiesen ayudar con el siguiente escenario;
Tengo un laboratorio con un gateway de voz 2801, con CME ( telephony-service) 8.6 y un VMware ESX 5.1 con CUCM 8.6. He configurado correctamente las llamadas salientes desde cucm hacia el gateway, pero no he podido configurar las llamadas entrantes desde el puerto FXO en el gateway para los Ip Phone.
Cual son los comandos necesarios para implementantar que una llamada entrante sea contestada por un anexo ( DN) .
Saludos.
el 11-19-2013 11:42 AM
Hola Leonardo,
Parece que tienes dos call control agents (CME y CUCM). La llamada entrante por el puerto FXO hacia dónde la deseas enrutar, ¿a un teléfono en el CME o en el CUCM?.
Saludos,
- Adrián.
el 11-19-2013 12:01 PM
Hola Adrián.
Gracias por tu respesta. El CUCM 8.6 se registrarán los teléfonos IP. El gateway de voz (2801) quedará en modo SRST pero de igual manera de este se tiene que enviar y recibir llamados desde el PSTN (FXO). La llamada entrante por el FXO se desea enrutar al teléfono IP registrado en el CUCM (Vmware).
Saludos.
Dejo copy y paste del show run.
G-SRST#show run
Building configuration...
Current configuration : 2798 bytes
!
version 15.1
service config
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname G-SRST
!
boot-start-marker
boot-end-marker
!
!
enable password cisco
!
no aaa new-model
dot11 syslog
ip source-route
!
!
!
!
!
ip cef
no ip domain lookup
ip name-server 192.168.47.1
ip name-server 8.8.8.8
no ipv6 cef
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
voice translation-rule 1
rule 1 // //
!
!
voice-card 0
!
crypto pki token default removal timeout 0
!
!
!
!
license udi pid CISCO2801 sn FHK1146F03J
!
!
!
!
!
!
!
interface Loopback0
no ip address
!
interface FastEthernet0/0
ip address 192.168.47.219 255.255.255.0
duplex auto
speed auto
h323-gateway voip interface
h323-gateway voip bind srcaddr 192.168.47.219
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 0.0.0.0 0.0.0.0 192.168.47.1
!
!
!
!
control-plane
!
!
voice-port 0/0/0
cptone CL
connection plar opx 2001
description PSTN-FXO
!
voice-port 0/0/1
!
voice-port 0/0/2
!
voice-port 0/0/3
!
!
!
mgcp profile default
!
!
dial-peer voice 2 voip
destination-pattern 2...
session target ipv4:192.168.47.223
!
dial-peer voice 1 pots
description CallSalidas
destination-pattern 9.[4-9]......
port 0/0/0
!
dial-peer voice 3 voip
destination-pattern 2001
codec g711ulaw
!
!
!
telephony-service
srst mode auto-provision all
srst ephone template 1
srst ephone description Telefonia caida : Nov 14 2013 21:00:36
srst dn template 1
max-ephones 5
max-dn 10
ip source-address 192.168.47.219 port 2000
system message Telefonia en Contingencia
time-zone 8
max-conferences 4 gain -6
transfer-system full-consult
create cnf-files version-stamp Jan 01 2002 00:00:00
!
!
ephone-dn-template 1
!
!
ephone-template 1
keepalive 20
codec g729r8
!
!
ephone-dn 1
number 2001
label 2001
description 2001
name 2001
ephone-dn-template 1
!
!
ephone-dn 2
number 2002
label 2002
description 2002
name 2002
ephone-dn-template 1
!
!
ephone-dn 3
number 2003
label 2003
description 2003
name 2003
ephone-dn-template 1
!
!
ephone 1
description Telefonia caida : Nov 14 2013 21:00:36
mac-address 1C75.0858.6777
ephone-template 1
codec g729r8
button 1:1
!
!
!
ephone 2
description Telefonia caida : Nov 14 2013 21:00:36
mac-address 1230.9011.0011
ephone-template 1
codec g729r8
button 1:2
!
!
!
ephone 3
description Telefonia caida : Nov 14 2013 21:00:36
mac-address 4055.39AD.0E9E
ephone-template 1
codec g729r8
button 1:3
!
!
!
ephone 4
description Telefonia caida : Nov 14 2013 21:00:36
codec g729r8
!
!
!
!
line con 0
line aux 0
line vty 0 4
password cisco
login
transport input all
!
scheduler allocate 20000 1000
end
G-SRST#
el 11-19-2013 01:03 PM
Hola Leonardo,
Parece que tu SRST está guardando la configuración de los DNs. Esto puede ser problemático a la hora del enrutamiento, pues las llamadas a la 2001 pueden estar haciendo "match" con algún dial-peer oculto del SRST. Mi recomendación es no utilizar mode auto-provision all. Sin embargo, si lo requieres, te recomiendo la sgte modificación:
# El valor "2" en el comando de abajo le indica al router que enrute las llamadas basado en la preferencia de los dial-peers. Mientras más baja la preferencia del dial-peer, mayor prioridad de escogencia tiene. Por defecto, los dialpeers que no tienen una preferencia explícitamente configurada, tienen un valor de 0.
dial-peer hunt 2
!
telephony-service
max-dn 10 preference 1 <--- Esto le configura a los dial-peers ocultos del SRST, una preferencia 1.
La configuración anterior le permite al router mandar la llamada por el dial-peer 2 VoIP (debido a que la preferencia que tiene es 0), por lo tanto cuando el CUCM está alcanzable la llamada siempre llegará al teléfono IP en el CUCM.
Cuando el router entra en modo SRST, el router enviará la llamada al CUCM (debido a que el dial-peer 2 tiene mayor preferencia), pero, como el CUCM no está alcanzable en ese momento, el router buscará otro dial-peer de mayor preferencia como respaldo para enrutar la llamada, es decir, va a utilizar el dial-peer oculto del SRST (que ahora tiene preferencia 1). En ese momento la llamada debería timbrar en el teléfono IP registrado al SRST.
Nota:
Revisa en tu CUCM si el gw de voz tiene el calling search space correcto que contenga la partición donde reside la extensión 2001.
Prueba y me avisas por favor.
Saludos,
- Adrián.
el 11-20-2013 08:10 AM
Hola Adrían.
Realizé los pasos que indicaste. Pero sigo con el problema. Las llamadas salientes funcionan ya sea desde el CUCM o en modo srst del gateway por el puerto FXO, pero las entrantes no. ya sea desde el cucm o desde el gateway modo SRST.
¿Será porque estoy usando con conversor GSM (conversor celular) para las llamadas?
Saludos cordiales.
el 11-20-2013 08:29 AM
Hola,
Realiza una llamada entrante y capturas unos debugs en el router:
debug voip ccapi inout
debug dial-peer all
debug vpm all (creo que el router te va a decir que ahora es otro comando)
Saludos,
- Adrian.
el 11-20-2013 10:06 AM
Hola Adrián.
Realizé los comandos,;
debug voip ccapi inout
debug dial-peer all ---> debug voip dialpeer all
debug vpm all
Hice una llamada pero no capturo nada. Alcanza a dar un tono y se corta. Realizé una llamada hacia el exterior para comprobar que el debug ( y el terminal monitor) funcionase y se funciona, captura detalles, pero para llamadas entrantes no captura debug.
Saludos cordiales.
el 11-20-2013 10:11 AM
Hola,
Al voice port quítale el connection plar opx 2001 y el cptone, y déjalo configurado sólo con el comando connection plar 2001. Si el problema persiste, prueba cambiar la troncal en otro voice port del router.
Saludos.
el 11-20-2013 10:22 AM
Realizé las pruebas, en todos los voice-port agregue solamente el connection plar 2001, pero en todos los puertos fxo el mismo problema.
Saludos.
el 11-20-2013 10:31 AM
Ok, tratemos de cambiar la señalización. Trata de poner en el voice-port el comando signal groundStart.
Saludos.
el 11-20-2013 10:37 AM
Hola Adrián;
Gracias por tu respuesta. Sigo sin solucionarlo.
Me faltará algo en el dial-pattern? el translation-rule es necesario? Cuales debería ser los comando necesarios para que funcionase una llamada entrante en un puerto FXO.
saludos cordiales.
el 11-20-2013 10:48 AM
Añade el comando no battery-reversal al voice-port.
Lo necesario es tener el connetion plar y el dialpeer voip apuntando a la IP del CUCM. En el CUCM, tener definido el GW como H.323 y asignarle a este un calling search space que contenga la partición donde reside la extensión 2001.
Saludos.
el 11-20-2013 02:12 PM
Hola Adrián;
En el CUCM esta configurado de esa manera.
Puede ser que el conversor celular que estoy usando no reciba llamados?
Saludos
el 11-20-2013 02:43 PM
Podrías validar esa parte.
Lo que me quedaría por decirte que probaras es tal vez un upgrade de IOS o abrir un caso a Cisco TAC para ver si la tarjeta presenta algo anómalo.
Saludos.
el 11-20-2013 03:01 PM
Hola Leonardo,
Espero te encuentres bien. Si sería bueno colectar los debugs señalados por Adrián. ¿Podrías ingresar a configure terminal desde el voice gateway y ejecutar el comando logging monitor, das enter y luego logging console y enter de nuevo?
Una vez esto hecho, corre los debugs nuevamente y dejanos saber si esta vez si se despliega el output de los debugs.
Los debugs necesitados son:
debug voip ccapi inout
debug dial-peer all
debug vpm all
Saludos,
Felipe Segnini
¡Conecte con otros expertos de Cisco y del mundo! Encuentre soluciones a sus problemas técnicos o comerciales, y aprenda compartiendo experiencias.
Queremos que su experiencia sea grata, le compartimos algunos links que le ayudarán a familiarizarse con la Comunidad de Cisco:
Navegue y encuentre contenido personalizado de la comunidad