IOS和IOS-XE语音路由器中的RTP源验证

简介

本文档介绍不同呼叫流和版本的Cisco IOS和IOS-XE语音路由器中RTP源验证功能的行为。

先决条件

要求

Cisco 建议您了解以下主题：

• IOS和IOS-XE软件
• H.323
• 会话初始协议 (SIP)
• Media Gateway Control Protocol (MGCP)
• 瘦呼叫控制协议(SCCP)
• 实时传输协议 (RTP)

使用的组件

本文档中的信息基于以下软件和硬件版本：

• ISRG2路由器(ISR2900、ISR3900)
• ISRG3路由器（ISR4400和ISR4300）
• ASR路由器（ASR1001-X、ASR1002-X、ASR1004、ASR1006和ASR1006-X，带RP2和ESP40）

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

了解VoIP网络和VoIP信令协议的基础知识非常重要，以便能够充分利用本文档。

RTP源验证定义和使用

RTP源验证是思科语音路由器中集成的一项功能，允许它们丢弃不受信任的入站RTP流量。

此功能的主要目标是提高设备的安全级别，并避免VoIP网络上的CrossTalk问题。

IOS语音路由器和IOS-XE语音路由器中有不同的功能和单一选项。

在IOS和IOS-XE中，此功能使语音路由器丢弃来自未知IP地址或端口的入站RTP流量，换句话说，语音路由器丢弃从未通过信令协商的IP地址或端口接收的数据包。

此功能在IOS和IOS-XE中的工作方式略有不同，因为路由器的架构以及它们被引入代码时；接下来的部分介绍这些场景。

IOS语音路由器中的RTP源验证

IOS具有两种不同的功能。

• 12.4(6)T中引入的源滤波器
• 15.5(3)M9、15.6(3)M6及后一版本引入的语音RTP源过滤器

注意：请注意，下一部分介绍的场景是Cisco Unified Communications Manager(CUCM)暂候音乐(MoH)，但是，在满足要求时，同一行为会触发功能丢弃RTP的其他情况下。 

源过滤器

此功能仅对SIP呼叫流可用。

配置后，如果呼叫流中使用的信令未协商RTP的IP地址和端口，则语音路由器会丢弃这些数据包。

源验证先检查源IP地址，然后检查源端口。  

配置

voice service voip
 sip
  source filter

行为和检测

例如，CUCM将呼叫置于保持状态，并且默认情况下CUCM通过信令通告端口4000，但实际上从临时端口(32768-61000)流传输RTP，因为默认情况下，Clusterwide Parameters下的Service Parameter Duplex Streaming Enabled已禁用。

Debug CCSIP Messages在语音路由器上显示SIP ACK消息，该消息通过会话描述协议(SDP)接收，告知路由器RTP来自CUCM-IP-Address和端口4000。

//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received: 
ACK sip:6002@Router-IP-Address:5060 SIP/2.0
Via: SIP/2.0/UDP CUCM-IP-Address:5060;branch=z9hG4bK4a424fed85
From: <sip:65002@CUCM-IP-Address>;tag=4091~842780d9-7186-4740-ada2-23e5d1b91316-46404063
To: <sip:6002@Router-IP-Address>;tag=2FF652-51D
Date: Thu, 18 Apr 2019 19:59:50 GMT
Call-ID: 3EDDD9E4-614B11E9-800D9C4B-C5465DB2@Router-IP-Address
User-Agent: Cisco-CUCM12.0
Max-Forwards: 70
CSeq: 102 ACK
Allow-Events: presence
Session-ID: 4978aa3900105000a000006cbcbcfda2;remote=836b14b48c77bfe681c0780c54ab4091
Content-Type: application/sdp
Content-Length: 191

v=0
o=CiscoSystemsCCM-SIP 4091 3 IN IP4 CUCM-IP-Address
s=SIP Call
c=IN IP4 CUCM-IP-Address (MoH Server)
t=0 0
          
m=audio 4000 RTP/AVP 0
a=X-cisco-media:umoh
a=ptime:20
a=rtpmap:0 PCMU/8000
a=sendonly

Show Call Active Voice Brief不显示RX增量，其中RTP应来自CUCM-IP-Address和端口4000。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实际来自何处，在本例中，它来自端口24588而不是4000，因此源验证失败，语音路由器丢弃数据包。

语音RTP源过滤器

此功能在15.5(3)M9、15.6(3)M6 IOS版本中引入。

它的工作方式与源过滤器相同，它首先验证源IP地址，然后验证源端口，但有两个主要区别。

1. 语音RTP源过滤器适用于SIP、H.323、MGCP和SCCP
2. 该功能还在调试VoIP RTP错误中添加了错误消息，以便轻松检测何时由于源验证失败而丢弃RTP

警告：默认情况下，此功能已启用且不显示在配置中。如果有设备从不同的源发送RTP，而不是通过信令通告的源发送RTP，则升级到支持此功能的任何IOS版本可能会导致音频问题。
当在命令前面加上“否”时，该功能被禁用，然后在配置中显示。

配置

Configuration Terminal
 voice rtp source-filter

每个协议的行为和检测

对于H.323:

语音路由器上的调试H225 Asn1显示收到的openLogicalChannelAck，它通知路由器远程媒体地址0.0.0.0:0。

H245 MSC OUTGOING PDU ::=

value MultimediaSystemControlMessage ::= response : openLogicalChannelAck : 
    {
      forwardLogicalChannelNumber 1
      forwardMultiplexAckParameters h2250LogicalChannelAckParameters : 
      {
        mediaChannel unicastAddress : iPAddress : 
        {
          network 'Router-IP-Address'H
          tsapIdentifier 16404 (Router's UDP Port for the RTP)
        }
        mediaControlChannel unicastAddress : iPAddress : 
        {
          network 'Router-IP-Address'H
          tsapIdentifier 16405 (Router's UDP Port for the RTCP)
        }
        flowControlToZero FALSE
      }
    }



Received openLogicalChannelAck has network and tsapIdentifier for the mediaChannel in zeros which means IP Address 0.0.0.0 and port 0.

H245 MSC INCOMING PDU ::=

value MultimediaSystemControlMessage ::= response : openLogicalChannelAck : 
    {
      forwardLogicalChannelNumber 2
      forwardMultiplexAckParameters h2250LogicalChannelAckParameters : 
      {
        sessionID 1
        mediaChannel unicastAddress : iPAddress : 
        {
          network '00000000'H
          tsapIdentifier 0
        }
        mediaControlChannel unicastAddress : iPAddress : 
        {
          network '00000000'H
          tsapIdentifier 1
        }
      }
    }

Show Call Active Voice Brief不显示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的接收位置。在本示例中，它从端口24608和CUCM-IP-Address(而不是端口0和IP地址0.0.0.0)接收。

Debug VoIP RTP Error(调试VoIP RTP错误)显示从CUCM-IP-Address(而不是0.0.0.0)接收的丢弃数据包的原因，因此它未通过源验证。

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:

Debug CCSIP Messages在语音路由器上显示SDP收到的SIP ACK消息，该消息指示路由器期望从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不显示RX增量，该RTP预期从CUCM-IP-Address:4000收到。

由于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实际来自何处，在本例中，它来自端口24634 和CUCM-IP-Address，而不是CUCM-IP-Address:4000。

Debug VoIP RTP Error(调试VoIP RTP错误)显示从端口24634（而不是端口4000）接收的丢弃数据包的原因，因此它未通过源验证。

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(调试MGCP数据包)显示呼叫最初协商的介质的时间，以及呼叫被置于保持状态的时间。

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不显示RX增量，该RTP预期来自IP-Phone-IP-Address:23248。

由于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实际来自何处，在本例中，它来自端口24612和CUCM-IP-Address，而不是IP-Phone-IP-Address:23248。

Debug VoIP RTP Error(调试VoIP RTP错误)显示从CUCM-IP-Address(而非IP-Phone-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(调试VoIP RTP错误)显示从CUCM-IP-Address(而不是0.0.0.0)接收的丢弃数据包的原因，因此它未通过源验证。

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在IOS-XE平台中不会增加，除非在语音服务VoIP下配置Media Bulk-Stats 命令，但请注意，此命令可能影响路由器的性能，因此建议仅在进行故障排除时启用它，然后禁用它。

Debug Voip FPI Inout不显示此处启用的网络地址转换(NAT)标志，因为openLogicalChannelAck禁用了媒体，可以使用消息端: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丢弃的数据包总数|丢弃的数据包数：显示一个表，其中呼叫处于暂候时入口流接收被禁用的所有丢弃数据包数增加。

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、Port 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通过。

这可以通过调试VoIP FPI输出来检查。

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

如果发生此情况时将不同的Attribute for Media Direction发送到语音路由器，则不会激活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

调试VoIP FPI输出显示媒体方向设置为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已丢弃的数据包总数|已丢弃的数据包数：在“流的源错误”部分显示增量。

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

调试VoIP FPI输出显示媒体方向设置为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

如果发生此情况时将不同的Attribute for Media Direction发送到语音路由器，则不会激活NAT标志功能，并且数据包将被丢弃，因为它们来自不同的源。

调试MGCP数据包显示在本示例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
<---

调试VoIP FPI输出显示媒体方向设置为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已丢弃的数据包总数|已丢弃的数据包数：在“流的源错误”部分显示增量。

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

调试VoIP FPI输出显示媒体方向设置为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，而语音路由器通过OpenReceiveChannelAck告知CUCM要在何处接收该媒体。 
StartMediaTransmission消息用于指示语音路由器将RTP发送到指定的目标。

换句话说，如果只交换OpenReceiveChannel是通知媒体资源它只接收RTP(recvonly)的一种方式，并且如果只交换StartMediaTransmission，则是告知媒体资源它只发送RTP（仅发送）的一种方式，但如果交换了这两种方式，则它等于发送recv

如果媒体方向设置为sendonly或sendrecv，并且RTP来自不同的源，则不会激活NAT 标志，并且show platform hardware qfp active feature sbc global | s丢弃的数据包总数|丢弃的数据包：显示丢弃的数据包。

提示：如果需要允许来自不同于通过信令协商的地址的RTP，并且recvonly 不能使用，则语音服务Voip 下的nat force-on ,Sip可用于添加手动扩展。此问题以前无法正常工作，但已修复缺陷 CSCvo15141 。请记住，这仅适用于SIP。

警告：如果在语音服务voip下配置了sip ，则这不允许FPI层在收到recvonly时激活NAT标志功能。

提示：在NAT标志对呼叫处于活动状态且音频工作正常的某些情况下，在show platform hardware qfp active feature sbc global下丢弃的数据包值 |s丢弃的数据包总数|丢弃的数据包数：但速率仍然会提高，这是因为在某些情况下和呼叫流中，实时控制协议(RTCP)仍然可以发送到语音路由器，并且可以从其他源发送，这会导致此行为。