Introducción
Este documento describe cómo resolver el problema de audio no direccional con llamadas hairpin en Cisco Unified Border Element (CUBE).
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- Protocolo de inicio de sesión (SIP)
- Cómo configurar y utilizar el CUBE
- Flujo de medios y flujo de datos
Componentes Utilizados
La información que contiene este documento se basa en estas versiones de software y hardware.
- Cisco Unified Communications Manager (CUCM) - 11.5.1.10000-5
- CUBO - 15,5(3)S5
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.
Topología de red
Problema
Una llamada de horquilla es una llamada entrante de un distribuidor de servicios de telefonía por Internet (ITSP) reenviada o transferida de nuevo al ITSP, esto da como resultado un audio de ninguna manera, las llamadas normales a ITSP desde teléfonos IP funcionan bien.
De acuerdo con SIP RFC 3264, las negociaciones de socket de medios entre el cliente de agente de usuario SIP (UAC) y el servidor de agente de usuario SIP (UAS) se llevan a cabo a través del protocolo de descripción de sesión (SDP) en el modelo de oferta/respuesta, seguido de todos los fabricantes de productos de voz sobre IP (VoIP).
Algunos ITSP no tienen en cuenta la información de puerto y dirección IP en el SDP debido a su implementación de firewall, por lo tanto, el socket debe ser iniciado por el otro extremo (en este caso, CUBE). ITSP requiere que el extremo lejano envíe algunos paquetes de protocolo de transporte en tiempo real (RTP) hacia él, una vez que ITSP recibe los paquetes RTP, transmite los paquetes a la IP de origen de los paquetes recibidos.
En una llamada entre un teléfono IP y el ITSP, que no cuenta con la horquilla, este problema no ocurre, esto se debe a que el teléfono IP envía paquetes RTP ficticios después de abrir los puertos requeridos.
Cuando una llamada proviene del ITSP y se les envía de vuelta, tanto el iniciador de la llamada como el receptor de la llamada no envían ningún flujo a menos que reciban un flujo de alguien en la trayectoria de la llamada, esto es una situación de interbloqueo.
Verificación
Para validar que la conexión se ha establecido correctamente, ejecute este comando: show voip rtp connections.
Max Ports Available: 19999, Ports Reserved: 101, Ports in Use: 4
Port range not configured, Min: 8000, Max: 48199
Ports Ports Ports
Media-Address Range Available Reserved In-use
Default Address-Range 19999 101 4
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 21 22 16424 16568 10.106.36.169 10.106.108.72
2 22 21 16426 24602 10.106.36.169 10.106.123.29
3 23 24 16428 24600 10.106.36.169 10.106.123.29
4 24 23 16430 16570 10.106.36.169 10.106.108.72
Found 4 active RTP connections
Ejecute el comando show call active voice brief para ver los contadores Rx/Tx de los 4 tramos de llamada desde la perspectiva de CUBE como 0/0.
Total call-legs: 4
35E9 : 21 7441740ms.1 (*13:00:22.857 UTC Sat May 20 2017) +4080 pid:123 Answer 5655 connected
dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<<
IP 10.106.108.72:16568 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
LostPacketRate:0.00 OutOfOrderRate:0.00
35E9 : 22 7441740ms.2 (*13:00:22.857 UTC Sat May 20 2017) +4080 pid:123 Originate 7961 connected
dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<<
IP 10.106.123.29:24602 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
LostPacketRate:0.00 OutOfOrderRate:0.00
0 : 23 7441780ms.1 (*13:00:22.897 UTC Sat May 20 2017) +4020 pid:124 Answer 5655 connected
dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<<
IP 10.106.123.29:24600 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
LostPacketRate:0.00 OutOfOrderRate:0.00
0 : 24 7441780ms.2 (*13:00:22.897 UTC Sat May 20 2017) +4010 pid:124 Originate 7961 connected
dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0 <<<<
IP 10.106.108.72:16570 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
LostPacketRate:0.00 OutOfOrderRate:0.00
Nota: En caso de que los routers utilicen IOS-XE, ejecute este comando para validar los contadores Rx/Tx:
voice service voip
media bulk-stats
No se recomienda ejecutar este comando cuando el volumen de la llamada es alto; asegúrese de ejecutar este comando cuando la CPU sea inferior al 30%.
Solución
Punto de terminación de medios de software (MTP)
Este es el método preferido para superar el problema. Los MTP del software CUCM son capaces de enviar paquetes RTP ficticios. En una llamada hairpin, el software MTP suministra paquetes RTP ficticios a ambos, al iniciador de la llamada y al receptor de la llamada, por lo tanto, el ITSP recibe estos paquetes y responde con RTP al software MTP.
Asegúrese de que la casilla de verificación Media Termination Point Required esté marcada en la página Trunk Configuration. Navegue hasta Device > SIP trunk y seleccione la Media Resource Group List (MRGL) de ese trunk, valide que contiene al menos un MTP de software.
- Nota: el MTP de hardware no puede enviar flujos RTP ficticios. Asegúrese de que el MRGL asociado con el trunk invoca solamente el MTP de software. El software MTP solo puede conectar llamadas G711, asegúrese de que el flujo de llamadas de extremo a extremo debe utilizar G711 para que esta solución alternativa funcione.
La siguiente imagen muestra el aspecto de la carga de RTP ficticia en Wireshark:
Flujo de medios
Con Media Flow-Around, los paquetes de señalización finalizan y se originan en CUBE, pero los paquetes de medios omiten CUBE y fluyen directamente entre los terminales.
voice service voip
media flow-around
Llamada con flujo de medios
Precaución: esto puede afectar a la funcionalidad de CUBE, ya que no puede finalizar medios para ninguna llamada. RTP omite el CUBE y fluye directamente entre los extremos. En este caso, fluye directamente entre los ITSP.
El modo de configuración de par de marcación para el flujo de medios no tiene efecto si Media Flow-Around está configurado en la configuración global.
Configuración
- Configure el flujo de medios en la configuración global.
- Cree un medio de clase de voz con flujo de medios.
- Aplique medios de clase de voz en todos los pares de marcado en los que se espera que se utilice el flujo de medios.
- Los pares de marcado que no tienen esta configuración recaen en Media Flow-Around, ya que está configurada globalmente.
Voice service voip
media flow-around
voice-class media 10
media flow-through
dial-peer voice 1 voip
Description ** Inbound dial-peer **
voice class media 10
dial-peer voice 2 voip
Description ** Outbound dial-peer **
voice class media 10
Anti-Trombón de medios
Esta función funciona de forma similar a Media Flow-Around; sin embargo, afecta menos. En primer lugar, busca las llamadas en bucle o de horquilla; si se encuentra una llamada de horquilla, esta función activa otra ronda de negociación de medios para la llamada identificada. Al final de esta negociación, el CUBE ya no forma parte de la ruta de medios.
Ambas partes, CUBE e ITSP, necesitan soportar la función Anti-Trombone para que esto funcione.
voice service voip
media anti-trombone
Llamada con antitrombón de medios
Nota: Valide las restricciones antes de configurar Media Anti-Trombone en http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/media-path.html
Habilite CUBE para enviar paquetes STUN en el puerto/IP de medios negociados
Habilite el CUBE para enviar solicitudes/paquetes STUN generados localmente (estos paquetes STUN son paquetes UDP con los mismos números de IP/puerto de medios) para ser enviados a través de la trayectoria de medios negociada; los dispositivos en la trayectoria de medios pueden borrar la trayectoria después de obtener estos paquetes STUN después de verificar el protocolo IP/Puerto/transporte si estos dispositivos no están verificando los datos de la aplicación real:
voice service voip
stun
stun flowdata agent-id 1 boot-count 4
stun flowdata shared-secret 0 Password123$
voice class stun-usage 1
stun usage firewall-traversal flow data
dial-peer voice 2000 voip
Descripción ** Dial-peer entrante de ITSP **
voice-class stun-usage 1
Esto se puede hacer en el par de marcado utilizado para recibir la llamada del ITSP o en el par de marcado utilizado para enviar la llamada al ITSP o a ambos.