Validação de origem de RTP em roteadores de voz IOS e IOS-XE
Contents
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
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.
- Filtro de origem RTP de voz funciona para SIP, H.323, MGCP e SCCP
- 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
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.
- Não é configurável
- Por padrão, ele é ativado
- Não é possível desabilitar
- 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
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
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.
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)