RTP-Quellvalidierung in IOS- und IOS-XE-Voice-Routern
Inhalt
Einführung
Dieses Dokument beschreibt das Verhalten der Funktion zur RTP-Quellvalidierung in Cisco IOS- und IOS-XE-Voice Routern für verschiedene Anrufabläufe und Versionen.
Voraussetzungen
Anforderungen
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
- IOS- und IOS-XE-Software
- H.323
- Session Initiation Protocol (SIP)
- MGCP (Media Gateway Control Protocol)
- Skinny Call Control Protocol (SCCP)
- Real-Time Transport Protocol (RTP)
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:
- ISR G2-Router (ISR2900, ISR3900)
- ISR G3 Router (ISR4400 und ISR4300)
- ASR-Router (ASR1001-X, ASR1002-X, ASR1004, ASR1006 und ASR1006-X mit RP2 und ESP40)
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Hintergrundinformationen
Es ist wichtig, die Grundlagen von VoIP-Netzwerken und VoIP-Signalisierungsprotokollen zu verstehen, um die Vorteile dieses Dokuments in vollem Umfang nutzen zu können.
Definition und Verwendung der RTP-Quellvalidierung
Die RTP-Quellvalidierung ist eine in Cisco Voice Router integrierte Funktion, mit der nicht vertrauenswürdige eingehende RTP-Datenverkehr verworfen werden kann.
Das Hauptziel dieser Funktion besteht darin, eine höhere Sicherheitsstufe auf dem Gerät zu erreichen und CrossTalk-Probleme in VoIP-Netzwerken zu vermeiden.
IOS-Voice-Router verfügen über verschiedene Funktionen und IOS-XE-Voice-Router über eine einzige Option.
In IOS und IOS-XE lässt diese Funktion den Voice Routern eingehenden RTP-Datenverkehr von unbekannten IP-Adressen oder Ports verwerfen, d. h. Pakete, die von einer IP-Adresse oder einem Port empfangen wurden, der nicht über die Signalisierung ausgehandelt wurde, werden vom Voice Router verworfen.
Die Funktionsweise dieser Funktion in IOS und IOS-XE unterscheidet sich etwas von der Architektur der Router und ihrer Einführung in den Code. In den nächsten Abschnitten werden diese Szenarien erläutert.
RTP-Quellvalidierung in IOS-Sprach-Routern
IOS bietet zwei verschiedene Varianten dieser Funktion.
- Quellfilter, eingeführt in 12.4(6)T
- Voice RTP Source-Filter, der in den Versionen 15.5(3)M9, 15.6(3)M6 und höher eingeführt wurde
Quellfilter
Diese Funktion ist nur für SIP-Anrufflüsse verfügbar.
Wenn die im Anruffluss verwendete Signalisierung die IP-Adresse und den Port, von dem das RTP stammt, nicht aushandelt, werden diese Pakete bei der Konfiguration vom Voice Router verworfen.
Die Quellvalidierung überprüft die IP-Quelladresse und anschließend den Quellport.
Konfiguration
voice service voip sip source filter
Verhalten und Erkennung
Ein gutes Beispiel wäre, wenn der CUCM einen Anruf in die Haltestellung setzt und der CUCM standardmäßig den Port 4000 durch Signalisierung meldet, aber das RTP tatsächlich von einem flüchtigen Port (32768-61000) durchläuft, da der Service Parameter Duplex Streaming unter Clusterweiten Parametern standardmäßig deaktiviert ist.
Die Debug-CCSIP-Nachrichten zeigen auf dem Voice Router eine SIP ACK-Nachricht an, die mit Session Description Protocol (SDP) empfangen wurde. Dadurch wird dem Router mitgeteilt, dass das RTP von der CUCM-IP-Adresse und dem Port 4000 stammt.
//-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
Die Anzeige "Call Active Voice Brief" zeigt keine RX-Inkremente auf der Strecke an, auf der RTP von der CUCM-IP-Adresse und dem Port 4000 stammen soll. RTP wird von einem anderen Port empfangen und vom Voice Router verworfen.
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 (VoIP-RTP-Verbindungen anzeigen) zeigt das RmtRTP als 4000 und RemoteIP als CUCM-IP-Adresse an.
Der Router erwartet, dass das RTP von derselben Quelle stammt.
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
Mit einer Sniffer-Erfassung kann überprüft werden, woher das RTP tatsächlich stammt. In diesem Beispiel stammt es vom Port 24588 anstelle von 4000, sodass die Quellvalidierung fehlschlägt und der Voice Router die Pakete verwirft.
Sprach-RTP-Quellfilter
Diese Funktion wurde in den IOS-Versionen 15.5(3)M9, 15.6(3)M6 eingeführt.
Es funktioniert genauso wie der Quellfilter, bei dem zunächst die Quell-IP-Adresse und dann der Quellport validiert werden, weist jedoch zwei wesentliche Unterschiede auf.
- Voice RTP Source-Filter funktioniert für SIP, H.323, MGCP und SCCP.
- Die Funktion hat außerdem eine Fehlermeldung in Debug VoIP RTP Error hinzugefügt, um leicht zu erkennen, wann das RTP aufgrund eines Fehlers bei der Quellvalidierung verloren geht
Konfiguration
Configuration Terminal voice rtp source-filter
Verhalten und Erkennung pro Protokoll
Für H.323:
Debug H225 Asn1 auf Voice Routern zeigt ein openLogicalChannelAck an, das den Router über die Remote-Medienadresse 0.0.0.0:0 informiert.
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 zeigt keine RX-Erhöhungen an, und Remote-IP-Adresse und Port sind auf 0.0.0.0:0 eingestellt.
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 (VoIP-RTP-Verbindungen anzeigen) zeigt das RmtRTP und RemoteIP als 0.0.0.0:0 an, sodass der Router das RTP von dieser Quelle erwartet.
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
Mit einer Sniffer-Erfassung kann überprüft werden, wo das RTP empfangen wird. In diesem Beispiel wird sie von Port 24608 und CUCM-IP-Adresse anstelle von Port 0 und IP-Adresse 0.0.0.0 empfangen.
Der Debug VoIP RTP-Fehler zeigt den Grund für diese verworfenen Pakete an, die von der CUCM-IP-Adresse anstelle von 0.0.0.0 empfangen wurden, sodass die Quellvalidierung fehlschlägt.
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
Für SIP:
Die Debug-CCSIP-Nachrichten zeigen auf dem Voice Router eine SIP-ACK-Nachricht an, die mit SDP empfangen wurde. Dadurch wird der Router angewiesen, RTP von der CUCM-IP-Adresse und dem Port 4000 zu erwarten.
//-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
Die Anzeige "Call Active Voice Brief" zeigt keine RX-Erhöhungen für den Abschnitt an, der erwartet, dass RTP von CUCM-IP-Adresse:4000 empfangen wird.
Da das RTP tatsächlich von einem anderen Port stammt, wird es verworfen.
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 (VoIP-RTP-Verbindungen anzeigen) zeigt das RmtRTP und RemoteIP als CUCM-IP-Adresse:4000 an. Der Router erwartet, dass das RTP von dieser Quelle stammt.
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
Mit einer Sniffer-Erfassung kann überprüft werden, woher das RTP tatsächlich stammt. In diesem Beispiel stammt es von Port 24634 und CUCM-IP-Adresse anstelle von CUCM-IP-Adresse:4000.
Der Debug VoIP RTP-Fehler zeigt den Grund für die vom Port 24634 anstatt von Port 4000 empfangenen verlorenen Pakete an, sodass die Quellvalidierung fehlschlägt.
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
Für MGCP:
Debug MGCP Packets zeigt an, wann der Anruf zunächst Medien ausgehandelt hat und wann er dann in die Haltestellung versetzt wird.
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 <---
Die Anzeige "Call Active Voice Brief" zeigt keine RX-Erhöhungen für den Abschnitt an, der erwartet, dass RTP von der IP-Telefon-IP-Adresse:23248 kommt.
Da das RTP tatsächlich von einer anderen IP-Adresse stammt, wird es verworfen.
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 (VoIP-RTP-Verbindungen anzeigen) zeigt das RmtRTP und RemoteIP als IP-Adresse des IP-Telefons:23248 an. Der Router erwartet, dass das RTP von dieser Quelle stammt.
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
Mit einer Sniffer-Erfassung kann überprüft werden, woher das RTP tatsächlich stammt. In diesem Beispiel stammt es von Port 24612 und CUCM-IP-Adresse anstatt von IP-Telefon-IP-Adresse:23248.
Der Debug VoIP RTP-Fehler zeigt den Grund für diese verworfenen Pakete an, die von der CUCM-IP-Adresse anstelle von der IP-Telefon-IP-Adresse empfangen wurden, sodass die Quellvalidierung fehlschlägt.
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
Für SCCP:
Debug SCCP Messages (SCCP-Nachrichten debuggen) zeigt an, wann der Anruf gehalten wird.
Der CUCM weist den Voice-Router zunächst an, auf inaktive Medien mit einem CloseReceive-Channel und einer StoppMediaTransmission umzuschalten.
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
Dann weist CUCM den Sprach-Router an, den Umschlag mit einem OpenReceiveChannel umzuschalten.
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 (SCCP-Verbindungen anzeigen) zeigt den Ripadr und die Ports 0.0.0.0:0; Der Router erwartet, dass das RTP von dieser Quelle stammt.
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
Der Debug VoIP RTP-Fehler zeigt den Grund für diese verworfenen Pakete an, die von der CUCM-IP-Adresse anstelle von 0.0.0.0 empfangen wurden, sodass die Quellvalidierung fehlschlägt.
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
RTP-Quellvalidierung auf IOS-XE Voice Routern
Die wichtigsten Punkte, die in IOS-XE hervorgehoben werden sollten, sind:
- Es ist nicht konfigurierbar
- Diese Funktion ist standardmäßig aktiviert.
- Kann nicht deaktiviert werden
- Die Medienrichtung in der VoIP-Signalisierung ist die einzige Ausnahme, die es dem RTP ermöglicht, aus einer unbekannten Quelle zu fließen.
Verhalten und Erkennung pro Protokoll
Für H.323:
Bei diesem Protokoll funktioniert RTP von Warteschleifenmusik nicht, da CUCM immer die openLogicalChannelAck-Nachricht sendet, wobei IP-Adresse und Port auf Nullen festgelegt sind, wodurch die Medien deaktiviert werden.
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
Dasselbe kann mit Show Call Active Voice Brief überprüft werden, um zu überprüfen, wie der RX den Wert erhöht und die Remote-Medienadresse IP 0.0.0.0:0 lautet.
11F3 : 17 8703830ms.1 (13:00:22.060 CDT Tue Apr 23 2019) +2150 pid:2 Answer 6002 active dur 00:15:22 tx:19014/9213600 rx:1/3836010 dscp:0 media:0 audio tos:0x0 video tos:0x0 Tele 0/1/1:23 (17) [0/1/1.23] tx:158740/106870/0ms g711ulaw noise:-68 acom:22 i/0:-57/-61 dBm 11F3 : 18 8703830ms.2 (13:00:22.060 CDT Tue Apr 23 2019) +2150 pid:1 Originate 55002 active dur 00:15:22 tx:19709/3836010 rx:46068/9213600 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP 0.0.0.0:0 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No ICE: Off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a LostPacketRate:0.00 OutOfOrderRate:0.00
Debug Voip FPI Inout zeigt kein NAT-Flag (Network Address Translation) an, das hier aktiviert ist, da die Medien mit dem openLogicalChannelAck deaktiviert wurden, Medien können mit der Nachrichtenseite SIDE_A, rtp_type:0: überprüft werden.
//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 Gesamtzahl der blockierten Pakete|Verworfene Pakete: Zeigt eine Tabelle mit allen verworfenen Paketen an, in denen der Eingangs-Fluss während des gehaltenen Anrufs deaktiviert wird.
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
Für SIP
Bei Verwendung von SIP sendet CUCM im SDP die CUCM-IP-Adresse, das Port 4000 und das Medienattribut in Richtung a=sendonly, wodurch der Router angewiesen wird, nur RTP zu empfangen.
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
Der Befehl a=sendonly legt die Medienrichtung so fest, dass sie für die Perspektive des Voice Routers zurückgegeben wird. Dies löst die NAT-Flag-Funktion aus, die das Durchlaufen des RTP auch dann ermöglicht, wenn es von einer anderen Quelle stammt.
Dies kann mit Debug VoIP FPI Inout überprüft werden.
//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
Wenn in diesem Fall ein anderes Attribut für die Medienrichtung an den Voice Router gesendet wird, wird die NAT-Flag-Funktion nicht aktiviert und Pakete werden verworfen, da sie von einer anderen Quelle stammen.
Das Debuggen von CCSIP-Meldungen wird in diesem Beispiel a=sendrecv angezeigt.
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 zeigt die Medienrichtung auf rtp_type:3:SENDRECV und keine Funktion für NAT-Flag an.
//27/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2
Da kein NAT-Flag vorhanden ist, ist die aktive Funktion "show platform hardware qfp" sbc global | s Gesamtzahl der verworfenen Pakete|Verworfene Pakete: Zeigt die Inkremente im Abschnitt "Falsche Quelle für Datenfluss" an.
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
Für MGCP:
Wenn MGCP verwendet wird, sendet der CUCM einen MDCX, um die Medienrichtung zu ändern, die bereits beim ursprünglichen Verbindungsaufbau ausgehandelt wurde. Somit ändert sich die IP-Adresse oder die Signalisierung nicht. Nach dem MDCX wird das RTP nun jedoch von einer anderen Quelle gestreamt.
Da M: recvonly wird an den Voice Router gesendet, die NAT-Flag-Funktion wird aktiviert.
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 zeigt die Medienrichtung an, die auf rtp_type:2:RECVONLY und NAT-Flag festgelegt ist, wodurch das RTP durchfließen kann.
//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
Wenn in diesem Fall ein anderes Attribut für die Medienrichtung an den Voice Router gesendet wird, wird die NAT-Flag-Funktion nicht aktiviert und Pakete werden verworfen, da sie von einer anderen Quelle stammen.
Debuggen von MGCP-Paketen wird in diesem Beispiel 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 zeigt die Medienrichtung auf rtp_type:3:SENDRECV und keine Funktion für NAT-Flag an.
//29/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2
Da kein NAT-Flag vorhanden ist, ist die aktive Funktion "show plattform hardware qfp" sbc global | s Gesamtzahl der verworfenen Pakete|Verworfene Pakete: Zeigt die Inkremente im Abschnitt "Falsche Quelle für Datenfluss" an.
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
Für SCCP:
Debug SCCP Messages (SCCP-Nachrichten debuggen) zeigt an, wann der Anruf gehalten wird.
Der CUCM weist den Voice-Router zunächst an, zu einem inaktiven Medium mit einem CloseReceiveChannel und einer StopMediaTransmission zu wechseln.
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
Dann weist CUCM den Sprach-Router an, den Ruhemodus mit einem OpenReceiveChannel zu ändern.
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 (SCCP-Verbindungen anzeigen) zeigt den Ripadr und die Ports 0.0.0.0:0; Der Router erwartet, dass das RTP von dieser Quelle stammt.
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 zeigt die Medienrichtung an, die auf rtp_type:2:RECVONLY und NAT-Flag festgelegt ist, wodurch das RTP durchfließen kann.
//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
Wenn die Medienrichtung auf sendonly oder sendrecv festgelegt ist und das RTP von einer anderen Quelle stammt, dann wird kein NAT-Flag aktiviert und die aktive Funktion "show plattform hardware qfp" sbc global aktiviert | s Gesamtzahl der blockierten Pakete|Verworfene Pakete: Zeigt verworfene Pakete an.
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)