Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Informações de Apoio

Definição e uso da validação da origem de RTP

Validação de origem de RTP em roteadores de voz IOS

Filtro de Origem

Configuração

Comportamento e detecção

Filtro de origem RTP de voz

Configuração

Comportamento e detecção por protocolo

Validação de origem de RTP em roteadores de voz IOS-XE

Comportamento e detecção por protocolo

Introduction

Este documento descreve o comportamento do recurso de validação de origem de RTP nos roteadores de voz IOS e IOS-XE da Cisco para diferentes fluxos de chamada e versões.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

- Software IOS e IOS-XE

- H.323

- Protocolo de Iniciação da Sessão (SIP)

- Media Gateway Control Protocol (MGCP)

- Skinny Call Control Protocol (SCCP)

- Protocolo de transporte em tempo real (RTP)

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

- Roteadores ISR2900, ISR3900

- Roteadores ISR4400 e ISR4300

- Roteadores ASR (ASR1001-X, ASR1002-X, ASR1004, ASR1006 e ASR1006-X com RP2 e 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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

É importante entender os conceitos básicos das redes VoIP e dos protocolos de sinalização VoIP para poder aproveitar ao máximo este documento.

Definição e uso da validação da origem de RTP

A Validação da Fonte RTP é um recurso integrado nos Cisco Voice Routers que permite que eles descartem tráfego RTP de entrada não confiável.

O principal objetivo deste recurso é ter um nível de segurança mais alto no dispositivo e também evitar problemas do CrossTalk em redes VoIP.

Há diferentes sabores desse recurso em roteadores de voz IOS e uma única opção em roteadores de voz IOS-XE.

No IOS e no IOS-XE, esse recurso faz com que os Roteadores de Voz descartem o tráfego RTP de entrada de endereços IP ou portas desconhecidas, em outras palavras, os pacotes recebidos de um endereço IP ou porta que não foi negociada por meio da sinalização, são descartados pelo Roteador de Voz.

A forma como esse recurso funciona no IOS e no IOS-XE é um pouco diferente devido à arquitetura dos roteadores e quando eles foram introduzidos no código; As próximas seções explicam esses cenários.

Validação de origem de RTP em roteadores de voz IOS

O IOS tem dois sabores diferentes desse recurso.

- Filtro de Origem introduzido em 12.4(6)T

- Filtro de origem de RTP de voz que foi introduzido em 15.5(3)M9, 15.6(3)M6 e versões anteriores

Cuidado:Esteja ciente de que os cenários abordados nas próximas seções são com o Cisco Unified Communications Manager (CUCM) Music on Hold (MoH), mas há outras situações em que o mesmo comportamento aciona o recurso para descartar o RTP desde que os requisitos sejam atendidos.

Filtro de Origem

Esse recurso está disponível somente para fluxos de chamada SIP.

Quando configurado, se a sinalização usada no fluxo de chamada não negociou o endereço IP e a porta de onde o RTP vem, o roteador de voz descarta esses pacotes.

A Validação de Origem verifica o Endereço IP de Origem e, em seguida, a Porta de Origem.

Configuração

voice service voip

sip

source filter

Comportamento e detecção

Um bom exemplo seria quando o CUCM coloca uma chamada em espera e, por padrão, o CUCM anuncia a porta 4000 através da sinalização, mas na verdade transmite o RTP de uma porta efêmera (32768-61000), pois o parâmetro de serviço Transmissão duplex habilitada em Parâmetros Clusterwideé desabilitado padrão.

Debug CCSIP Messages mostra no Roteador de Voz uma mensagem ACK SIP recebida com o Session Description Protocol (SDP) que informa ao roteador que o RTP vem de CUCM-IP-Address e Port 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 Ative Voice Brief não mostra incrementos de RX no trecho em que o RTP deve vir do CUCM-IP-Address e da porta 4000. O RTP é recebido de uma porta diferente e descartado pelo Roteador 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 mostra o RmtRTP como 4000 e RemoteIP como CUCM-IP-Address.

O roteador espera que o RTP venha dessa mesma origem.

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

Com uma captura de farejador, ela pode ser verificada de onde o RTP realmente vem, neste exemplo, ela vem da porta 24588 em vez de 4000 para que a validação de origem falhe e o Roteador de Voz descarte os pacotes.

Filtro de origem RTP de voz

Este recurso foi apresentado nas versões 15.5(3)M9, 15.6(3)M6 do IOS.

Funciona da mesma forma que o Filtro de Origem onde valida primeiro o Endereço IP de Origem e depois a Porta de Origem, mas tem duas diferenças principais.

1. Filtro de origem RTP de voz funciona para SIP, H.323, MGCP e SCCP

2. O recurso também adicionou uma mensagem de erro em Debug VoIP RTP Error para detectar facilmente quando o RTP é descartado devido a uma falha de validação de origem

Caution: Esse recurso vem ativado por padrão e não aparece na configuração. As atualizações para qualquer versão do IOS que suporte esse recurso podem resultar em problemas de áudio se houver dispositivos que enviam o RTP de uma origem diferente daquela anunciada sobre a sinalização.

Quando o recurso é desativado por meio de um Não na frente do comando, ele aparece na configuração.

Configuração

Configuration Terminal

voice rtp source-filter

Comportamento e detecção por protocolo

Para H.323:

A depuração H225 Asn1 em Roteadores de Voz mostra um openLogicalChannelAck recebido que informa o roteador sobre o endereço de mídia remoto 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 Ative Voice Brief não mostra incrementos RX e Remote IP Address and Port estão definidos como 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 mostra o RmtRTP e o RemoteIP como 0.0.0.0:0 para que o roteador espere o RTP dessa origem.

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

Com uma captura de farejador, ele pode ser verificado onde o RTP é recebido. Neste exemplo, ele é recebido da porta 24608 e do CUCM-IP-Address em vez da porta 0 e do IP Address 0.0.0.0.

Debug VoIP RTP Error mostra o motivo para os pacotes descartados como recebidos do CUCM-IP-Address em vez de 0.0.0.0, portanto ele falha na validação da origem.

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 mostra no Roteador de Voz uma mensagem ACK SIP recebida com SDP que instrui o roteador a esperar RTP de CUCM-IP-Address e Port 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 Ative Voice Brief não mostra incrementos de RX no segmento que espera que o RTP seja recebido do CUCM-IP-Address:4000.

Como o RTP vem de outra porta, ele é descartado.

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 mostra o RmtRTP e o RemoteIP como CUCM-IP-Address:4000, o roteador espera que o RTP venha dessa origem.

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

Com uma captura de sniffer, ela pode ser verificada de onde o RTP realmente vem, neste exemplo, ela vem da porta 24634 e CUCM-IP-Address em vez de CUCM-IP-Address:4000.

Debug VoIP RTP Error mostra o motivo para os pacotes descartados como recebidos da porta 24634 em vez da porta 4000, portanto ele falha na validação da origem.

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:

Debug MGCP Packets mostra quando a chamada negociou inicialmente a mídia e quando ela é colocada em 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 Ative Voice Brief não mostra incrementos de RX no segmento que espera que o RTP venha de IP-Phone-IP-Address:23248.

Como o RTP vem de outro endereço IP, ele é descartado.

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 mostra o RmtRTP e o RemoteIP como IP-Phone-IP-Address:23248, o roteador espera que o RTP venha dessa origem.

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

Com uma captura de farejador, ela pode ser verificada de onde o RTP realmente vem, neste exemplo, ela vem da porta 24612 e CUCM-IP-Address em vez de IP-Phone-IP-Address:23248.

Debug VoIP RTP Error mostra a razão para esses pacotes descartados como recebidos de CUCM-IP-Address em vez de IP-Phone-IP-Address, portanto ele falha na validação da origem.

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 mensagens SCCP mostra quando a chamada é colocada em espera.

O CUCM primeiro instrui o Roteador de Voz a mudar para mídia inativa com um CloseReceiveChannel e uma 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

Em seguida, o CUCM instrui o Roteador de Voz a mudar para recuperação com um 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 mostra o ripaddr e o porta 0.0.0.0:0; o roteador espera que o RTP venha dessa origem.

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 mostra o motivo para os pacotes descartados como recebidos do CUCM-IP-Address em vez de 0.0.0.0, portanto ele falha na validação da origem.

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

Validação de origem de RTP em roteadores de voz IOS-XE

As coisas mais importantes a serem destacadas no IOS-XE são.

1. Não é configurável

2. Por padrão, ele é ativado

3. Não é possível desabilitar

4. A direção da mídia na sinalização VoIP é a única exceção que permite que o RTP flua de uma origem desconhecida

Comportamento e detecção por protocolo

Para H.323:

Com esse protocolo, o RTP do MoH não funciona porque o CUCM sempre envia a mensagem openLogicalChannelAck com endereço IP e porta definidos como zeros, o que desabilita a mídia.

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

A mesma coisa pode ser verificada com o Show Call Ative Voice Brief para verificar como o valor de RX incrementa para e o endereço de mídia remota é 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

aviso: RX e TX não incrementam em plataformas IOS-XE a menos que o comando Media Bulk-Stats esteja configurado em Voice Service VoIP, mas saiba que esse comando pode afetar o desempenho do roteador, portanto, é recomendável ativá-lo somente ao solucionar problemas e desativá-lo posteriormente.

A entrada de FPI de Depuração Voip não mostra o sinalizador de Conversão de Endereço de Rede (NAT) ativado aqui, pois a mídia foi desabilitada com o openLogicalChannelAck, a mídia desabilitada pode ser verificada com a mensagem lado: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 ative feature sbc global | s Total de pacotes descartados|Pacotes descartados: apresenta uma tabela com todos os pacotes descartados onde o fluxo de entrada recebe incrementos desativados enquanto a chamada está em 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

Quando o SIP é usado, o CUCM envia no SDP o CUCM-IP-Address, a porta 4000 e o atributo de mídia para direção como a=sendonly, que instrui o roteador a receber somente 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

O a=sendonly define a direção da mídia como recvonly para a perspectiva do Roteador de Voz e isso aciona a função de flag NAT que ainda permite que o RTP passe, mesmo que provém de uma fonte diferente.

Isso pode ser verificado com 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

Se um Atributo diferente para a Direção de Mídia for enviado ao Roteador de Voz quando isso acontecer, a função flag NAT não será ativada e os pacotes serão descartados porque vêm de uma origem diferente.

Debug CCSIP Messages mostra neste exemplo 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

A entrada FPI de VoIP de depuração mostra a direção de mídia definida como rtp_type:3:SENDRECV e nenhuma função de flag NAT.

//27/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2

Como não há sinalizador NAT, o comando show platform hardware qfp ative feature sbc global | s Total de pacotes descartados|Pacotes descartados: mostra incrementos na seção Origem errada para fluxo.

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:

Quando o MGCP é usado, o CUCM envia um MDCX para alterar a direção da mídia já negociada quando a chamada foi conectada originalmente, portanto, nenhuma alteração no endereço IP ou na sinalização, mas depois do MDCX, o RTP é transferido de outra origem.

Desde M: Recvonly é enviado para o Roteador de Voz, a função flag NAT é habilitada.

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

<---

A entrada FPI de Depuração VoIP mostra a direção de mídia definida como rtp_type:2:RECVONLY e NAT flag function, que permite que o RTP flua.

//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

Se um Atributo diferente para a Direção de Mídia for enviado ao Roteador de Voz quando isso acontecer, a função flag NAT não será ativada e os pacotes serão descartados porque vêm de uma origem diferente.

Debug MGCP Packets mostra neste exemplo 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

<---

A entrada FPI de VoIP de depuração mostra a direção de mídia definida como rtp_type:3:SENDRECV e nenhuma função de flag NAT.

//29/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2

Como não há flag NAT, o comando show platform hardware qfp ative feature sbc global | s Total de pacotes descartados|Pacotes descartados: mostra incrementos na seção Origem errada para fluxo.

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 mensagens SCCP mostra quando a chamada é colocada em espera.

O CUCM primeiro instrui o Roteador de Voz a mudar para mídia inativa com um CloseReceiveChannel e uma 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

Em seguida, o CUCM instrui o Roteador de Voz a alternar para recuperação com um 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 mostra o ripaddr e o porta 0.0.0.0:0; o roteador espera que o RTP venha dessa origem.

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

A entrada FPI de Depuração VoIP mostra a direção de mídia definida como rtp_type:2:RECVONLY e NAT flag function, que permite que o RTP flua.

//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

Dica: as mensagens do OpenReceiveChannel são usadas para instruir o Roteador de Voz a receber o RTP e o Roteador de Voz informa ao CUCM sobre o OpenReceiveChannelAck onde ele deseja receber essa mídia.

A mensagem StartMediaTransmission é usada para instruir o Roteador de Voz a enviar RTP ao destino especificado.

Em outras palavras, se apenas o OpenReceiveChannel é trocado é uma forma de dizer ao recurso de mídia que ele somente recebe RTP (recuperação) e se somente StartMediaTransmission é trocado, é uma forma de dizer ao recurso de mídia que ele envia somente RTP (sendonly), mas se ambos forem trocados é igual a sendrecv.

Se a direção da mídia estiver definida como sendonly ou sendrecv e o RTP vier de uma origem diferente, nenhuma flag NAT será ativada e a opção show platform hardware qfp ative feature sbc global | s Total de pacotes descartados|Pacotes descartados: mostra pacotes descartados.

Tip: Se houver necessidade de permitir que o RTP tenha origem em um endereço diferente daquele negociado por meio da sinalização e recuperação não puder ser usado, nat force em Voice Service Voip, Sip pode ser usado para adicionar uma expectativa manual. Anteriormente, isso não estava funcionando corretamente, mas estava corrigido em um defeito CSCvo15141 . Lembre-se de que isso funciona somente para SIP.

Aviso: se o conteúdo de passagem sdp sob voz voip do serviço de voz, sip está configurado, isso não permite que a camada FPI ative a NAT Flag Function quando recvonly é recebida.

Tip: Em algumas situações em que o sinalizador NAT está ativo para uma chamada e o áudio funciona bem, o valor dos pacotes descartados em show platform hardware qfp ative feature sbc global | s Total de pacotes descartados|Pacotes descartados: Ainda pode aumentar em uma taxa muito mais baixa, porque em algumas situações e fluxos de chamadas, o Protocolo de Controle em Tempo Real (RTCP) ainda pode ser enviado para o Roteador de Voz e de uma fonte diferente que causaria esse comportamento.