内容

概要

前提条件

要件

使用するコンポーネント

背景説明

RTPソース検証定義および使用

IOS音声ルータでのRTPソース検証

ソースフィルタ

コンフィギュレーション

動作と検出

音声RTPソースフィルタ

コンフィギュレーション

プロトコルごとの動作と検出

IOS-XE音声ルータのRTPソース検証

プロトコルごとの動作と検出

概要

このドキュメントでは、さまざまなコールフローとバージョンのCisco IOSおよびIOS-XE音声ルータにおけるRTPソース検証機能の動作について説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

- IOSおよびIOS-XEソフトウェア

- H.323

- Session Initiation Protocol（SIP）

- Media Gateway Control Protocol（MGCP）

- Skinny Call Control Protocol（SCCP）

- Real-Time Transport Protocol（RTP; リアルタイム転送プロトコル）

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

- ISRG2ルータ(ISR2900、ISR3900)

- ISRG3ルータ（ISR4400およびISR4300）

- ASRルータ（ASR1001-X、ASR1002-X、ASR1004、ASR1006、ASR1006-X、RP2およびESP40搭載）

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

このドキュメントを最大限に活用するには、VoIPネットワークとVoIPシグナリングプロトコルの基本を理解することが重要です。

RTPソース検証定義および使用

RTPソース検証は、Cisco音声ルータに統合された機能で、信頼できない着信RTPトラフィックを廃棄できます。

この機能の主な目的は、デバイスのセキュリティレベルを高くし、VoIPネットワークでのCrossTalkの問題を回避することです。

IOS音声ルータでは、この機能の種類が異なり、IOS-XE音声ルータでは1つのオプションがあります。

IOSおよびIOS-XEでは、この機能により、音声ルータは不明なIPアドレスまたはポートからの着信RTPトラフィックをドロップします。つまり、シグナリングを介してネゴシエートされなかったIPアドレスまたはポートからのパケットは、音声ルータによってドロップされます。

この機能がIOSおよびIOS-XEで動作する方法は、ルータのアーキテクチャとコードへの導入時期によって若干異なります。次のセクションでは、これらのシナリオについて説明します。

IOS音声ルータでのRTPソース検証

IOSには、この機能の2つの異なる種類があります。

- 12.4(6)Tで導入されたソースフィルタ

- Voice RTP Source-Filter:15.5(3)M9、15.6(3)M6以降のバージョンで導入されました。

注意：次のセクションで説明するシナリオはCisco Unified Communications Manager(CUCM)保留音(MoH)に関するものですが、他の状況では、要件が満たされている限り、同じ動作がRTPのドロップをトリガーします。

ソースフィルタ

この機能は、SIPコールフローでのみ使用できます。

設定されている場合、コールフローで使用されるシグナリングが、RTPの送信元であるIPアドレスとポートをネゴシエートしなかった場合、音声ルータはそれらのパケットを廃棄します。

ソース検証では、ソースIPアドレス、次にソース・ポートがチェックされます。

コンフィギュレーション

voice service voip

sip

source filter

動作と検出

CUCMがコールを保留にし、デフォルトでCUCMがシグナリングを通じてポート4000をアドバタイズして、サービスパラメータの[Duplex Streaming Enabled]が[Clusterwide Parameters]の下にあるので、実際にRTPをストリーミングします はデフォルトで無効になっています。

Debug CCSIP Messagesは、RTPがCUCM-IP-Addressとポート4000から着信したことをルータに通知するSession Description Protocol(SDP)を使用して受信したSIP ACKメッセージを音声ルータでに表示します。

//-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は、RTPがCUCM-IP-Addressとポート4000から着信すると予想されるレッグでRXの増加を表示しません。RTPは別のポートから受信し、音声ルータでドロップです。

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では、RmtRTPは4000、RemoteIPはCUCM-IP-Addressと表示されます。

ルータは、RTPがその同じ送信元から来ることを期待します。

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

スニファキャプチャを使用すると、RTPが実際に着信した場所を確認できます。この例では、4000ではなくポート24588から着信します。これにより、発信元の検証が失敗し、音声ルータでパケットが廃棄されます。

音声RTPソースフィルタ

この機能は、15.5(3)M9、15.6(3)M6 IOSバージョンで導入されました。

これは、最初に送信元IPアドレスを検証し、次に送信元ポートを検証するソースフィルタと同じ方法できますが、大きく2つの違いがあります。

1. 音声RTPソースフィルタは、SIP、H.323、MGCP、およびSCCPで動作します

2. また、この機能は、ソース検証の失敗が原因でRTPがドロップされた場合を簡単に検出するために、「Debug VoIP RTP Error」にエラーメッセージを追加しました

注意：この機能はデフォルトで有効になっており、設定には表示されません。この機能をサポートするIOSリリースにアップグレードすると、シグナリングでアドバタイズされたデバイスとは異なる送信元からRTPを送信するデバイスがある場合に、音声の問題が発生する可能性があります。

コマンドの前にNoを付けて機能を無効にすると、設定に表示されます。

コンフィギュレーション

Configuration Terminal

voice rtp source-filter

プロトコルごとの動作と検出

H.323の場合：

音声ルータ上のH225 Asn1のデバッグには、リモートメディアアドレス0.0.0.0:0についてルータに通知するopenLogicalChannelAckが受信されたことが示されます。

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はRXの増加を示さず、リモートIPアドレスとポートは0.0.0.0:0に設定されています。

11F5 : 21 18903090ms.1 (16:00:48.794 CDT Fri Apr 19 2019) +1070 pid:2 Answer 6002 active

dur 00:00:43 tx:376/63168 rx:899/137074 dscp:0 media:0 audio tos:0x0 video tos:0x0

Tele 0/1/0:23 (21) [0/1/0.1] tx:35340/14230/0ms g711ulaw noise:-68 acom:3  i/0:-64/-63 dBm

11F5 : 22 18903090ms.2 (16:00:48.794 CDT Fri Apr 19 2019) +1070 pid:1 Originate 36004 active

dur 00:00:43 tx:152/23047 rx:376/60160 dscp:0 media:0 audio tos:0xB8 video tos:0x0

IP 0.0.0.0:0 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/65/65ms g711ulaw TextRelay: off Transcoded: No ICE: Off

media inactive detected:n media contrl rcvd:n/a timestamp:n/a

long duration call detected:n long duration call duration:n/a timestamp:n/a

LostPacketRate:0.00 OutOfOrderRate:0.00

LocalUUID:

RemoteUUID:

VRF:

Show VoIP RTP Connectionsでは、RmtRTPとRemoteIPが0.0.0.0:0と表示され、ルータはその送信元からのRTPを想定しています。

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

スニファキャプチャを使用すると、RTPが受信された場所を確認できます。この例では、ポート0とIPアドレス0.0.0.0の代わりに、ポート24608とCUCM-IP-Addressから受信されます。

Debug VoIP RTP Errorは、0.0.0.0ではなく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

voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet.

Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address

SIP:

デバッグCCSIPメッセージは、SDPを使用して受信されたSIP ACKメッセージを音声ルータに表示します。SDPは、CUCM-IP-Addressおよびポート4000からRTPを受けするように指示します。

//-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は、CUCM-IP-Address:4000からRTPを受信する必要があるレッグでRX増分を表示しません。

RTPは実際には別のポートから送信されるため、ドロップされます。

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は、RmtRTPとRemoteIPをCUCM-IP-Address:4000と表示します。ルータはRTPがその送信元から来ることを想定しています。

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

スニファキャプチャを使用すると、RTPの実際の送信元を確認できます。この例では、RTPの送信元はCUCM-IP-Address:4000ではなく、ポート24634とCUCM-IP-Addressです。

Debug VoIP RTP Errorは、ポート4000ではなくポート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

voip_rtp_recv_fs_input:ERROR Port validation failed, dropping RTP packet.

Expected port: 4000, Received port: 24634

MGCPの場合：

Debug MGCP Packetsは、コールが最初にメディアをネゴシエートした時点と、その後で保留状態になった時点を示します。

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は、RTPがIP-Phone-IP-Address:23248から来ることを期待するレグで、RXの増加を表示しません。

RTPは実際には別のIPアドレスから送信されるため、ドロップされます。

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は、RmtRTPとRemoteIP をIP-Phone-IP-Address:23248と表示します。ルータはRTPがその送信元から来ることを想定しています。

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

スニファキャプチャを使用すると、RTPの実際の送信元を確認できます。この例では、RTPの送信元はIP-Phone-IP-Address:23248ではなく、ポート24612とCUCM-IP-Address-Addressです。

Debug VoIP RTP Errorは、IP-Phone-IP-Addressの代わりに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

voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet.

Expected addr: IP-Phone-IP-Address, Received addr: CUCM-IP-Address

SCCPの場合：

SCCPメッセージのデバッグは、コールが保留にされたときに表示されます。

CUCMは最初に、CloseReceiveChannelと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

次に、CUCMは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は、ripaddrとrportas 0.0.0.0:0を示します。ルータはRTPがその送信元から来ることを想定しています。

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は、0.0.0.0ではなくCUCM-IP-Addressから受信したパケットがドロップされた理由を示し、ソースの検証に失敗します。

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

IOS-XE音声ルータのRTPソース検証

IOS-XEで特に重要なことは、次のとおりです。

1. これは設定できません

2. デフォルトで有効になっています

3. 無効にできません

4. VoIPシグナリングのメディア方向は、不明な送信元からのRTPの流れを許可する唯一の例外です

プロトコルごとの動作と検出

H.323の場合：

このプロトコルでは、MoHからのRTPは機能しません。CUCMは、メディアを無効にするIPアドレスとポートがゼロに設定されたopenLogicalChannelAckメッセージを常に送信します。

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

Show Call Active Voice Briefを使用して、RXのインクリメント値が停止し、リモートメディアアドレスが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

警告：RXとTXは、Voice Service VoIPでMedia Bulk-Statsコマンドが設定されていない限り、IOS-XEプラットフォームでは増加しません。ただし、このコマンドはルータのパフォーマンスに影響する可能性があるため、トラブルシューティング後は無効のみ。

Debug Voip FPI Inoutは、メディアがopenLogicalChannelAckで無効になったため、ここで有効になっているネットワークアドレス変換(NAT)フラグを表示しません。メディアが無効になっているかどうかは、side: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 total packets dropped|Dropped packets：コールの保留時に入力フローが無効の増分を受信した場合には、ドロップされたすべてのパケットを示すテーブルが表示されます。

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

SIP

SIPを使用すると、CUCMはSDPにCUCM-IP-Address、ポート4000、および方向用のメディア属性をa=sendonlyとして送信し、ルータに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

a=sendonlyは、音声ルータの観点からメディア方向をrecvonlyに設定して、NATフラグ機能をトリガーします。これにより、RTPが別の送信元から送信されても、RTPが通過できます。

これは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

これが発生したときにメディア方向の別の属性が音声ルータに送信された場合、NATフラグ機能は有効ではなく、パケットは別の送信元から送信されるためドロップされます。

CCSIPメッセージのデバッグは、この例の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は、メディアの方向がrtp_type:3:SENDRECVに設定され、NATフラグ機能がない状態を示します。

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

NATフラグが存在しないため、show platform hardware qfp active feature sbc global | s total packets dropped|ドロップされたパケット：フローのソースが正しくないセクションに増分が表示されます。

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

MGCPの場合：

MGCPを使用すると、CUCMはMDCXを送信して、コールが最初に接続されたときにネゴシエート済みのメディア方向を変更します。そのため、IPアドレスやシグナリングは変更されませんが、MDCXの後にRTPは別のソースからストリームされます。

M以来：recvonlyが音声ルータに送信され、NATフラグ機能が有効になります。

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は、メディア方向がrtp_type:2:RECVONLYに設定され、NATフラグ機能が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

これが発生したときにメディア方向の別の属性が音声ルータに送信された場合、NATフラグ機能は有効ではなく、パケットは別の送信元から送信されるためドロップされます。

Debug MGCP Packetsを次の例の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は、メディアの方向がrtp_type:3:SENDRECVに設定され、NATフラグ機能がない状態を示します。

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

NATフラグがないため、show platform hardware qfp active feature sbc global | s total packets dropped|ドロップされたパケット：フローのソースが正しくないセクションに増分が表示されます。

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

SCCPの場合：

SCCPメッセージのデバッグは、コールが保留にされたときに表示されます。

CUCMは最初に、CloseReceiveChannelと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

次に、CUCMは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は、ripaddrとrportas 0.0.0.0:0を示します。ルータはRTPがその送信元から来ることを想定しています。

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は、メディア方向がrtp_type:2:RECVONLYに設定され、NATフラグ機能が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

ヒント:OpenReceiveChannelメッセージは、音声ルータにRTPを受信するように指示するために使用され、音声ルータはCUCMにそのメディアを受信するOpenReceiveChannelAckを伝えます。

StartMediaTransmissionメッセージは、指定された宛先にRTPを送信するように音声ルータに指示するために使用されます。

つまり、OpenReceiveChannelのみが交換される場合は、メディアリソースに対してRTPのみ(recvonly)を受信し、StartMediaTransmissionのみが交換される場合は、メディアリソースにRTPのみ(sendonly)を送信します回収

メディア方向がsendonlyまたはsendrecvに設定されていて、RTPが別の送信元から送信された場合、NAT flagはアクティブ化されず、show platform hardware qfp active feature sbc global | s total packets dropped|ドロップされたパケット：ドロップされたパケットを示します。

ヒント：シグナリングを通じてネゴシエートされたアドレスとは異なるアドレスから発信されたRTPを使用できない場合は、nat force-onをVoice Service Voipの下で使用し、Sipを使用して手動で予測できます。これは以前は正常に動作していませんでしたが、不具合で修正されました CSCvo15141 .これはSIPでのみ機能することに注意してください。

警告：voice service voipでpass-thru content sdpが設定されている場合、sipが設定されていると、recvonlyを受信したときにFPIレイヤがNAT Flag機能をアクティブにすることはできません。

ヒント：あるコールでNATフラグがアクティブで、音声が正常に動作している場合は、show platform hardware qfp active feature sbc globalでパケット値がドロップされます | s Total packets dropped|ドロップされたパケット：は、より低いレートでも増加する可能性があります。これは、状況やコールフローによっては、Real Time Control Protocol(RTCP)を音声ルータに送信し、この動作を引き起こす別のソースから送信できる場合があるためです。