El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe las técnicas y comandos básicos para resolver problemas y depurar redes VoIP.
Cisco recomienda que tenga conocimiento sobre estos temas:
Configuración de VoIP
QoS de voz
Diseño e implementación de redes VoIP
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware. No obstante, los resultados mostrados se basan en Cisco IOS® versión 12.3(8).
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
En este documento se muestran técnicas y comandos básicos de Troubleshooting y debug de redes VoIP. Se incluye una introducción a la arquitectura de telefonía y flujo de llamadas de voz en un router Cisco, seguida de un enfoque de Troubleshooting de VoIP paso a paso presentado en los pasos siguientes:
Verificar los dígitos recibidos y enviados desde puertos de voz analógicos y digitales
Comprender los problemas de calidad de servicio (QoS) de VoIP
Comprender los detalles de códigos de causas y valores de depuración de VoIP
Nota: Este documento no explica todas las facetas de la arquitectura de Cisco IOS utilizada en gateways y gatekeepers de Cisco VoIP. sino que tiene como objetivo mostrar qué comandos se pueden utilizar y qué campos de los resultados de los comandos son más valiosos.
Precaución: es intensivo para el procesador depurar Cisco IOS. Sea precavido a la hora de utilizar las depuraciones indicadas en este documento. Para obtener más información, consulte Información importante sobre comandos de depuración.
Las depuraciones deben ejecutarse con la indicación de fecha y hora en el registro. Habilite la marca de tiempo con los comandos: service timestamps debug datetime msec, service timestampslog datetime msec en el modo de habilitación. Las indicaciones de fecha y hora ayudan a determinar el intervalo de tiempo entre cambios de estado.
Un factor importante que hay que tener en cuenta antes de empezar a solucionar problemas de VoIP o a depurar VoIP es que las llamadas VoIP están compuestas por tres tramos de llamada. Dichos tramos de llamada son los sistemas telefónicos convencionales de origen (POTS), VoIP y POTS de destino. Esto se ilustra en el diagrama siguiente: La resolución de problemas y la depuración primero tienen que centrarse independientemente en cada tramo y luego en la llamada VoIP en general.
Las definiciones siguientes explican la función de los principales componentes que se muestran en el diagrama de flujo de la llamada del router:
API de control de llamadas (interfaz de programación de aplicaciones): Tres clientes utilizan la API de control de llamadas. Los tres clientes son: la CLI, el agente del protocolo de administración de red simple (SNMP) y la aplicación de sesión. Las funciones principales de la API de control de llamadas (también denominada CCAPI) son las siguientes:
Identifique los tramos de llamada (por ejemplo, ¿de qué par de marcado se trata? ¿de dónde procede?).
Decidir qué aplicación de sesión acepta la llamada (por ejemplo, ¿quién la maneja?).
Invocar el administrador del paquete.
Poner juntos en conferencia los tramos de llamada.
Empezar a registrar las estadísticas de llamadas.
Aplicación de sesión y mapeador del plan de marcado: La aplicación de sesión utiliza el mapeador del plan de marcado para asociar un número a un par de marcado (POTS local o VoIP remoto) El Mapeador del plan de marcado utiliza la Tabla de par de marcado para buscar pares de marcado activos.
Telephony and VoIP Service Provider Interface (SPI): el SPI de telefonía se comunica con los dial-peers POTS (analógicos: fxs, fxo, e&m Digital: isdn, qsig, e&m, etc.). VoIP SPI es la interfaz específica para los pares de VoIP. Los controladores Telephony/DSP prestan servicios al SPI de telefonía mientras el SPI de VoIP cuenta con los protocolos de sesión.
Este diagrama muestra la arquitectura de los bloques de construcción del router de Cisco Telephony y cómo interactúan entre sí.
La lista siguiente describe las funciones y definiciones de los principales componentes del diagrama:
Interfaz de programación de aplicaciones de control de llamadas (CCAPI) — Entidad de software que establece, finaliza y conecta en puente los segmentos de llamada.
Proveedor de servicios de telefonía de voz (VTSP): proceso de Cisco IOS que atiende las solicitudes de la API de control de llamadas y formula las solicitudes adecuadas al procesador de señales digitales (DSP) o al VPM.
Módulo del procesador de voz (VPM): — El VPM se encarga de conectar en puente y coordinar los procesos de señalización entre la máquina de estado de señalización (SSM) de los puertos de telefonía, el administrador de recursos de DSP y el VTSP.
Administrador de recursos de DSP — El DSPRM proporciona interfaces a través de las cuales el VTSP puede enviar mensajes a los DSP y recibir mensajes de éstos.
Administrador de paquetes — El administrador de paquetes reenvía paquetes entre los DSP y los segmentos de llamadas de pares.
Par de llamada — El par de llamada es el segmento de llamada opuesto. Puede tratarse de otra conexión de voz de telefonía (POTS), VoFR, VoATM o una conexión VoIP.
La verificación de la señalización digital y analógica es para:
Determinar que se reciba la señalización digital o analógica activada o desactivada adecuada.
Determinar que esté configurada la señalización E&M, FXO y FXS apropiada en ambos lados del router y del switch (CO o PBX).
Verifique que los DSP estén en el modo de recolección de dígitos.
Los comandos indicados en estas secciones se pueden utilizar para verificar la señalización.
show controllers t1 [slot/port] — Utilice este comando primero. Muestra si la conexión T1 digital entre el router y el switch (CO o PBX) está activada o desactivada y si funciona correctamente. El resultado de este comando es como se indica a continuación:
router# show controllers T1 1/0 T1 1/0 is up. Applique type is Channelized T1 Cablelength is short 133 No alarms detected. Framing is ESF, Line Code is B8ZS, Clock Source is Line Primary. Data in current interval (6 seconds elapsed): 0 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs |
Si utiliza E1, utilice el comando show controllers e1. Para obtener más información, consulte:
show voice port slot-number/port: utilice este comando para visualizar el estado del puerto y los parámetros configurados en el puerto de voz de las tarjetas de interfaz de voz (VIC) de Cisco. Al igual que todos los comandos de Cisco IOS, los valores predeterminados no se muestran en show running-config , pero sí se muestran con este comando.
A continuación, mostramos un resultado de ejemplo de un puerto de voz E&M:
router# show voice port 1/0:1 recEive and transMit Slot is 1, Sub-unit is 0, Port is 1 Type of VoicePort is E&M Operation State is DORMANT Administrative State is UP No Interface Down Failure Description is not set Noise Regeneration is enabled Non Linear Processing is enabled Music On Hold Threshold is Set to -38 dBm In Gain is Set to 0 dB Out Attenuation is Set to 0 dB Echo Cancellation is enabled Echo Cancel Coverage is set to 16 ms Connection Mode is normal Connection Number is not set Initial Time Out is set to 10 s Interdigit Time Out is set to 10 s Call-Disconnect Time Out is set to 60 s Region Tone is set for US Voice card specific Info Follows: Out Attenuation is Set to 0 dB Echo Cancellation is enabled Echo Cancel Coverage is set to 16 ms Connection Mode is normal (could be trunk or plar) Connection Number is not set Initial Time Out is set to 10 s Interdigit Time Out is set to 10 s Call-Disconnect Time Out is set to 60 s Region Tone is set for US Voice card specific Info Follows: Signal Type is wink-start Operation Type is 2-wire E&M Type is 1 Dial Type is dtmf In Seizure is inactive Out Seizure is inactive Digit Duration Timing is set to 100 ms InterDigit Duration Timing is set to 100 ms Pulse Rate Timing is set to 10 pulses/second InterDigit Pulse Duration Timing is set to 500 ms Clear Wait Duration Timing is set to 400 ms Wink Wait Duration Timing is set to 200 ms Wink Duration Timing is set to 200 ms Delay Start Timing is set to 300 ms Delay Duration Timing is set to 2000 ms Dial Pulse Min. Delay is set to 140 ms |
Los comandos siguientes se utilizan para depurar la interfaz de telefonía VPM:
debug vpm signal: este comando se utiliza para recopilar información de depuración para los eventos de señalización y puede ser útil para resolver problemas con la señalización a un PBX.
debug vpm spi — Este comando hace un seguimiento del modo en que la interfaz del proveedor de servicios (SPI) del módulo del puerto de voz interactúa con la API de control de llamadas. Este comando depurador muestra información sobre cómo es manejada cada indicación de red y petición de aplicación.
debug vpm dsp — Este comando muestra mensajes del DSP, en el VPM, al router. Además, puede ser útil si sospecha que el VPM no es funcional. Es una forma sencilla de comprobar si el VPM responde a las indicaciones de descolgar y para evaluar el tiempo de los mensajes de señalización desde la interfaz.
debug vpm all: este comando EXEC habilita todos los comandos debug vpm: debug vpm spi, debug vpm signal y debug vpm dsp.
debug vpm port — Este comando sirve para limitar el resultado de la depuración a un puerto concreto. Por ejemplo, este resultado muestra debug vpm dspmessages solamente para el puerto 1/0/0:
debug vpm dsp debug vpm port 1/0/0
Ejemplo de resultado para debug vpm signalCommand
maui-voip-austin#debug vpm signal !--- FXS port 1/0/0 goes from the "on-hook" to "off-hook" !--- state. htsp_process_event: [1/0/0, 1.2 , 36] fxsls_onhook_offhook htsp_setup_ind *Mar 10 16:08:55.958: htsp_process_event: [1/0/0, 1.3 , 8] !--- Sends ringing alert to the called phone. *Mar 10 16:09:02.410: htsp_process_event: [1/0/0, 1.3 , 10] htsp_alert_notify *Mar 10 16:09:03.378: htsp_process_event: [1/0/0, 1.3 , 11] !--- End of phone call, port goes "on-hook". *Mar 10 16:09:11.966: htsp_process_event: [1/0/0, 1.3 , 6] *Mar 10 16:09:17.218: htsp_process_event: [1/0/0, 1.3 , 28] fxsls_offhook_onhook *Mar 10 16:09:17.370: htsp_process_event: [1/0/0, 1.3 , 41] fxsls_offhook_timer *Mar 10 16:09:17.382: htsp_process_event: [1/0/0, 1.2 , 7] fxsls_onhook_release |
Si el estado desactivado y activado no señalizan correctamente, compruebe los elementos siguientes:
Verifique que el cableado sea correcto.
Verifique que tanto el router como el switch (CO o PBX) estén correctamente conectados a tierra.
Verifique que ambos extremos de la conexión tengan configuraciones de señalización equivalentes. Las configuraciones que no sean coincidentes pueden producir una señalización incompleta o unidireccional.
Para obtener más información acerca de la resolución de problemas E&M, consulte Comprensión y solución de problemas de tipos de interfaces E&M analógicas y disposición del cableado.
Ejemplo de resultado para debug vpm spiCommand
maui-voip-austin#debug vpm spi Voice Port Module Session debugging is enabled !--- The DSP is put into digit collection mode. *Mar 10 16:48:55.710: dsp_digit_collect_on: [1/0/0] packet_len=20 channel_id=128 packet_id=35 min_inter_delay=290 max_inter_delay=3200 mim_make_time=18 max_make _time=75 min_brake_time=18 max_brake_time=75 |
Una vez que se haya verificado la señalización del estado desactivado y el estado activado (off-hook y on-hook) y se sabe que éstos funcionan correctamente, verifique que se hayan recibido o enviado los dígitos correctos en el puerto de voz (digital o analógico). No se podrá asociar un par de marcado o un switch (CO o PBX) no podrá llamar a la estación correcta si se envían o reciben dígitos incorrectos. Algunos comandos que se pueden utilizar para verificar los dígitos recibidos/enviados son:
show dialplan number — Este comando se utiliza para mostrar qué par de marcado se alcanza al marcar un número de teléfono concreto.
debug vtsp session — Este comando muestra información acerca de cómo se procesa cada aplicación e indicación de red, las indicaciones de señalización y los mensajes de control de DSP.
debug vtsp dsp — En las versiones anteriores a la versión del software Cisco IOS 12.3, este comando mostraba los dígitos a medida que el puerto de voz los recibía. No obstante, en la versión del software Cisco IOS 12.3 y posteriores, el resultado del comando debug ya no muestra los dígitos. La combinación de debug hpi detail y debug hpinotification se puede utilizar para ver los dígitos entrantes.
debug vtsp all: este comando habilita estos comandos debug voice telephony service provider (VTSP): debug vtsp session, debug vtsp error y debug vtsp dsp.
show dialplan number <digit_string> — Este comando muestra el par de marcado que una cadena de dígitos asocia. Si se pueden asociar varios pares de marcado, se mostrarán todos en el orden en el que se asocian.
Nota: Debe utilizar el signo # al final de los números de teléfono de los pares de marcado con una longitud variable, a fin de asociar los patrones de destino que terminan con una T.
El resultado de este comando es como se indica a continuación:
maui-voip-austin#show dialplan number 5000 Dial string terminator: # Macro Exp.: 5000 VoiceOverIpPeer2 information type = voice, tag = 2, destination-pattern = `5000', answer-address = `', preference=0, group = 2, Admin state is up, Operation state is up, incoming called-number = `', connections/maximum = 0/unlimited, application associated: type = voip, session-target = `ipv4:192.168.10.2', technology prefix: ip precedence = 5, UDP checksum = disabled, session-protocol = cisco, req-qos = best-effort, acc-qos = best-effort, dtmf-relay = cisco-rtp, fax-rate = voice, payload size = 20 bytes codec = g729r8, payload size = 20 bytes, Expect factor = 10, Icpif = 30, signaling-type = cas, VAD = enabled, Poor QOV Trap = disabled, Connect Time = 25630, Charged Units = 0, Successful Calls = 25, Failed Calls = 0, Accepted Calls = 25, Refused Calls = 0, Last Disconnect Cause is "10 ", Last Disconnect Text is "normal call clearing.", Last Setup Time = 84427934. Matched: 5000 Digits: 4 Target: ipv4:192.168.10.2 |
El comando debug vtsp session muestra información sobre cómo el router interactúa con el DSP basándose en las indicaciones de señalización de la pila de señalización y las solicitudes de la aplicación. El comando debug muestra información acerca de cómo se manejan las solicitudes de aplicación y de indicación de red, las indicaciones de señalización y los mensajes de control de DSP.
maui-voip-austin#debug vtsp session Voice telephony call control session debugging is on !--- Output is suppressed. |
Si se determina que los dígitos no se envían o reciben correctamente, entonces posiblemente puede ser necesario utilizar un capturador de dígitos (herramienta de prueba) o un probador T1 para verificar que los dígitos se envían con la frecuencia y el intervalo de tiempo correctos. Si se envían "incorrectamente" para el switch (CO o PBX), es posible que sea necesario ajustar algunos valores del router o switch (CO o PBX) para que coincidan y puedan interoperar. En general, estos son valores de duración de dígitos y de duración de interdígitos. Otro elemento que debe examinarse si parece que los dígitos se envían correctamente son las tablas de traducción del switch (CO o PBX) que pueden agregar o eliminar dígitos.
Después de verificar que la señalización del puerto de voz funciona correctamente y que se reciben los dígitos correctos, pase a la resolución de problemas y depuración del control de llamadas de VoIP. Los factores siguientes explican por qué la depuración del control de llamadas puede convertirse en una tarea compleja:
Los gateways VoIP de Cisco utilizan la señalización H.323 para realizar llamadas. H.323 se compone de tres capas de negociación y establecimiento de llamadas: H.225, H.245 y H.323. Estos protocolos utilizan una combinación de TCP y UDP para configurar y establecer una llamada.
La depuración VoIP de extremo a extremo muestra varias máquinas de estado de Cisco IOS. Si se producen problemas con alguna máquina de estado, una llamada puede fallar.
La depuración VoIP de extremo a extremo puede ser muy verbosa y crear un resultado de depuración de gran volumen.
El principal comando de depuración de llamadas VoIP de extremo a extremo es debug voip ccapi inout. A continuación, mostramos el resultado de una depuración de llamada.
!--- Action: A VoIP call is originated through the |
Si la llamada falla y la causa parece estar en la parte de VoIP de la configuración de la llamada, posiblemente necesite observar la parte de TCP H.225 o H.245 de la configuración de la llamada, en lugar de solo la parte de UDP de la configuración H.323. Los comandos que pueden usarse para depurar la configuración de llamada H.225 o H.245 son:
debug ip tcp transactions and debug ip tcp packet — Estos comandos examinan la parte de TCP de la negociación de H.225 y H.245. Devuelven las direcciones IP, los puertos TCP y los estados de las conexiones TCP.
debug cch323 h225 — Este comando examina la parte de H.225 de la negociación de la llamada y rastrea la transición de estado de la máquina de estado H.225 en función del evento procesado. Considérelo como la parte de la capa 1 de la configuración de llamada H.323 de tres partes.
debug cch323 h245 — Este comando examina la parte de H.245 de la negociación de la llamada y rastrea la transición de estado de la máquina de estado H.245 en función de los eventos procesados. Considérelo como la parte de la capa 2 de la configuración de la llamada H.323 de tres partes.
Cuando las llamadas VolP se establecen adecuadamente, el paso siguiente consiste en verificar que la calidad de voz sea buena. Aunque en este documento no se cubre la resolución de problemas de QoS, tenga en cuenta las directrices que exponemos a continuación para conseguir una buena calidad de voz:
Comprenda cuánto ancho de banda consume una llamada VoIP con cada códec. Esto incluye la capa 2 y los encabezados IP/UDP/RTP. Para obtener más información, consulte Modificación del cálculo del consumo de ancho de banda para llamadas de voz.
Comprenda las características de la red IP sobre la que viajan las llamadas. Por ejemplo, el ancho de banda de una red de retransmisión de tramas en CIR es muy diferente del que está por encima de CIR (o ráfaga), en el que los paquetes se pueden abandonar o poner en cola en la nube de Frame Relay. Asegúrese de que el retraso y las fluctuaciones estén controlados y eliminados en lo máximo posible. La demora de transmisión unidireccional no debe superar los 150 ms (según la recomendación de G.114).
Utilice una técnica de envío a cola que permita identificar y priorizar el tráfico VoIP.
Cuando transmite VoIP a través de links de baja velocidad, utilice técnicas de fragmentación de paquetes de Capa 2, como MLPPP con fragmentación e intercalación de enlaces (LFI) en links punto a punto, o FRF.12 en links Frame Relay. La fragmentación de paquetes de datos más grandes permite una menor fluctuación y menos retraso en la transmisión de tráfico VoIP debido a que los paquetes VoIP pueden ser entrelazados en el link.
Pruebe con otro códec e intente llamar con VAD habilitado e inhabilitado para en lo posible acotar el problema al DSP, en contraposición con la red IP.
En la resolución de problemas de la Calidad de servicio (QoS), deben tenerse en cuenta principalmente los paquetes descartados y los embotellamientos de red que pueden causar retrasos e inestabilidad.
Busque:
caídas de la interfaz
caídas del búfer
congestión de la interfaz
congestión de link
Debe examinar cada interfaz del trayecto de la llamada VoIP. Asimismo, elimine los paquetes abandonados y la congestión. Además, el retraso de ida y vuelta debe reducirse lo máximo posible. Los pings entre los puntos finales de VoIP proporcionan una indicación del retraso de ida y vuelta de un enlace. Siempre que sea posible, la demora de ida y vuelta no debe superar los 300 ms. Si es preciso que el retraso supere este valor, deberán realizarse esfuerzos para asegurarse de que dicho retraso sea constante, de modo que no se introduzca ninguna fluctuación ni retraso variable.
También se debe realizar una verificación para garantizar que el mecanismo de cola del IOS de Cisco coloque los paquetes VoIP dentro de las colas adecuadas. Los comandos de Cisco IOS, como show queue interface o show priority pueden ayudar en la verificación de la colocación en cola.
Use estas tablas cuando lea las depuraciones y los valores asociados de las depuraciones.
Valor de la causa de desconexión de la llamada (en hex) | Significado y número (en decimales) |
---|---|
CC_CAUSE_UANUM = 0x1 | número sin asignar. (1) |
CC_CAUSE_NO_ROUTE = 0x3 | no hay ruta para el destino. (3) |
CC_CAUSE_NORM = 0x10 | verificación normal de llamadas. apartado |
CC_CAUSE_BUSY = 0x11 | usuario ocupado. (17) |
CC_CAUSE_NORS = 0x12 | sin respuesta del usuario. (18) |
CC_CAUSE_NOAN = 0x13 | sin respuesta del usuario. (19) |
CC_CAUSE_REJECT = 0x15 | llamada rechazada. 210 |
CC_CAUSE_INVALID_NUMBER = 0x1C | número no válido 28 |
CC_CAUSE_UNSP = 0x1F | normal, sin especificar. (31) |
CC_CAUSE_NO_CIRCUIT = 0x22 | sin circuito. (34) |
CC_CAUSE_NO_REQ_CIRCUIT = 0x2C | ningún circuito solicitado. (44) |
CC_CAUSE_NO_RESOURCE = 0x2F | sin recursos. (47) 1 |
CC_CAUSE_NOSV = 0x3F | servicio u opción no disponible, o sin especificar (63) |
1Este problema puede ocurrir debido a una discordancia de códec dentro de la configuración de H323, por lo que el primer paso de troubleshooting es codificar los pares de marcado VoIP para utilizar el códec correcto.
Para obtener más información sobre los CÓDEC, consulte Introducción a los Códecs: Complejidad, Soporte de Hardware, MOS y Negociación.
Valor de negociación | Significado |
---|---|
Códec = 0x00000001 | G711 ULAW 64K PCM |
Códec = 0x00000002 | G711 ALAW 64K PCM |
Códec = 0x00000004 | G729 |
Códec = 0x00000004 | G729IETF |
Códec = 0x00000008 | G729a |
Códec = 0x00000010 | G726r16 |
Códec = 0x00000020 | G726r24 |
Códec = 0x00000040 | G726r32 |
Códec = 0x00000080 | G728 |
Códec = 0x00000100 | G723r63 |
Códec = 0x00000200 | G723r53 |
Códec = 0x00000400 | GSMFR |
Códec = 0x00000800 | G729b |
Códec = 0x00001000 | G729ab |
Códec = 0x00002000 | G723ar63 |
Códec = 0x00004000 | G723ar53 |
Códec = 0x00008000 | CLEAR_CHANNEL |
‘Tipos de tonos’ | Significado |
---|---|
CC_TONE_RINGBACK 0x1 | Tono |
CC_TONE_FAX 0x2 | Tono de fax |
CC_TONE_BUSY 0x4 | Tono de ocupado |
CC_TONE_DIALTONE 0x8 | Tono de marcado |
CC_TONE_OOS 0x10 | Tono de fuera de servicio |
CC_TONE_ADDR_ACK 0x20 | Tono de acuse de recibo de dirección |
CC_TONE_DISCONNECT 0x40 | Tono de desconexión |
CC_TONE_OFF_HOOK_NOTICE 0x80 | Tono que indica que el teléfono está descolgado |
CC_TONE_OFF_HOOK_ALERT 0x100 | Versión más urgente de CC_TONE_OFF_HOOK_NOTICE |
CC_TONE_CUSTOM 0x200 | Tono personalizado: se utiliza cuando se especifica un tono personalizado |
CC_TONE_NULL 0x0 | Tono nulo |
Valores | Significado |
---|---|
CC_CAP_FAX_NONE 0x1 | Inhabilita fax o no está disponible |
CC_CAP_FAX_VOICE 0x2 | Llamado de voz |
CC_CAP_FAX_144 0x4 | 14.400 baudios |
CC_CAP_FAX_96 0x8 | 9.600 baudios |
CC_CAP_FAX_72 0x10 | 7.200 baudios |
CC_CAP_FAX_48 0x20 | 4,800 baudios |
CC_CAP_FAX_24 0x40 | 2.400 baudios |
CC_CAP_VAD_OFF 0x1 | VAD desactivado |
CC_CAP_VAD_ON 0x2 | VAD habilitado |
Revisión | Fecha de publicación | Comentarios |
---|---|---|
2.0 |
20-Apr-2023 |
Actualice el formato. Alertas de CCW corregidas. Recertificación. |
1.0 |
11-Dec-2001 |
Versión inicial |