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).
El propósito de este documento es proporcionar una explicación detallada de los tonos de repliegue de audio a los que normalmente se hace referencia como tonos de progreso de llamada o tonos de CP para abreviar.
Este documento intentará discutir y proporcionar un análisis de cómo funciona la recepción de llamada dentro de todos los protocolos de señalización analógica y voz sobre IP (VoIP).
Si bien no es necesario un requisito formal para leer este documento; se escribió con la esperanza de que el lector ya tenga algún conocimiento práctico de los protocolos de señalización de voz subyacentes que se utilizan para establecer y conectar llamadas telefónicas. A lo largo de este documento se hace referencia a estos protocolos muchas veces.
Protocolos de señalización: Protocolo de inicio de sesión (SIP), H323 (h225 / h245), Protocolo de control de gateway de medios (MGCP), Protocolo de control de cliente ligero (SCCP), ISDN Q931, E1 R2.
Protocolos de medios: protocolo en tiempo real (RTP), códecs de voz y códecs de vídeo.
Tecnologías analógicas: Oreja y Boca (E&M), Suscriptor de Intercambio Externo (FXS), Oficina de Intercambio Externo (FXO) y E1 R2.
La información de este documento se basa en estos programas y hardware:
Gateways Cisco IOS y IOS-XE (2800 / 3800 / 2900 / 3900 / 4300 / 4400 / CSR1000v / ASR100X) que ejecutan cualquier versión de IOS/IOS-XE.
Cisco Unified Communications Manager (CUCM) versiones 9.X y posteriores
Cisco Unity Connection (CUC) versiones 9.x y posteriores
Customer Voice Portal (CVP) versión 9.x y 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. Si su red está activa, asegúrese de comprender el impacto potencial de cualquier comando o configuración.
Rinback no es un protocolo VoIP o analógico, pero está presente en todas las llamadas telefónicas realizadas por teléfonos móviles, líneas fijas, teléfonos de escritorio y clientes de software. Por lo tanto, entender cómo funciona, de dónde procede y cómo resolver problemas de recepción de llamada es una parte importante de una estrategia de herramientas de Ingenieros de colaboración.
El tono de llamada es una secuencia de tonos que se reproduce en la persona que realiza una llamada telefónica y que permite al autor de la llamada saber que la persona a la que se llama está sonando. La ausencia de tono de llamada se debe considerar un signo negativo, ya que el autor de la llamada supondría que la persona a la que se llama no está sonando. Los tonos de recepción de llamada/CP varían según el país. Si una persona a la que llamar a un número de Estados Unidos, se reproduciría un conjunto diferente de timbre que si esa misma persona llamara a un número del Reino Unido.
En la mayoría de los escenarios, la parte llamada remota de la parte que llama reproducirá la llamada. Para que esto ocurra, se debe cortar el audio en la dirección hacia atrás (Llamado a llamada).
Este documento examina los diferentes protocolos y cómo negocian la recepción de llamada, así como cómo manipular la devolución de llamada cuando se usa ese protocolo.
ISDN Q.931 utilizó el concepto de indicadores de progreso (PI) que se puede ver en la señalización Q.931. Esto se puede ver en los gateways de voz de Cisco ejecutando debug isdn q931. Los indicadores de progreso se pueden enviar en los mensajes Alerta, Progreso, Procedimientos de llamada, Configuración Ack y Desconexión. Un valor del indicador de progreso de 1 u 8 recortará el audio hacia atrás para la recepción de llamada y los mensajes de error. Los valores de los indicadores de progreso 0, 2 y 3 no recortarán los medios hacia atrás. Un DSP asignado al canal ISDN puede reproducir el tono de llamada a la línea ISDN si la parte llamada remota no puede hacerlo.
Advertencias conocidas con ISDN Ringback
Indicadores de progreso Q931
Valor | Definición | Mensaje Q.931 |
Indicador de progreso = 0 | fuera de banda | Configuración |
Indicador de progreso = 1 | La llamada no es ISDN de extremo a extremo. Puede haber más información de progreso de llamada dentro de banda | Alerta, conexión, progreso, configuración |
Indicador de progreso = 2 | La dirección de destino no es ISDN. | Alerta, conexión, progreso |
Indicador de progreso = 3 | La dirección de destino no es ISDN. | Configuración |
Indicador de progreso = 8 | Ya está disponible información en banda o un patrón apropiado. | Alerta, conexión, progreso, desconexión |
Ejemplos de Indicadores de Progreso en Banda ISDN Q.931
Jun 22 15:16:36.790: ISDN Se0/2/0:23 Q931: TX -> ALERTING pd = 8 callref = 0x80A3 Progress Ind i = 0x8188 - In-band info or appropriate now available
Nov 28 21:25:41.754: ISDN Se0/1/1:15 Q931: TX -> PROGRESS pd = 8 callref = 0x805C Progress Ind i = 0x8188 - In-band info or appropriate now available
Configuración
La recepción de llamada ISDN funciona de forma fiable de forma predeterminada, por lo que no se requiere ninguna configuración adicional. Sin embargo, existen comandos para cambiar el comportamiento en caso de un requisito de interoperabilidad.
Cambio manual del valor progress_ind.
Notas Importantes:
Sintaxis de comando completo:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-p2.html#wp1001337490
! progress_ind { alert | callproc } { enable pi-number | disable | strip [strip-pi-number] } progress_ind { connect | disconnect | progress | setup } { enable pi-number | disable } ! dial-peer voice 1 pots destination-pattern 8675309$ progress_ind alert enable 8 progress_ind callproc enable 8 progress_ind connect enable 8 progress_ind disconnect enable 8 progress_ind progress enable 8 progress_ind progress setup 1 ! dial-peer voice 2 pots destination-pattern 8675309$ progress_ind alert strip 8 progress_ind callproc strip 8 ! dial-peer voice 3 pots destination-pattern 8675309$ progress_ind alert disable progress_ind callproc disable progress_ind connect disable progress_ind disconnect disable progress_ind progress disable progress_ind progress disable !
Requerir que una puerta de enlace de voz siempre envíe mensajes de alerta
Si un administrador necesita que un gateway de voz envíe siempre un mensaje de alerta antes de conectar, el comando isdn send-alerting se puede configurar en una interfaz serial. Esta opción está desactivada de forma predeterminada
Sintaxis de comando completo: http://www.cisco.com/c/en/us/td/docs/ios/dial/command/reference/dia-cr-book/dia_i2.html
! interface Serial0/0/0:23 isdn send-alerting !
Depuraciones
debug isdn q931 debug voip ccapi inout
H.323 y más específicamente el protocolo de señalización H.225 VOIP se construyó sobre el protocolo Q.931 de ISDN. Como resultado, comparten muchos elementos comunes. Muchos de los comandos presentes y las ideas detrás de Q.931 ringback están presentes en H.323/H.225. Esto incluye los valores del indicador de progreso, los tipos de mensaje y los comandos.
Ejemplo de mensaje H.225 para recepción
*Jun 22 11:32:52.080: H225.0 INCOMING PDU ::= value H323_UserInformation ::= { h323-uu-pdu { h323-message-body alerting :
Configuración
H.323 y H.225 no requieren configuración para la devolución de llamada fuera de la caja. Sin embargo, los comandos especificados en la sección ISDN Q.931 también son aplicables al Retorno H.323. Además, hay comandos disponibles para la señalización H.323.
Comando | Definición |
voice call send-alert |
|
voice rtp send-recv | Abre el canal de audio RTP en ambas direcciones. |
! dial-peer voice 1 voip tone ringback alert-no-pi ! dial-peer voice 2 pots tone ringback alert-no-pi ! |
|
Configuraciones de CUCM
Existen algunas configuraciones específicas de H.323 para la recepción de llamada dentro de CUCM>
Navigation Path: CUCM > System > Service Parameters > Pub > CallManager > Send H225 User Info Message > Use ANN For Ringback
Valor | Definición |
Utilizar ANN para devolución de llamada | Utilice Cisco SCCP Annunciator para reproducir el tono de recepción de llamada (disponible en Cisco CallManager versión 4.0 y posteriores) |
Información de usuario para el tono de progreso de llamada | Enviar el mensaje de información del usuario H.225 al gateway IOS para reproducir el tono de recepción de llamada o el tono en espera (este es el valor predeterminado). |
H225 Info for Call Progress Tone (Información de H225 para el tono de progreso de la llamada) | Enviar el mensaje de información H.225 al gateway IOS para reproducir el tono de recepción de llamada o el tono en espera |
Depuraciones
debug voip ccapi inout debug h225 asn1
Este también es un documento excelente sobre la resolución de problemas del retorno de llamada H.323
http://www.cisco.com/c/en/us/support/docs/voice/h323/22983-ringback.html
La recepción de llamada SIP normalmente implica uno de dos mensajes. 180 y 183. RFC 3261 establece que 0, 1 o más de estos mensajes 1XX pueden ser recibidos después de una INVITE, por lo tanto no es contrario a RFC no recibir uno de estos mensajes. Si no se recibe ninguna, no habrá recepción de llamada. Por lo tanto, si una persona que llama espera una devolución de llamada de alguna forma, se requiere un 180 o 183.
Tanto un 180 como un 183 pueden contener el protocolo de descripción de sesión (SDP) que CUBE tratará como medios iniciales. Cuando SDP está presente en un mensaje 18X CUBE y CUCM esperará que el dispositivo de extremo lejano que envía el 18X con SDP reproduzca el timbre desde la IP especificada en el SDP. No hay ninguna configuración para cambiar este comportamiento en CUCM o CUBE. Algunos dispositivos requieren un intercambio PRACK (rel1xx) en el mensaje 18X antes de enviar el timbre.
RFC3960 profundiza en detalles adicionales sobre la señalización de recepción de llamada con SIP.
Es importante tener en cuenta que para SIP a ISDN y SIP a H.323 llama a un 18X con mapas SDP a un Indicador de progreso en banda mientras que un 18X sin SDP mapea a una Alerta.
Ejemplo 183 con SDP
SIP/2.0 183 Session Progress Via: SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bK6350828126b1a From: <sip:8675309@10.10.10.10>;tag=85512413~796a13c3-49d2-74ec-19db-f4258d9eef64-40934478 To: <sip:123456789@10.10.10.1>;tag=BA0FA04C-97B Date: Wed, 22 Jun 2016 11:32:51 GMT Call-ID: 575b0c00-76a177e1-57ea4-2009000a CSeq: 101 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Remote-Party-ID: <sip:8675309@10.10.10.10>;party=called;screen=no;privacy=off Contact: <sip:8675309@10.10.10.10:5060;transport=tcp> Supported: sdp-anat Server: Cisco-SIPGateway/IOS-15.4.3.M2 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 250 v=0 o=CiscoSystemsSIP-GW-UserAgent 9474 3602 IN IP4 172.16.37.129 s=SIP Call c=IN IP4 10.10.10.10 t=0 0 m=audio 17606 RTP/AVP 8 101 c=IN IP4 10.10.10.10 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20
Muestra 180 sin SDP
SIP/2.0 180 Ringing Via: SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bKd34f2a2080 From: <sip:2002@10.10.10.10>;tag=17170~21823a7a-6ec3-4a2f-9307-df98bca4b011-23314477 To: <sip:3001@10.10.10.1> ;tag=1ADFB1AC-3CB Date: Tue, 26 Jan 2016 22:05:06 GMT Call-ID: d859d700-6a71ed8f-26-a21030e CSeq: 102 INVITE Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-event Remote-Party-ID: < sip:3001@10.10.10.10> ;party=called;screen=yes;privacy=off Contact: < sip:3001@10.10.10.10:5060;transport=tcp> Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0
Configuración
Comando | Definición |
! sip-ua disable-Early-Media 180 ! |
Se utiliza para especificar el tratamiento de llamadas, los medios iniciales o el retorno de llamada local, que se proporciona para 180 respuestas con 180 respuestas con protocolo de descripción de sesión (SDP) |
! voice service voip sip bloque {180 | 181 | 183} sdp {presente | ausente} ! |
Bloquea mensajes específicos pertenecientes a la devolución de llamada |
Perfil SIP para cambiar una sesión 183 en curso a un timbre 180.
! voice service voip sip sip-profiles inbound ! voice class sip-profiles 777 response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session Progress" "SIP/2.0 180 Ringing" ! dial-peer voice 777 voip voice-class sip profile 777 inbound !
Habilitación de PRACK (rel1xx) en CUCM.
Ruta del menú del sistema: Device > Device Settings > Sip Profile > Choose a SIP profile > SIP Rel1XX
Opciones
Habilitación de PRACK (rel1xx) en Gateawys
Depuraciones
debug voip ccapi inout debug ccsip messages
MGCP es el lado VOIP que controla los puertos FXS e ISDN T1 / E1. Puede verificar si CUCM está enviando la señalización de recepción de llamada adecuada al puerto específico pero no hay mucha configuración que se pueda hacer.
Ejemplo de mensaje MGCP Ringback de CUCM a un puerto FXS VG224
Apr 29 01:01:38.264: MGCP Packet received from 14.50.244.2:2427---> RQNT 37 AALN/S2/1@vg224 MGCP 0.1 X: 1b R: L/hu S: G/rt Q: process,loop <---
S: = Eventos señalizados y g/rt = Paquete genérico / Tono de recepción de llamada
Configuración de CUCM
Ruta del menú del sistema: System > Service Parameters > Pub > CallManager > Disable Alerting Progress Indicator
Configuración de gateway
Depuraciones
debug mgcp packet
debug voip ccapi nout
debug vpm signal debug voip vtsp session
En el caso de los teléfonos IP SCCP registrados en CUCM o CME, se envía un "mensaje de tono de inicio" al teléfono IP que indica al teléfono local que reproduzca el timbre a la persona que realiza la llamada.
Depuraciones de recepción de llamada para todos los puertos de voz analógicos:
debug voip ccapi inout debug vpm signal debug voip vtsp session
GATEWAY(config)#voice-port 0/2/0 GATEWAY(config-voiceport)#cptone ? locale 2 letter ISO-3166 country code AR Argentina IN India PA Panama AU Australia ID Indonesia PE Peru AT Austria IE Ireland PH Philippines BE Belgium IL Israel PL Poland BR Brazil IT Italy PT Portugal CA Canada JP Japan RU Russian Federation CL Chile JO Jordan SA Saudi Arabia CN China KE Kenya SG Singapore CO Colombia KR Korea Republic SK Slovakia C1 Custom1 KW Kuwait SI Slovenia C2 Custom2 LB Lebanon ZA South Africa CY Cyprus LU Luxembourg ES Spain CZ Czech Republic MY Malaysia SE Sweden DK Denmark MT Malta CH Switzerland EG Egypt MX Mexico TW Taiwan FI Finland NP Nepal TH Thailand FR France NL Netherlands TR Turkey DE Germany NZ New Zealand AE United Arab Emirates GH Ghana NG Nigeria GB United Kingdom GR Greece NO Norway US United States HK Hong Kong OM Oman VE Venezuela HU Hungary PK Pakistan ZW Zimbabwe IS Iceland
Salida de debug ccapi inout, debug vpm signal y debug voip vtsp session para llamadas E1 R2 que muestran el tono de llamada.
042446: May 12 14:51:15.816 GMT: //2475488/47922BA59254/CCAPI/cc_api_call_alert: Interface=0x3ECE2770, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1) 042447: May 12 14:51:15.816 GMT: //2475488/47922BA59254/CCAPI/cc_api_call_alert: Call Entry(Retry Count=0, Responsed=TRUE) 042448: May 12 14:51:15.816 GMT: //2475487/47922BA59254/CCAPI/ccCallAlert: Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1) 042449: May 12 14:51:15.816 GMT: //2475487/47922BA59254/CCAPI/ccCallAlert: Call Entry(Responsed=TRUE, Alert Sent=TRUE)htsp_alert_notify 042450: May 12 14:51:15.816 GMT: r2_reg_event_proc(0/0/1:1(1)) ALERTING RECEIVED 042451: May 12 14:51:15.816 GMT: R2 Incoming Voice(0/1): DSX (E1 0/0/1:0): STATE: R2_IN_WAIT_REMOTE_ALERT R2 Got Event R2_ALERTING 042452: May 12 14:51:15.816 GMT: rx R2_ALERTING in r2_comp_wait_remote_alert 042453: May 12 14:51:15.816 GMT: r2_reg_generate_digits(0/0/1:1(1)): Tx digit '1' 042454: May 12 14:51:16.672 GMT: //2475487/47922BA59254/VTSP:(0/0/1:1):0:1:1/vtsp_report_cas_digit: End Digit=2, Mode=CC_TONE_R2_MF_BACKWARD_MODE 042455: May 12 14:51:16.672 GMT: htsp_digit_ready(0/0/1:1(1)): Rx digit='#'
CVP indicará al gateway VXML que reproduzca la recepción de llamada enviando una INVITE con un número específico.
Ejemplo: 9191
El SDP de esta INVITE estará donde queremos que el gateway VXML envíe la señal de llamada.
Esto coincidirá con un par de marcado configurado con un servicio de recepción de llamada configurado.
El retraso en el corte de recepción de llamada suele deberse a un retraso en la señalización subyacente. Los debugs y los logs del dispositivo específico y los protocolos que se utilizan deberán ser consultados para averiguar por qué hay un retraso en la señalización.
Para la falla de señalización de la gateway de voz en los pares de marcado y la re-búsqueda del par de marcado puede causar un retraso considerable a medida que el dispositivo intenta encontrar un salto siguiente para la llamada.
Como puede ver en todo el documento, la recopilación de depuraciones ccapi es muy importante para CUALQUIER problema de recepción de llamada.
la función Api de control de llamadas (CCAPI) se encarga de conectar en puente dos lados de una llamada en una gateway de voz y, como resultado, de unir también el timbre de un tramo de llamada a otro.
Ejemplos de salida de depuración de CCAPI para recepción de llamada
Feb 2 21:27:18.884: //22/9285F23E801B/CCAPI/cc_api_call_alert: Interface=0x3AB79E8, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
Jun 23 13:32:34 EDT: //1204/77232A800001/CCAPI/cc_api_call_cut_progress: Interface=0x7FD5FD1CEE10, Progress Indication=INBAND(8), Signal Indication=INTERCEPT(2), Cause Value=0 Jun 23 13:32:34 EDT: //1203/77232A800001/CCAPI/ccCallCutProgress: Progress Indication=INBAND(8), Signal Indication=INTERCEPT(2), Cause Value=0 Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE)
Jun 22 11:32:52.096: //204706/575B0C000000/CCAPI/ccCallAlert: Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)
Nov 28 21:25:41.748: //43495/0C82F2F380B7/CCAPI/cc_api_call_cut_progress: Interface=0x7F8028B60F90, Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1), Cause Value=0 Nov 28 21:25:41.749: //43494/0C82F2F380B7/CCAPI/ccCallCutProgress: Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1), Cause Value=0 Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE) Nov 28 21:25:41.749: //43494/0C82F2F380B7/CCAPI/ccGenerateToneInfo: Stop Tone On Digit=FALSE, Tone=Null, Tone Direction=Network, Params=0x0, Call Id=43494
Dependiendo de su señalización, todo puede verse bien. Sin embargo, puede que todavía no haya recepción de llamada. Si la señal indica que una parte específica va a enviar una señal de llamada a su dispositivo, vale la pena capturar una captura de paquetes o una captura PCM del puerto de voz para verificar si la recepción de llamada se está reproduciendo o no.
También es importante verificar el ruteo de Capa 3 desde el origen y el destino. si no pueden enviar paquetes RTP a su dispositivo, no oirá audio. Además, si no puede enviar paquetes a un dispositivo específico, no oirán su recepción de llamada.
Comandos de ruteo útiles de capa 3
show ip route show ip cef <remote_ip> ping a.b.c.d source <interface> traceroute a.b.c.d
Documentación de captura PCM:
http://www.cisco.com/c/en/us/support/docs/voice/h323/116078-technologies-technote-commandrefe.html