Convalida dell'origine RTP in router voce IOS e IOS-XE

Introduzione

Questo documento descrive il comportamento della funzione di convalida dell'origine RTP in Cisco IOS e IOS-XE Voice Router per flussi di chiamate e versioni diverse.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Software IOS e IOS-XE
• H.323
• SIP (Session Initiation Protocol)
• Protocollo MGCP (Media Gateway Control Protocol)
• Protocollo SCCP (Skinny Call Control Protocol)
• Protocollo RTP (Real-time Transport Protocol)

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Router ISR2 (ISR2900, ISR3900)
• Router ISR3 (ISR4400 e ISR4300)
• Router ASR (ASR 1001-X, ASR 1002-X, ASR 1004, ASR 1006 e ASR 1006-X con RP2 ed ESP40)

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Per trarre il massimo vantaggio da questo documento, è importante conoscere le nozioni di base sulle reti VoIP e sui protocolli di segnalazione VoIP.

Definizione e utilizzi della convalida dell'origine RTP

La convalida dell'origine RTP è una funzione integrata nei router voce Cisco che consente di eliminare i traffici RTP in entrata non attendibili.

L'obiettivo principale di questa funzionalità è quello di avere un livello di sicurezza più elevato sul dispositivo ed evitare problemi CrossTalk sulle reti VoIP.

Questa funzionalità è disponibile in diversi formati nei router voce IOS e in un'unica opzione nei router voce IOS-XE.

In IOS e IOS-XE, questa funzione fa sì che i router voce scartino il traffico RTP in entrata proveniente da indirizzi IP o porte sconosciuti, in altre parole che i pacchetti ricevuti da un indirizzo IP o da una porta non negoziata tramite segnalazione, vengano scartati dal router voce.

Il funzionamento di questa funzionalità in IOS e IOS-XE è leggermente diverso a causa dell'architettura dei router e del momento in cui sono stati introdotti nel codice; Nelle sezioni seguenti vengono illustrati tali scenari.

Convalida origine RTP in router voce IOS

IOS ha due diverse caratteristiche di questa funzione.

• Filtro sorgente introdotto in 12.4(6)T
• Voice RTP Source-Filter, introdotto nelle versioni 15.5(3)M9, 15.6(3)M6 e successive

Attenzione: gli scenari illustrati nelle sezioni seguenti sono relativi alla musica di attesa (MoH) di Cisco Unified Communications Manager (CUCM), ma in altre situazioni lo stesso comportamento determina l'eliminazione della funzionalità RTP, a condizione che vengano soddisfatti i requisiti. 

Filtro origine

Questa funzionalità è disponibile solo per i flussi di chiamate SIP.

Quando è configurata, se la segnalazione utilizzata nel flusso di chiamata non ha negoziato l'indirizzo IP e la porta da cui proviene l'RTP, il router vocale scarta i pacchetti.

La convalida dell'origine controlla Source IP Address e quindi Source Port.  

Configurazione

voice service voip
 sip
  source filter

Comportamento e rilevamento

Un buon esempio potrebbe essere quando CUCM mette una chiamata in attesa e per impostazione predefinita annuncia la porta 4000 tramite segnalazione ma in realtà invia in streaming il RTP da una porta effimera (32768-61000) poiché il parametro di servizio Streaming duplex abilitato in Parametri a livello di cluster è disabilitato per impostazione predefinita.

Debug CSIP Messages mostra sul router vocale un messaggio SIP ACK ricevuto con Session Description Protocol (SDP) che indica al router che il RTP proviene da CUCM-indirizzo IP e porta 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 non visualizza gli incrementi RX sulla gamba da cui si prevede che la porta RTP provenga dall'indirizzo IP-CUCM e dalla porta 4000. La porta RTP viene ricevuta da una porta diversa e scartata dal router voce.

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

Mostra connessioni VoIP RTP visualizza RmtRTP come 4000 e RemoteIP come indirizzo IP-CUCM.

Il router si aspetta che il RTP provenga dalla stessa origine.

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 un'acquisizione dello sniffer, è possibile verificare da dove provenga effettivamente il RTP, nell'esempio riportato, la sua origine è la porta 24588 anziché 4000, quindi la convalida dell'origine ha esito negativo e il router vocale scarta i pacchetti.

Voice RTP Source-Filter

Questa funzione è stata introdotta nelle versioni 15.5(3)M9, 15.6(3)M6 IOS.

Il funzionamento è analogo a quello del filtro di origine, in cui convalida innanzitutto l'indirizzo IP di origine e quindi la porta di origine, ma presenta due differenze principali.

1. Voice RTP Source-Filter funziona per SIP, H.323, MGCP e SCCP
2. La funzione ha aggiunto anche un messaggio di errore in Debug VoIP RTP Error (Errore debug VoIP RTP) per rilevare facilmente quando il RTP viene scartato a causa di un errore di convalida dell'origine

Attenzione: Questa funzione viene attivata per default e non viene visualizzata nella configurazione. Gli aggiornamenti a qualsiasi versione IOS che supporta questa funzione possono causare problemi audio se vi sono dispositivi che inviano il segnale RTP da una sorgente diversa da quella pubblicizzata tramite segnalazione.
Quando la funzione viene disabilitata da con un No davanti al comando, viene visualizzata nella configurazione.

Configurazione

Configuration Terminal
 voice rtp source-filter

Comportamento e rilevamento per protocollo

H.323:

Debug H225 Asn1 su router voce: visualizza un messaggio openLogicalChannelAck ricevuto che informa il router dell'indirizzo multimediale 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 Active Voice Brief non visualizza gli incrementi RX e l'indirizzo IP remoto e la porta sono impostati su 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: 

Mostra connessioni VoIP RTP indica che RmtRTP e RemoteIP sono impostati su 0.0.0.0:0 in modo che il router si aspetti il RTP da quella sorgente.

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 un'acquisizione sniffer, è possibile verificare dove viene ricevuto l'RTP. Nell'esempio, viene ricevuto dalla porta 24608 e da CUCM-IP-Address in sostituzione di Port 0 e IP Address 0.0.0.

Debug VoIP RTP Error: visualizza il motivo per cui i pacchetti ignorati sono stati ricevuti da CUCM-IP-Address anziché da 0.0.0.0, quindi la convalida dell'origine non riesce.

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

Per SIP:

Debug CCSIP Messages visualizza sul router vocale un messaggio SIP ACK ricevuto con SDP che indica al router di prevedere il protocollo RTP dall'indirizzo IP CUCM e dalla porta 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 non visualizza gli incrementi RX sulla gamba che prevedono la ricezione di RTP da CUCM-IP-Address:4000.

Poiché l'RTP in realtà proviene da un'altra porta, viene scartato.

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 RmtRTP e RemoteIP come indirizzo IP-CUCM:4000, il router si aspetta che il RTP provenga da quella origine.

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 un'acquisizione dello sniffer, è possibile verificare da dove provenga effettivamente il RTP, in questo esempio se proviene dalla porta 24634 e da CUCM-IP-Address invece di CUCM-IP-Address:4000.

L'errore di debug VoIP RTP mostra il motivo per cui i pacchetti ignorati sono stati ricevuti dalla porta 24634 anziché dalla porta 4000, quindi la convalida dell'origine non riesce.

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

Per MGCP:

Debug dei pacchetti MGCP visualizza quando il supporto della chiamata è stato inizialmente negoziato e quindi quando è stato messo in attesa.

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 non visualizza gli incrementi RX sulla gamba che prevedono che il protocollo RTP provenga da IP-Phone-IP-Address:23248.

Poiché l'RTP in realtà proviene da un altro indirizzo IP, viene scartato.

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 RmtRTP e RemoteIP come indirizzo IP-telefono:23248, il router si aspetta che il RTP provenga da quella origine.

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 un'acquisizione dello sniffer, è possibile verificare da dove provenga effettivamente il RTP, in questo esempio se proviene dalla porta 24612 e da CUCM-IP-Address anziché da IP-Phone-IP-Address:23248.

Debug VoIP RTP Error: visualizza il motivo per cui i pacchetti ignorati sono stati ricevuti da CUCM-IP-Address anziché da IP-Phone-IP-Address, quindi la convalida dell'origine non è riuscita.

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

Per SCCP:

Debug dei messaggi SCCP indica quando la chiamata viene messa in attesa.

CUCM indica innanzitutto al router vocale di passare ai supporti inattivi con CloseReceiveChannel e 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

Quindi CUCM indica al router vocale di passare alla ricezione 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 mostra il ripaddr e i report come 0.0.0.0:0; Il router si aspetta che il RTP venga da quella sorgente.

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: visualizza il motivo per cui i pacchetti ignorati sono stati ricevuti da CUCM-IP-Address anziché da 0.0.0.0, quindi la convalida dell'origine non riesce.

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

Convalida dell'origine RTP sui router voce IOS-XE

Le cose più importanti da evidenziare in IOS-XE sono.

1. Non è configurabile
2. È attivata per impostazione predefinita
3. Impossibile disabilitare
4. La direzione dei supporti nella segnalazione VoIP è l'unica eccezione che consente al router di passare da un'origine sconosciuta

Comportamento e rilevamento per protocollo

H.323:

Con questo protocollo, RTP da MoH non funziona in quanto CUCM invia sempre il messaggio openLogicalChannelAck con indirizzo IP e porta impostati su zero che disabilita il supporto.

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

La stessa cosa può essere verificata con Show Call Active Voice Brief per verificare in che modo il valore di incremento RX si arresta e l'indirizzo del supporto remoto è 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

Avviso: RX e TX non aumentano nelle piattaforme IOS-XE a meno che il comando Media Bulk-Stats non sia configurato in Voice Service VoIP, ma questo comando può influire sulle prestazioni del router, quindi si consiglia di abilitarlo solo quando si risolvono i problemi e disabilitarlo in seguito.

Debug Voip FPI Inout non visualizza il flag NAT (Network Address Translation) qui abilitato perché il supporto è stato disabilitato con openLogicalChannelAck, il supporto disabilitato può essere controllato con il messaggio 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 Totale pacchetti ignorati|Pacchetti ignorati: presenta una tabella con tutti i pacchetti ignorati in cui il flusso in ingresso riceve incrementi disabilitati mentre la chiamata è in attesa.

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

Per SIP

Quando si usa il SIP, CUCM invia nel SDP l'indirizzo IP-CUCM, la porta 4000 e l'attributo media per la direzione come a=sendonly, per indicare al router di ricevere solo il protocollo 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

L'opzione a=sendonly imposta la direzione dei supporti in modo che riceva solo la prospettiva del router vocale. In questo modo viene attivata la funzione NAT flag che consente ancora al router di passare attraverso la connessione RTP anche se proviene da una fonte diversa.

È possibile controllare questa condizione 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

Se al router vocale viene inviato un attributo diverso per la direzione del supporto, la funzione di flag NAT non verrà attivata e i pacchetti verranno scartati perché provengono da un'origine diversa.

Debug CCSIP Messages viene mostrato in questo esempio 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 mostra la direzione del supporto impostata su rtp_type:3:SENDRECV e nessuna funzione flag NAT.

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

Poiché non è presente alcun flag NAT, il comando show platform hardware qfp active feature sbc global | s Totale pacchetti ignorati|Pacchetti ignorati: mostra incrementi nella sezione Origine errata per il flusso.

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

Per MGCP:

Quando si usa MGCP, CUCM invia un MDCX per modificare la direzione dei supporti già negoziata quando la chiamata è stata originariamente connessa, in modo da non modificare l'indirizzo IP o la segnalazione, ma dopo l'MDCX il RTP viene ora trasmesso da un'altra origine.

Da M: recvonly viene inviato al router voce. La funzione flag NAT viene abilitata.

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 mostra la direzione del supporto impostata sulla funzione rtp_type:2:RECVONLY e NAT flag, che consente il passaggio del RTP.

//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 al router vocale viene inviato un attributo diverso per la direzione del supporto, la funzione di flag NAT non verrà attivata e i pacchetti verranno scartati perché provengono da un'origine diversa.

Debug dei pacchetti MGCP viene mostrato nell'esempio 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 mostra la direzione del supporto impostata su rtp_type:3:SENDRECV e nessuna funzione flag NAT.

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

Poiché non è presente alcun flag NAT, il show platform hardware qfp active feature sbc global | s Totale pacchetti ignorati|Pacchetti ignorati: mostra incrementi nella sezione Origine errata per il flusso.

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

Per SCCP:

Debug dei messaggi SCCP indica quando la chiamata viene messa in attesa.

CUCM indica innanzitutto al router vocale di passare ai supporti inattivi con CloseReceiveChannel e 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

Quindi CUCM indica al router vocale di passare alla ricezione tramite 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 il ripaddr e i report come 0.0.0.0:0; Il router si aspetta che il RTP venga da quella sorgente.

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 mostra la direzione del supporto impostata sulla funzione rtp_type:2:RECVONLY e NAT flag, che consente il passaggio del RTP.

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

Suggerimento: i messaggi OpenReceiveChannel vengono utilizzati per indicare al router vocale di ricevere il RTP e il router vocale comunica a CUCM tramite OpenReceiveChannelAck dove desidera ricevere il supporto. 
Il messaggio StartMediaTransmission viene usato per indicare al router vocale di inviare il protocollo RTP alla destinazione specificata.

In altre parole, se solo OpenReceiveChannel viene scambiato è un modo per indicare alla risorsa multimediale che riceve solo RTP (recvonly) e se solo StartMediaTransmission viene scambiato, è un modo per indicare alla risorsa multimediale che invia solo RTP (sendonly), ma se vengono scambiati entrambi è uguale a sendrecv.

Se la direzione del supporto è impostata su sendonly o sendrecv e l'RTP proviene da un'origine diversa, non viene attivato alcun flag NAT e la funzionalità attiva show platform hardware qfp sbc global | s Totale pacchetti ignorati|Pacchetti ignorati: mostra i pacchetti ignorati.

Suggerimento: Se è necessario consentire che il protocollo RTP provenga da un indirizzo diverso da quello negoziato tramite segnalazione e ricezione non può essere utilizzato, è possibile usare nat force-on in Voice Service, Sip per aggiungere una previsione manuale. In precedenza, il problema non funzionava correttamente, ma è stato risolto in caso di difetto CSCvo15141 . Tenete presente che questo funziona solo per il SIP.

Avviso: se il contenuto pass-thru sdp nel servizio vocale voip, sip è configurato, il livello FPI non potrà attivare la funzione NAT Flag quando si riceve.

Suggerimento: In alcune situazioni in cui NAT Flag è attivo per una chiamata e l'audio funziona bene, il valore dei pacchetti scartati sotto show platform hardware qfp active feature sbc global | s Totale pacchetti ignorati|Pacchetti ignorati: può comunque aumentare con una frequenza molto inferiore, in quanto in alcune situazioni e flussi di chiamata, il protocollo RTCP (Real Time Control Protocol) può ancora essere inviato al router voce e da un'altra origine che provocherebbe questo comportamento.