IOS和IOS-XE語音路由器中的RTP源驗證
目錄
簡介
本檔案介紹Cisco IOS和IOS-XE語音路由器中適用於不同通話流程和版本的RTP來源驗證功能的行為。
必要條件
需求
思科建議您瞭解以下主題：
- IOS和IOS-XE軟體
- H.323
- 作業階段啟始通訊協定(SIP)
- 媒體閘道控制通訊協定(MGCP)
- 精簡型通話控制通訊協定(SCCP)
- 即時傳輸通訊協定(RTP)
採用元件
本文中的資訊係根據以下軟體和硬體版本：
- ISRG2路由器(ISR2900、ISR3900)
- ISRG3路由器（ISR4400和ISR4300）
- ASR路由器（帶RP2和ESP40的ASR1001-X、ASR1002-X、ASR1004、ASR1006和ASR1006-X）
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
背景資訊
為了能夠充分利用本文檔，瞭解VoIP網路和VoIP信令協定的基礎知識非常重要。
RTP源驗證定義和用途
RTP源驗證是Cisco語音路由器中整合的一項功能，允許它們丟棄不受信任的入站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源過濾器
源篩選器
此功能僅適用於SIP呼叫流。
配置後，如果呼叫流中使用的信令未協商RTP來自的IP地址和埠，則語音路由器會丟棄這些資料包。
來源驗證會檢查來源IP地址，然後檢查來源連線埠。
組態
voice service voip sip source filter
行為和檢測
一個很好的例子是，CUCM將呼叫置於保持狀態，並且預設情況下，CUCM通過信令通告埠4000，但實際上是從臨時埠(32768-61000)流傳輸RTP，因為預設情況下禁用了Clusterwide Parameters下的服務引數Duplex Streaming。
Debug CCSIP Messages在語音路由器上顯示使用會話描述協定(SDP)接收的SIP ACK消息，告知路由器的RTP來自CUCM-IP-Address 和Port 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不會顯示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實際上來自何處，在本範例中，它來自連線埠2458，而不是4000，因此來源驗證失敗，且語音路由器捨棄封包。
語音RTP來源過濾器
此功能在15.5(3)M9、15.6(3)M6 IOS版本中引入。
其工作方式與來源過濾器相同，它首先驗證來源IP位址，然後驗證來源連線埠，但具有兩個主要差異。
- 語音RTP源過濾器適用於SIP、H.323、MGCP和SCCP
- 此功能還在Debug VoIP RTP Error中新增了錯誤消息，以便輕鬆檢測由於源驗證失敗而丟棄RTP的時間
組態
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 顯示從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在語音路由器上顯示SIP ACK消息，該消息通過SDP接收，指示路由器期望從CUCM-IP-Address和Port 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實際上來自何處，在本範例中，它來自連線埠24634和CUCM-IP-Address，而不是CUCM-IP-Address:4000。
Debug VoIP RTP Error 顯示從埠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不會顯示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實際上來自何處，在本範例中，它來自連線埠24612和CUCM-IP-Address，而不是IP-Phone-IP-Address:23248。
Debug VoIP RTP Error 顯示從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:
Debug SCCP Messages顯示呼叫被置於保持狀態的時間。
CUCM首先指示語音路由器使用CloseReceiveChannel和StopMediaTransmission切換到inactive介質。
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 顯示從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中需要強調的最重要內容是。
- 不可配置
- 預設情況下啟用
- 無法禁用
- 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
Debug Voip FPI Inout不顯示Network Address Translation(NAT)Flag在此處啟用，因為使用openLogicalChannelAck禁用了媒體，可以使用消息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、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通過，即使它來自其他源。
這可透過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標誌功能，並且資料包將被丟棄，因為它們來自不同的源。
Debug CCSIP Messages顯示在此示例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|Dropped packets：顯示Wrong source for flow部分中的增量數量。
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|Dropped packets：顯示Wrong source for flow部分中的增量數量。
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:
Debug SCCP Messages顯示呼叫被置於保持狀態的時間。
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
如果媒體方向設定為sendonly或sendrecv，並且RTP來自其他源，則不啟用NAT標誌，並且show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets：顯示packets dropped。
意見