Validación de Origen RTP en Routers de Voz IOS y IOS-XE
Contenido
Introducción
Este documento describe el comportamiento de la función de Validación de Origen RTP en Cisco IOS y Routers de Voz IOS-XE para diferentes flujos de llamadas y versiones.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
- Software IOS y IOS-XE
- H.323
- Protocolo de inicio de sesión (SIP)
- Protocolo de Control de Gateway de Medios (MGCP)
- Skinny Call Control Protocol (SCCP)
- Protocolo de transporte en tiempo real (RTP)
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
- Routers ISRG2 (ISR2900, ISR3900)
- Routers ISRG3 (ISR4400 e ISR4300)
- Routers ASR (ASR1001-X, ASR1002-X, ASR1004, ASR1006 y ASR1006-X con RP2 y ESP40)
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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Antecedentes
Es importante comprender los conceptos básicos de las redes VoIP y los protocolos de señalización VoIP para poder aprovechar al máximo este documento.
Definición y Uso de la Validación de Origen RTP
La validación de origen RTP es una función integrada en los routers de voz de Cisco que les permite descartar los tráficos RTP entrantes no confiables.
El objetivo principal de esta función es tener un mayor nivel de seguridad en el dispositivo y también evitar problemas de CrossTalk en las redes VoIP.
Hay diferentes tipos de esta función en los routers de voz IOS y una única opción en los routers de voz IOS-XE.
En IOS y IOS-XE, esta función hace que los routers de voz descarten el tráfico RTP entrante de direcciones IP o puertos desconocidos, es decir, que los paquetes recibidos de una dirección IP o un puerto que no se negoció a través de la señalización, son descartados por el router de voz.
La forma en que funciona esta función en IOS e IOS-XE es un poco diferente debido a la arquitectura de los Routers y cuando se introdujeron en el código; En las siguientes secciones se explican esos escenarios.
Validación de Origen RTP en Routers de Voz IOS
IOS tiene dos tipos diferentes de esta función.
- Filtro de origen introducido en 12.4(6)T
- Voice RTP Source-Filter que se introdujo en las versiones 15.5(3)M9, 15.6(3)M6 y posteriores
Filtro de origen
Esta función solo está disponible para los flujos de llamadas SIP.
Cuando se configura, si la señalización utilizada en el flujo de llamada no negoció la dirección IP y el puerto de donde proviene el RTP, el router de voz entonces descarta esos paquetes.
La Validación de Origen verifica Dirección IP de Origen y luego Puerto de Origen.
Configuración
voice service voip sip source filter
Comportamiento y detección
Un buen ejemplo sería cuando CUCM pone una llamada en espera y, de forma predeterminada, CUCM anuncia el puerto 4000 a través de la señalización, pero en realidad transmite el RTP desde un puerto efímero (32768-61000) ya que el parámetro de servicio streaming dúplex habilitado bajo Clusterwide Parameters está desactivado de forma predeterminada.
Debug CCSIP Messages muestra en el router de voz un mensaje SIP ACK recibido con el protocolo de descripción de sesión (SDP) que indica al router que el RTP proviene de CUCM-IP-Address y puerto 4000.
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:6002@Router-IP-Address:5060 SIP/2.0
Via: SIP/2.0/UDP CUCM-IP-Address:5060;branch=z9hG4bK4a424fed85
From: <sip:65002@CUCM-IP-Address>;tag=4091~842780d9-7186-4740-ada2-23e5d1b91316-46404063
To: <sip:6002@Router-IP-Address>;tag=2FF652-51D
Date: Thu, 18 Apr 2019 19:59:50 GMT
Call-ID: 3EDDD9E4-614B11E9-800D9C4B-C5465DB2@Router-IP-Address
User-Agent: Cisco-CUCM12.0
Max-Forwards: 70
CSeq: 102 ACK
Allow-Events: presence
Session-ID: 4978aa3900105000a000006cbcbcfda2;remote=836b14b48c77bfe681c0780c54ab4091
Content-Type: application/sdp
Content-Length: 191
v=0
o=CiscoSystemsCCM-SIP 4091 3 IN IP4 CUCM-IP-Address
s=SIP Call
c=IN IP4 CUCM-IP-Address (MoH Server)
t=0 0
m=audio 4000 RTP/AVP 0
a=X-cisco-media:umoh
a=ptime:20
a=rtpmap:0 PCMU/8000
a=sendonly
Show Call Active Voice Brief no muestra incrementos RX en el tramo donde se espera que RTP provenga de CUCM-IP-Address y puerto 4000. El RTP se recibe de un puerto diferente y es descartado por el router de voz.
11EC : 3 3143250ms.1 (14:59:02.516 CDT Thu Apr 18 2019) +1960 pid:0 Answer 6002 active dur 00:47:29 tx:2330/391440 rx:64875/10380000 dscp:0 media:0 audio tos:0x0 video tos:0x0 Tele 0/0/0:23 (3) [0/0/0.23] tx:2803960/1263780/0ms g711ulaw noise:-65 acom:3 i/0:-60/-64 dBm 11EC : 4 3143250ms.2 (14:59:02.516 CDT Thu Apr 18 2019) +1950 pid:1 Originate 65002 connected dur 00:47:29 tx:1686/269760 rx:2330/372800 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP CUCM-IP-Address:4000 SRTP: off rtt:1ms pl:46150/0ms lost:0/0/0 delay:55/55/65ms g711ulaw TextRelay: off Transcoded: No ICE: Off 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
Show VoIP RTP Connections muestra el RmtRTP como 4000 e RemoteIP como CUCM-IP-Address.
El router espera que el RTP provenga de esa misma fuente.
show voip rtp connections
VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 1
Min Max Ports Ports Ports
Media-Address Range Port Port Available Reserved In-use
------------------------------------------------------------------------------
Global Media Pool 16384 32766 8091 101 1
------------------------------------------------------------------------------
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS
1 4 3 16386 4000 Router-IP-Address CUCM-IP-Address NO
Found 1 active RTP connections
Con una captura del sniffer, se puede verificar de dónde proviene realmente el RTP, en este ejemplo proviene del puerto 24588 en lugar de 4000 por lo que la validación del origen falla y el router de voz descarta los paquetes.
Filtro de origen de RTP de voz
Esta función se introdujo en las versiones 15.5(3)M9, 15.6(3)M6 IOS.
Funciona de la misma manera que el filtro de origen donde valida primero la dirección IP de origen y luego el puerto de origen, pero tiene dos diferencias principales.
- Voice RTP Source-Filter funciona para SIP, H.323, MGCP y SCCP
- La función también agregó un mensaje de error en Debug VoIP RTP Error para detectar fácilmente cuándo se descarta el RTP debido a una falla de validación de origen
Configuración
Configuration Terminal voice rtp source-filter
Comportamiento y detección por protocolo
Para H.323:
La depuración H225 Asn1 en los routers de voz muestra un openLogicalChannelAck recibido que informa al router acerca de la dirección de medios remota 0.0.0.0:0.
H245 MSC OUTGOING PDU ::=
value MultimediaSystemControlMessage ::= response : openLogicalChannelAck :
{
forwardLogicalChannelNumber 1
forwardMultiplexAckParameters h2250LogicalChannelAckParameters :
{
mediaChannel unicastAddress : iPAddress :
{
network 'Router-IP-Address'H
tsapIdentifier 16404 (Router's UDP Port for the RTP)
}
mediaControlChannel unicastAddress : iPAddress :
{
network 'Router-IP-Address'H
tsapIdentifier 16405 (Router's UDP Port for the RTCP)
}
flowControlToZero FALSE
}
}
Received openLogicalChannelAck has network and tsapIdentifier for the mediaChannel in zeros which means IP Address 0.0.0.0 and port 0.
H245 MSC INCOMING PDU ::=
value MultimediaSystemControlMessage ::= response : openLogicalChannelAck :
{
forwardLogicalChannelNumber 2
forwardMultiplexAckParameters h2250LogicalChannelAckParameters :
{
sessionID 1
mediaChannel unicastAddress : iPAddress :
{
network '00000000'H
tsapIdentifier 0
}
mediaControlChannel unicastAddress : iPAddress :
{
network '00000000'H
tsapIdentifier 1
}
}
}
Show Call Active Voice Brief no muestra los incrementos RX y Remote IP Address and Port están configurados en 0.0.0.0:0.
11F5 : 21 18903090ms.1 (16:00:48.794 CDT Fri Apr 19 2019) +1070 pid:2 Answer 6002 active dur 00:00:43 tx:376/63168 rx:899/137074 dscp:0 media:0 audio tos:0x0 video tos:0x0 Tele 0/1/0:23 (21) [0/1/0.1] tx:35340/14230/0ms g711ulaw noise:-68 acom:3 i/0:-64/-63 dBm 11F5 : 22 18903090ms.2 (16:00:48.794 CDT Fri Apr 19 2019) +1070 pid:1 Originate 36004 active dur 00:00:43 tx:152/23047 rx:376/60160 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP 0.0.0.0:0 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/65/65ms g711ulaw TextRelay: off Transcoded: No ICE: Off 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 LocalUUID: RemoteUUID: VRF:
Show VoIP RTP Connections muestra el RmtRTP y el RemoteIP como 0.0.0.0:0 para que el router espere el RTP de ese origen.
VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 1
Port range not configured
Min Max Ports Ports Ports
Media-Address Range Port Port Available Reserved In-use
------------------------------------------------------------------------------
Global Media Pool 16384 32766 8091 101 1
------------------------------------------------------------------------------
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF
1 22 21 16404 0 Router-IP-Address 0.0.0.0 NO NA
Found 1 active RTP connections
Con una captura del sniffer, se puede verificar dónde se recibe el RTP. En este ejemplo, se recibe del puerto 24608 y CUCM-IP-Address en lugar del puerto 0 y la dirección IP 0.0.0.
Debug VoIP RTP Error muestra la razón de esos paquetes perdidos como recibidos de CUCM-IP-Address en lugar de 0.0.0.0, por lo que falla la validación de origen.
voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address
Para SIP:
Debug CCSIP Messages muestra en el router de voz un mensaje SIP ACK recibido con SDP que indica al router que espere RTP desde CUCM-IP-Address y puerto 4000.
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:6002@Router-IP-Address:5060 SIP/2.0
Via: SIP/2.0/UDP CUCM-IP-Address:5060;branch=z9hG4bK16712e94eda
From: <sip:65002@CUCM-IP-Address>;tag=5931~842780d9-7186-4740-ada2-23e5d1b91316-46404140
To: <sip:6002@10.201.160.54>;tag=FE677E-E12
Date: Fri, 19 Apr 2019 23:53:48 GMT
Call-ID: 32798F13-623511E9-805BC9D5-801BF5C7@Router-IP-Address
User-Agent: Cisco-CUCM12.0
Max-Forwards: 70
CSeq: 102 ACK
Allow-Events: presence
Session-ID: 5fdd1bc300105000a000006cbcbcfda2;remote=761410b40eed518a94bd5f7bbccfbe40
Content-Type: application/sdp
Content-Length: 191
v=0
o=CiscoSystemsCCM-SIP 5931 3 IN IP4 CUCM-IP-Address
s=SIP Call
c=IN IP4 CUCM-IP-Address (MoH Server)
t=0 0
m=audio 4000 RTP/AVP 0
a=X-cisco-media:umoh
a=ptime:20
a=rtpmap:0 PCMU/8000
a=sendonly
Show Call Active Voice Brief no muestra incrementos RX en el tramo que esperan que RTP reciba de CUCM-IP-Address:4000.
Dado que el RTP proviene de otro puerto, se descarta.
11F0 : 29 16672630ms.1 (18:53:43.109 CDT Fri Apr 19 2019) +1450 pid:0 Answer 6002 active dur 00:00:07 tx:169/28392 rx:265/42400 dscp:0 media:0 audio tos:0x0 video tos:0x0 Tele 0/0/0:23 (29) [0/0/0.23] tx:4020/4020/0ms g711ulaw noise:-74 acom:3 i/0:-64/-64 dBm 11F0 : 30 16672630ms.2 (18:53:43.109 CDT Fri Apr 19 2019) +1450 pid:1 Originate 65002 connected dur 00:00:07 tx:64/10240 rx:169/27040 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP CUCM-IP-Address:4000 SRTP: off rtt:0ms pl:3200/0ms lost:0/0/0 delay:0/55/65ms g711ulaw TextRelay: off Transcoded: No ICE: Off 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 LocalUUID:5fdd1bc300105000a000006cbcbcfda2 RemoteUUID:761410b40eed518a94bd5f7bbccfbe40 VRF: NA
Show VoIP RTP Connections muestra el RmtRTP y el RemoteIP como CUCM-IP-Address:4000, el router espera que el RTP provenga de ese origen.
show voip rtp connections
VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 1
Port range not configured
Min Max Ports Ports Ports
Media-Address Range Port Port Available Reserved In-use
------------------------------------------------------------------------------
Global Media Pool 16384 32766 8091 101 1
------------------------------------------------------------------------------
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF
1 30 29 16430 4000 Router-IP-Address CUCM-IP-Address NO NA
Found 1 active RTP connections
Con una captura de sniffer, se puede verificar de dónde proviene realmente el RTP, en este ejemplo proviene del puerto 24634 y CUCM-IP-Address en lugar de CUCM-IP-Address:4000.
Debug VoIP RTP Error muestra la razón de esos paquetes perdidos como recibidos del puerto 24634 en lugar del puerto 4000, por lo que falla la validación de origen.
voip_rtp_recv_fs_input:ERROR Port validation failed, dropping RTP packet. Expected port: 4000, Received port: 24634 voip_rtp_recv_fs_input:ERROR Port validation failed, dropping RTP packet. Expected port: 4000, Received port: 24634 voip_rtp_recv_fs_input:ERROR Port validation failed, dropping RTP packet. Expected port: 4000, Received port: 24634 voip_rtp_recv_fs_input:ERROR Port validation failed, dropping RTP packet. Expected port: 4000, Received port: 24634
Para MGCP:
Depurar paquetes MGCP muestra cuándo la llamada negoció inicialmente los medios y después cuándo se puso en espera.
When the call initially connects, it negotiates the media capabilities through SDP.
MGCP Packet received from CUCM-IP-Address:2427---> MDCX 1324 S0/SU1/DS1-1/23@3945-A.luirami2.lab MGCP 0.1 C: D000000002c4139b000000F500000008 I: 10 X: 17 L: p:20, a:PCMU, s:off, t:b8 M: sendrecv R: D/[0-9ABCD*#] S: Q: process,loop v=0 o=- 16 0 IN EPN S0/SU1/DS1-1/23@3945-A.luirami2.lab s=Cisco SDP 0 t=0 0 m=audio 23248 RTP/AVP 0 c=IN IP4 IP-Phone-IP-Address <--- MGCP Packet sent to CUCM-IP-Address:2427---> 200 1324 OK <---
Then when it is placed on hold, CUCM only changes the direction of the media.
MGCP Packet received from CUCM-IP-Address:2427---> MDCX 1325 S0/SU1/DS1-1/23@3945-A.luirami2.lab MGCP 0.1 C: D000000002c4139b000000F500000008 I: 10 X: 17 M: recvonly R: D/[0-9ABCD*#] Q: process,loop <--- MGCP Packet sent to CUCM-IP-Address:2427---> 200 1325 OK <---
Show Call Active Voice Brief no muestra incrementos RX en el segmento que espera que RTP provenga de IP-Phone-IP-Address:23248.
Dado que el RTP realmente proviene de otra dirección IP, se descarta.
11FD : 38 31140580ms.1 (19:24:46.254 CDT Fri Apr 19 2019) +0 pid:0 Originate connecting dur 00:00:36 tx:289/46240 rx:272/43520 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP IP-Phone-IP-Address:23248 SRTP: off rtt:1ms pl:5440/70ms lost:0/0/0 delay:0/55/65ms g711ulaw TextRelay: off Transcoded: No ICE: Off 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 LocalUUID: RemoteUUID: VRF: 11FD : 37 31140580ms.2 (19:24:46.252 CDT Fri Apr 19 2019) +0 pid:0 Originate active dur 00:00:36 tx:272/45696 rx:1832/293120 dscp:0 media:0 audio tos:0x0 video tos:0x0 Tele 0/1/1:23 (37) [0/1/1.23] tx:36630/36630/0ms g711ulaw noise:-68 acom:6 i/0:-65/-60 dBm
Show VoIP RTP Connections muestra el RmtRTP y RemoteIP como IP-Phone-IP-Address:23248, el router espera que el RTP provenga de ese origen.
show voip rtp connections
VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 1
Port range not configured
Min Max Ports Ports Ports
Media-Address Range Port Port Available Reserved In-use
------------------------------------------------------------------------------
Global Media Pool 16384 32766 8091 101 1
------------------------------------------------------------------------------
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF
1 38 37 16420 23248 Router-IP-Address IP-Phone-IP-Address NO NA
Found 1 active RTP connections
Con una captura de sniffer, se puede verificar de dónde viene realmente el RTP, en este ejemplo proviene del puerto 24612 y CUCM-IP-Address en lugar de IP-Phone-IP-Address:23248.
Debug VoIP RTP Error muestra la razón de esos paquetes perdidos como recibidos de CUCM-IP-Address en lugar de IP-Phone-IP-Address, por lo que falla la validación de origen.
voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: IP-Phone-IP-Address, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: IP-Phone-IP-Address, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: IP-Phone-IP-Address, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: IP-Phone-IP-Address, Received addr: CUCM-IP-Address
Para SCCP:
Depurar mensajes SCCP muestra cuando la llamada se pone en espera.
En primer lugar, CUCM indica al ruteador de voz que cambie a un medio inactivo con un CloseReceiveChannel y una StopMediaTransmission.
SCCP:rcvd CloseReceiveChannel CloseReceiveChannelMsg Info: conference_id = 33554439, pass_through_party_id = 33554541, call_ref = 46404215, port_handling = 0 SCCP:rcvd StopMediaTransmission StopMediaTransmissionMsg Info: conference_id = 33554439, pass_through_party_id = 33554541, call_ref = 46404215, port_handling = 0
A continuación, CUCM indica al ruteador de voz que cambie para recobrar con un OpenReceiveChannel.
SCCP:rcvd OpenReceiveChannel OpenReceiveChannelMsg Info: conference_id = 33554439, pass_through_party_id = 33554542 msec_pkt_size = 20, compression_type = 4 qualifier_in.ecvalue = 0, g723_bitrate = 0, call_ref = 46404215 stream_pass_through_id = 16777216, rfc2833_payload_type = 0 codec_dynamic_payload = 0, codec_mode = 0 Encryption Info :: algorithm_id 0, key_len 0, salt_len 0 requestedAddrType = 0, source_ip_addr.ipAddrType = 0, source_ip_addr = CUCM-IP-Address, source_port_number = 4000, audio_level_adjustment = 0 SCCP:send OpenReceiveChannelAck OpenReceiveChannelAck Info: pass_through_party_id=33554542, status=0(ok), host_ip_addr= Router-IP-Address, port=16390
Show SCCP Connections muestra la ripaddr y portas 0.0.0.0:0; El router espera que el RTP provenga de ese origen.
show sccp connections sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx 33554439 33554542 mtp recvonly g711u 16390 0 0.0.0.0 33554439 33554540 mtp sendrecv g711u 16386 16384 10.201.160.54 Total number of active session(s) 1, and connection(s) 2
Debug VoIP RTP Error muestra la razón de esos paquetes perdidos como recibidos de CUCM-IP-Address en lugar de 0.0.0.0, por lo que falla la validación de origen.
000147: Apr 24 11:49:22.499: voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address 000148: Apr 24 11:49:22.519: voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address 000149: Apr 24 11:49:22.539: voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address 000150: Apr 24 11:49:22.559: voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address
Validación de Origen RTP en Routers de Voz IOS-XE
Los aspectos más importantes que se deben destacar en IOS-XE son.
- No se puede configurar
- Está habilitado de forma predeterminada
- No se puede desactivar
- La dirección de medios en la señalización VoIP es la única excepción que permite que el RTP fluya desde un origen desconocido
Comportamiento y detección por protocolo
Para H.323:
Con este protocolo, el RTP de MoH no funciona ya que CUCM siempre envía el mensaje openLogicalChannelAck con la dirección IP y el puerto configurados en ceros que desactivan el medio.
H245 MSC INCOMING PDU ::=
value MultimediaSystemControlMessage ::= response : openLogicalChannelAck :
{
forwardLogicalChannelNumber 6
forwardMultiplexAckParameters h2250LogicalChannelAckParameters :
{
sessionID 1
mediaChannel unicastAddress : iPAddress :
{
network '00000000'H
tsapIdentifier 0
}
mediaControlChannel unicastAddress : iPAddress :
{
network '00000000'H
tsapIdentifier 1
Lo mismo se puede verificar con Mostrar resumen de voz activo de llamada para verificar cómo se detiene el valor RX y la dirección de medios remota es IP 0.0.0.0:0.
11F3 : 17 8703830ms.1 (13:00:22.060 CDT Tue Apr 23 2019) +2150 pid:2 Answer 6002 active dur 00:15:22 tx:19014/9213600 rx:1/3836010 dscp:0 media:0 audio tos:0x0 video tos:0x0 Tele 0/1/1:23 (17) [0/1/1.23] tx:158740/106870/0ms g711ulaw noise:-68 acom:22 i/0:-57/-61 dBm 11F3 : 18 8703830ms.2 (13:00:22.060 CDT Tue Apr 23 2019) +2150 pid:1 Originate 55002 active dur 00:15:22 tx:19709/3836010 rx:46068/9213600 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP 0.0.0.0:0 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No ICE: Off 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
Debug Voip FPI Inout no muestra el indicador de traducción de direcciones de red (NAT) habilitado aquí, ya que los medios se desactivaron con openLogicalChannelAck, los medios desactivados se pueden comprobar con el lado del mensaje:SIDE_A, rtp_type:0:.
//18/7F507F32800A/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:0: send:0 recv:0 //18/7F507F32800A/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: destAddr == 0, rcv and send both set to FALSE
show platform hardware qfp active feature sbc global | s Total de paquetes descartados|Paquetes descartados: presenta una tabla con todos los paquetes perdidos donde el flujo de entrada recibe incrementos inhabilitados mientras la llamada está en espera.
show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets: Total packets dropped = 138512 Dropped packets: No associated flow = 0 Wrong source for flow = 0 Ingress flow receive disabled = 138512 Egress flow send disabled = 0 Not conforming to flowspec = 0
Para SIP
Cuando se utiliza SIP, CUCM envía en el SDP el atributo CUCM-IP-Address, Port 4000 y el atributo media para la dirección como a=sendonly, que indica al router que reciba sólo RTP.
v=0 o=CiscoSystemsCCM-SIP 72019 3 IN IP4 CUCM-IP-Address s=SIP Call c=IN IP4 CUCM-IP-Address (MoH Server) t=0 0 m=audio 4000 RTP/AVP 0 a=X-cisco-media:umoh a=ptime:20 a=rtpmap:0 PCMU/8000 a=sendonly
La a=sendonly establece la dirección de medios en recvonly para la perspectiva del router de voz y esto desencadena la función NAT flag que aún permite que el RTP pase aunque proviene de un origen diferente.
Esto se puede verificar con Debug VoIP FPI Inout.
//25/3EAF69800000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:2:RECVONLY send:0 recv:2 //25/3EAF69800000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: recvonly mode - setting NAT flag
Si se envía un atributo diferente para dirección de medios al router de voz cuando esto sucede, la función del indicador NAT no se activará y los paquetes se descartarán porque vienen de un origen diferente.
Debug CCSIP Messages muestra en este ejemplo a=sendrecv.
v=0 o=CiscoSystemsCCM-SIP 72019 3 IN IP4 CUCM-IP-Address s=SIP Call c=IN IP4 CUCM-IP-Address (MoH Server) t=0 0 m=audio 4000 RTP/AVP 0 a=X-cisco-media:umoh a=ptime:20 a=rtpmap:0 PCMU/8000 a=sendrecv
Debug VoIP FPI Inout muestra la dirección de medios establecida en rtp_type:3:SENDRECV y sin función de indicador NAT.
//27/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2
Como no hay ningún indicador NAT, el show platform hardware qfp active feature sbc global | s Total de paquetes descartados|Paquetes descartados: muestra incrementos en la sección Origen incorrecto para flujo.
4351-A#show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets: Total packets dropped = 33496 Dropped packets: No associated flow = 0 Wrong source for flow = 33196 Ingress flow receive disabled = 0 Egress flow send disabled = 0 Not conforming to flowspec = 0
Para MGCP:
Cuando se utiliza MGCP, CUCM envía un MDCX para cambiar la dirección de medios ya negociada cuando la llamada se conectó originalmente, por lo que no hay cambios en la dirección IP ni en la señalización, pero después del MDCX el RTP ahora se transmite desde otro origen.
Desde M: recvonly se envía al router de voz, se habilita la función del indicador NAT.
MGCP Packet received from CUCM-IP-Address:2427---> MDCX 1529 S0/SU1/DS1-1/23@4351-A.luirami2.lab MGCP 0.1 C: D000000002c4151d000000F50000000a I: B X: 17 M: recvonly R: D/[0-9ABCD*#] Q: process,loop <---
Debug VoIP FPI Inout muestra la dirección de medios establecida en la función rtp_type:2:RECVONLY y la función de indicador NAT, que permite que el RTP fluya.
//30/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:2:RECVONLY send:0 recv:2 //30/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: recvonly mode - setting NAT flag
Si se envía un atributo diferente para dirección de medios al router de voz cuando esto sucede, la función del indicador NAT no se activará y los paquetes se descartarán porque vienen de un origen diferente.
Debug MGCP Packets muestra en este ejemplo M: sendrecv.
MGCP Packet received from CUCM-IP-Address:2427---> MDCX 1530 S0/SU1/DS1-1/23@4351-A.luirami2.lab MGCP 0.1 C: D000000002c4151d000000F50000000a I: B X: 17
M: sendrecv R: D/[0-9ABCD*#] Q: process,loop <---
Debug VoIP FPI Inout muestra la dirección de medios establecida en rtp_type:3:SENDRECV y sin función de indicador NAT.
//29/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2
Como no hay ningún indicador NAT, show platform hardware qfp active feature sbc global | s Total de paquetes descartados|Paquetes descartados: muestra incrementos en la sección Origen incorrecto para flujo.
show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets: Total packets dropped = 33596 Dropped packets: No associated flow = 0 Wrong source for flow = 33296 Ingress flow receive disabled = 0 Egress flow send disabled = 0 Not conforming to flowspec = 0
Para SCCP:
Depurar mensajes SCCP muestra cuando la llamada se pone en espera.
En primer lugar, CUCM indica al ruteador de voz que cambie a un medio inactivo con un CloseReceiveChannel y una StopMediaTransmission.
SCCP:rcvd CloseReceiveChannel
CloseReceiveChannelMsg Info:
conference_id = 33554436, pass_through_party_id = 33554500, call_ref = 46405010, port_handling = 0
SCCP:rcvd StopMediaTransmission
StopMediaTransmissionMsg Info:
conference_id = 33554436, pass_through_party_id = 33554500, call_ref = 46405010, port_handling = 0
A continuación, CUCM indica al ruteador de voz que cambie para recuperarse solamente con un OpenReceiveChannel.
SCCP:rcvd OpenReceiveChannel
OpenReceiveChannelMsg Info:
conference_id = 33554436, pass_through_party_id = 33554501
msec_pkt_size = 20, compression_type = 4
qualifier_in.ecvalue = 0, g723_bitrate = 0, call_ref = 46405010
stream_pass_through_id = 16777216, rfc2833_payload_type = 0
codec_dynamic_payload = 0, codec_mode = 0
Encryption Info :: algorithm_id 0, key_len 0, salt_len 0
requestedAddrType = 0, source_ip_addr.ipAddrType = 0, source_ip_addr = CUCM-IP-Address, source_port_number = 4000,
audio_level_adjustment = 0
SCCP:send OpenReceiveChannelAck
OpenReceiveChannelAck Info:
pass_through_party_id=33554501, status=0(ok), host_ip_addr= Router-IP-Address, port=8028
Show SCCP Connections muestra la ripaddr y portas 0.0.0.0:0; El router espera que el RTP provenga de ese origen.
show sccp connections sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx 33554436 33554501 mtp recvonly g711u 8028 0 0.0.0.0 33554436 33554499 mtp sendrecv g711u 8022 8024 Router-IP-Address Total number of active session(s) 1, and connection(s) 2
Debug VoIP FPI Inout muestra la dirección de medios establecida en la función rtp_type:2:RECVONLY y la función de indicador NAT, que permite que el RTP fluya.
//18/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:1:SENDONLY send:1 recv:0
//15/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_B, rtp_type:3:SENDRECV send:1 recv:2
//19/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:2:RECVONLY send:0 recv:2
//19/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: recvonly mode - setting NAT flag
//15/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_B, rtp_type:3:SENDRECV send:1 recv:2
Si la dirección de medios está configurada para enviar solamente o sendrecv y el RTP viene de un origen diferente, entonces no se activa ningún indicador NAT y se muestra la función activa de la plataforma hardware qfp sbc global | s Total de paquetes descartados|Paquetes descartados: muestra los paquetes descartados.
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)