WebEx : Cisco TelePresence MCU 4203

Mis llamadas que implican un TANDBERG Codian MCU, IP GW, IP VCR, ISDN GW, el servidor del TelePresence, VCS, el TCS o la desconexión del punto final inesperado después de un a plazo fijo del tiempo

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Preguntas


Introducción

Este artículo se relaciona con el IP VCR 2210 del Cisco TelePresence MCU 4203, del Cisco TelePresence MCU MSE 8420, del Cisco TelePresence, los Productos IP GW 3510 del Cisco TelePresence VCR MSE 8220, del Cisco TelePresence ISDN GW 3241, del Cisco TelePresence ISDN GW MSE 8321, del Cisco TelePresence, del Cisco TelePresence MCU 4505 y del Cisco TelePresence MCU MSE 8510.

Q. Mis llamadas que implican un TANDBERG Codian MCU, IP GW, IP VCR, ISDN GW, el servidor del TelePresence, VCS, el TCS o la desconexión del punto final inesperado después de un a plazo fijo del tiempo

A. Este FAQ está bajo revisión

Los Productos siguientes no imponen los límites de la Duración de la llamada:

  • Servidores del TelePresence TANDBERG

  • TANDBERG Codian MCU

  • Gatewayes IP TANDBERG Codian

  • IP VCR TANDBERG Codian

Muchos gatewayes ISDN incluyendo el TANDBERG Codian ISDN GW tienen un tiempo máximo configurable en la llamada que se puede encontrar en las configuraciones > el ISDN

La mayoría de los porteros incluyendo el portero TANDBERG VCS y TANDBERG pueden ser configurados para dar un plazo de una Duración de la llamada máxima.

Mientras que estos límites están de valor en la prevención de los costes involuntarios cuando un usuario no puede desconectar su llamada correctamente, pueden causar los problemas desconexión de la frustración.

Además, muchos Firewall comunes imponen un límite el la Duración de la llamada por abandono. Las configuraciones unidas mal del acceso de Ethernet pueden causar la alta pérdida del paquete, dando por resultado las llamadas que son caídas.

Si usted encuentra que las llamadas a o desde cierta desconexión del punto final siempre después de una determinada cantidad de hora, investigan el siguiente:

  1. Límites de la duración impuestos por cualquier porteros implicados en una llamada. El punto final y la unidad se podían registrar con diversos porteros; incluso si la llamada está siendo marcada por la dirección IP, bastante que por el número E.164, los porteros podrían todavía estar implicados en configurar y derribar la llamada.

  2. Límites de la duración aplicados a las conexiones de red por los Firewall. Por ejemplo, un Cisco PIX Firewall puede tener un comando timeout del h323 2:00:00(i.e del h225 1:00:00 UDP 0:02:00 de la conexión de tiempo de espera 1:00:00 de la forma una lista de Nombres del protocolo reconocidos que cada uno siguió por un descanso en las horas, de minutos y de segundos). Este ejemplo impone un límite de dos horas ante las conexiones de H.323; sin embargo, también impone los límites ante otros protocolos que también afectarían a una llamada video (UDP y H225). Muchos diversos Network Protocol están implicados en una llamada video IP. Un descanso aplicado a ningunos de ellos podía dar lugar a la llamada que era derribada.

  3. Los descansos se aplicaron en otros puntos finales y MCU - por ejemplo, la configuración de MaxTimeInCall en el Polycom MGC.

  4. Configuraciones del puerto de un switch de Ethernet unidas mal. Cuando no hay modelo a los tiempos después de lo cual a la desconexión de las llamadas, y los motivos de desconexión en el registro de acontecimientos incluyen 'H.245 la conexión de red Error, es posible que las configuraciones del acceso de Ethernet de su producto de Codian no hacen juego los del Switch que está conectado en. Es muy importante que las configuraciones del acceso de Ethernet en su producto de Codian hacen juego ésos en su Switch. Cuando se unen mal las configuraciones, la pérdida del paquete puede ocurrir, y cuando la pérdida del paquete excede cierto nivel, llama entre su MCU y sus puntos finales puede ser caído. Si un lado se fija para la negociación automática, el otro lado se debe fijar para la negociación automática (el “auto” se debe utilizar siempre para Gigabit Ethernet). Si un lado es cableado por hardware a cierto valor (por ejemplo, Full-duplex del 100 Mbps) el otro lado se debe fijar lo mismo. Si fijan a los ambos lados para la negociación automática pero todavía están ocurriendo las desconexiones al azar, es ambos lados buenos de un duro-alambre del paso de Troubleshooting al Full-duplex del 100 Mbps. Esto eliminará los problemas de negociación automática como la fuente de sus problemas.

De todo el éstos, los descansos del Firewall son probablemente los más duros de resolver problemas, porque usted no puede necesariamente ser consciente de la existencia del Firewall, e incluso si usted es, su configuración no es probable ser fácilmente accesible.


Información Relacionada


Document ID: 112275