Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Definition und Verwendung der RTP-Quellvalidierung

RTP-Quellvalidierung in IOS-Sprach-Routern

Quellfilter

Konfiguration

Verhalten und Erkennung

Sprach-RTP-Quellfilter

Konfiguration

Verhalten und Erkennung pro Protokoll

RTP-Quellvalidierung auf IOS-XE Voice Routern

Verhalten und Erkennung pro Protokoll

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

Vorsicht:Beachten Sie, dass die Szenarien, die in den nächsten Abschnitten behandelt werden, mit der Warteschleifenmusik von Cisco Unified Communications Manager (CUCM) zusammenhängen. Es gibt jedoch andere Situationen, in denen dasselbe Verhalten die Funktion dazu veranlasst, das RTP zu verwerfen, solange die Anforderungen erfüllt werden.

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.

1. Voice RTP Source-Filter funktioniert für SIP, H.323, MGCP und SCCP.

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

Vorsicht: Diese Funktion ist standardmäßig aktiviert und wird nicht in der Konfiguration angezeigt. Upgrades auf IOS-Versionen, die diese Funktion unterstützen, können zu Audioproblemen führen, wenn Geräte RTP von einer anderen Quelle als der über die Signalisierung gesendeten senden.

Wenn die Funktion durch mit einem Nein vor dem Befehl deaktiviert wird, wird sie in der Konfiguration angezeigt.

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:

1. Es ist nicht konfigurierbar

2. Diese Funktion ist standardmäßig aktiviert.

3. Kann nicht deaktiviert werden

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

Warnung: RX und TX inkrementieren IOS-XE-Plattformen nur, wenn der Media Bulk-Stats-Befehl unter Voice Service VoIP konfiguriert ist, aber beachten Sie, dass dieser Befehl die Leistung des Routers beeinflussen kann. Es wird daher empfohlen, ihn nur bei der Fehlerbehebung zu aktivieren und anschließend zu deaktivieren.

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

Tipp: OpenReceiveChannel-Nachrichten werden verwendet, um den Sprach-Router anzuweisen, RTP zu empfangen, und der Voice Router teilt dem CUCM über den OpenReceiveChannelAck mit, an den dieser Datenträger gesendet werden soll.

Die StartMediaTransmission-Nachricht wird verwendet, um den Sprach-Router anzuweisen, RTP an das angegebene Ziel zu senden.

Mit anderen Worten: Wenn nur OpenReceiveChannel ausgetauscht wird, kann der Medienressource mitgeteilt werden, dass sie nur RTP empfängt (rekvonly), und wenn nur StartMediaTransmission ausgetauscht wird, kann der Medienressource, die sie sendet (sendonly), aber wenn beide ausgetauscht werden, die sendrecv entspricht.

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.

Tipp: Wenn RTP von einer anderen Adresse als der über die Signalisierung ausgehandelten empfangen werden muss und Recover nicht verwendet werden kann, nat force-on unter Voip des Sprachdienstes, kann Sip verwendet werden, um eine manuelle Verwartung hinzuzufügen. Dies funktionierte zuvor nicht ordnungsgemäß, wurde aber bei einem Fehler behoben. CSCvo15141 . Beachten Sie, dass dies nur für SIP funktioniert.

Warnung: Wenn Pass-Thru-Content-Sdp unter Voice-Service-VoIP, sip konfiguriert ist, kann die FPI-Ebene die NAT-Flag-Funktion nicht aktivieren, wenn eine Wiederherstellung erfolgt.

Tipp: In einigen Situationen, in denen NAT-Flag für einen Anruf aktiv ist und die Audiofunktion einwandfrei funktioniert, wird der Paketwert unter show platform hardware qfp active feature sbc global verworfen. | insgesamt verworfene Pakete|Verworfene Pakete: kann sich jedoch noch wesentlich langsamer erhöhen, da in einigen Situationen und Anrufabläufen das Real Time Control Protocol (RTCP) immer noch von einer anderen Quelle an den Voice Router gesendet werden kann, die dieses Verhalten verursachen würde.