Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Antecedentes

Definición y Uso de la Validación de Origen RTP

Validación de Origen RTP en Routers de Voz IOS

Filtro de origen

Configuración

Comportamiento y detección

Filtro de origen de RTP de voz

Configuración

Comportamiento y detección por protocolo

Validación de Origen RTP en Routers de Voz IOS-XE

Comportamiento y detección por protocolo

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

Precaución: tenga en cuenta que los escenarios que se describen en las secciones siguientes se encuentran con Music on Hold (MoH) de Cisco Unified Communications Manager (CUCM), pero hay otras situaciones en las que el mismo comportamiento hace que la función descarte el RTP siempre que se cumplan los requisitos.

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.

1. Voice RTP Source-Filter funciona para SIP, H.323, MGCP y SCCP

2. 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

Precaución: Esta función se activa de forma predeterminada y no aparece en la configuración. Las actualizaciones a cualquier versión de IOS que soporte esta función pueden dar lugar a problemas de audio si hay dispositivos que envían RTP desde una fuente diferente a la anunciada sobre la señalización.

Cuando se inhabilita la función con un No delante del comando, se muestra en la configuración.

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.

1. No se puede configurar

2. Está habilitado de forma predeterminada

3. No se puede desactivar

4. 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

Advertencia: RX y TX no aumentan en las plataformas IOS-XE a menos que el comando Media Bulk-Stats esté configurado bajo la VoIP de servicio de voz, pero tenga en cuenta que este comando puede afectar el rendimiento del router, por lo que se recomienda habilitarlo sólo cuando se solucione el problema y se inhabilite después.

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

Sugerencia: los mensajes de OpenReceiveChannel se utilizan para indicar al router de voz que reciba RTP y el router de voz le dice a CUCM a través de OpenReceiveChannelAck dónde desea recibir ese medio.

StartMediaTransmission se utiliza para indicar al router de voz que envíe RTP al destino especificado.

En otras palabras, si sólo OpenReceiveChannel se intercambia es una manera de decirle al recurso de medios que sólo recibe RTP (recvonly) y si sólo se intercambia StartMediaTransmission, es una manera de decir al recurso de medios que sólo envía RTP (sendonly), pero si ambos se intercambian es igual a sendrecv.

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.

Consejo: Si hay una necesidad de permitir que RTP se origine desde una dirección diferente a la negociada a través de la señalización y recvonly no se puede utilizar, nat force-on bajo Voip de servicio de voz, Sip se puede utilizar para agregar una expectativa manual. Anteriormente no funcionaba correctamente, pero se solucionó el defecto CSCvo15141 . Tenga en cuenta que esto solo funciona para SIP.

Advertencia: Si pasa el sdp de contenido bajo voip de servicio de voz, se configura sip, esto no permite que la capa FPI active la función NAT Flag cuando se recibe recvonly.

Consejo: En algunas situaciones en las que NAT Flag está activo para una llamada y el audio funciona bien, se descartó el valor de los paquetes bajo show platform hardware qfp active feature sbc global | s Total de paquetes descartados|Paquetes descartados: Puede aumentar aún más en una velocidad mucho menor, esto se debe a que en algunas situaciones y flujos de llamadas, el protocolo de control en tiempo real (RTCP) todavía se puede enviar al router de voz y desde una fuente diferente que podría provocar este comportamiento.