The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the behaviour of RTP Source Validation feature in Cisco IOS and IOS-XE Voice Routers for different call flows and versions.
Cisco recommends that you have knowledge of these topics:
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
It's important to understand basics of VoIP Networks and VoIP Signaling Protocols in order to be able to get full advantage of this document.
RTP Source Validation is a feature integrated in Cisco Voice Routers that allows them to drop untrusted inbound RTP traffics.
The main goal of this feature is to have a higher security level on the device and also avoid CrossTalk issues on VoIP Networks.
There are different flavors of this feature in IOS Voice Routers and one single option in IOS-XE Voice Routers.
In IOS and IOS-XE, this feature makes the Voice Routers drop inbound RTP Traffic from unknown IP addresses or ports, in other words packets received from an IP Address or Port that was not negotiated through signaling, are dropped by the Voice Router.
The way this feature works in IOS and IOS-XE is a little different due to the architecture of the Routers and when they were introduced into the code; Next sections explain those scenarios.
IOS has two different flavors of this feature.
Caution:Be aware that the scenarios covered in the next sections are with Cisco Unified Communications Manager (CUCM) Music on Hold (MoH), but there are other situations where the same behaviour triggers the feature to drop the RTP as long as the requirements are met.
This feature is only available for SIP call flows.
When configured, if the signaling used in the call flow did not negotiate the IP Address and Port where the RTP comes from, the Voice Router then discards those packets.
The Source Validation checks Source IP Address and then Source Port.
voice service voip sip source filter
A good example would be when CUCM puts a call on Hold and by default CUCM advertises port 4000 through signaling but actually streams the RTP from an ephemeral port (32768-61000) since the Service Parameter Duplex Streaming Enabled under Clusterwide Parameters is disabled by default.
Debug CCSIP Messages shows on the Voice Router a SIP ACK message received with Session Description Protocol (SDP) which tells the router the RTP comes from CUCM-IP-Address and 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 does not show RX increments on the leg where RTP is expected to come from CUCM-IP-Address and port 4000. RTP is received from a different port and dropped by the Voice Router.
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 shows the RmtRTP as 4000 and RemoteIP as CUCM-IP-Address.
The router expects the RTP to come from that same source.
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
With a sniffer capture, it can be verified where the RTP actually comes from, in this example its comes from port 24588 instead of 4000 so the source validation fails and the Voice Router drops the packets.
This feature was introduced in 15.5(3)M9, 15.6(3)M6 IOS Versions.
It works the same way as Source Filter where it validates first the Source IP Address and then the Source Port but has two major differences.
Caution: This feature comes enabled by default and does not appear in the configuration. Upgrades to any IOS release that supports this feature can result in audio issues if there are devices that send RTP from a different source than the one advertised over signaling.
When the feature is disabled by with a No in front of the command, it then shows in the configuration.
Configuration Terminal voice rtp source-filter
For H.323:
Debug H225 Asn1 on Voice Routers shows an openLogicalChannelAck received which informs the router about the remote media address 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 does not show RX increments and Remote IP Address and Port are set to 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 shows the RmtRTP and RemoteIP as 0.0.0.0:0 so the router expects the RTP from that source.
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
With a sniffer capture, it can be verified where the RTP is received. In this example, it is received from port 24608 and CUCM-IP-Address instead of Port 0 and IP Address 0.0.0.0.
Debug VoIP RTP Error shows the reason for those dropped packets as received from CUCM-IP-Address instead of 0.0.0.0, so it fails the source validation.
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
For SIP:
Debug CCSIP Messages shows on the Voice Router a SIP ACK message received with SDP which instructs the router to expect RTP from CUCM-IP-Address and 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=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 does not show RX increments on the leg that expects RTP to bereceived from CUCM-IP-Address:4000.
Since the RTP actually comes from another port, it is dropped.
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 shows the RmtRTP and RemoteIP as CUCM-IP-Address:4000, the router expects the RTP to come from that source.
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
With a sniffer capture, it can be verified where the RTP actually comes from, in this example its comes from port 24634 and CUCM-IP-Address instead of CUCM-IP-Address:4000.
Debug VoIP RTP Error shows the reason for those dropped packets as received from Port 24634 instead of Port 4000, so it fails the source validation.
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
For MGCP:
Debug MGCP Packets shows when the call initially negotiated media, and then when it is placed on hold.
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 does not show RX increments on the leg that expects RTP to come from IP-Phone-IP-Address:23248.
Since the RTP actually comes from another IP Address, it is dropped.
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 shows the RmtRTP and RemoteIP as IP-Phone-IP-Address:23248, the router expects the RTP to come from that source.
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
With a sniffer capture, it can be verified where the RTP actually comes from, in this example its comes from port 24612 and CUCM-IP-Address instead of IP-Phone-IP-Address:23248.
Debug VoIP RTP Error shows the reason for those dropped packets as received from CUCM-IP-Address instead of IP-Phone-IP-Address, so it fails the source validation.
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
For SCCP:
Debug SCCP Messages shows when the call is placed on hold.
CUCM first instructs the Voice Router to switch to media inactive with a CloseReceiveChannel and a 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
Then CUCM Instructs the Voice Router to switch to recvonly with an 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 shows the ripaddr and rportas 0.0.0.0:0; The router expects the RTP to come from that source.
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 shows the reason for those dropped packets as received from CUCM-IP-Address instead of 0.0.0.0, so it fails the source validation.
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
The most important things to highlight about it in IOS-XE are.
For H.323:
With this protocol, RTP from MoH does not work as CUCM always sends the openLogicalChannelAck message with IP Address and Port set to zeros which disables the media.
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
The same thing can be verified with Show Call Active Voice Brief in order to check how the RX increments value stops and the remote media Address is 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
Warning: RX and TX do not increment in IOS-XE Platforms unless Media Bulk-Stats command is configured under Voice Service VoIP, but be aware that this command can affect the performance of the router so it is recommended to only enable it when troubleshooting and disable it afterwards.
Debug Voip FPI Inout does not show Network Address Translation (NAT) Flag enabled here as the media got disabled with the openLogicalChannelAck, media disabled can be checked with the message 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: presents a table with all dropped packets where Ingress flow receive disabled increments while the call is on hold.
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
For SIP
When SIP is used, CUCM sends in the SDP the CUCM-IP-Address, Port 4000 and media attribute for direction as a=sendonly which instructs the router to receive RTP only.
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
The a=sendonly sets the media direction to recvonly for the Voice Router's perspective and this triggers the NAT flag function that still allows the RTP to go through even though it comes from a different source.
This can be checked with 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
If a different Attribute for Media Direction is sent to the Voice Router when this happens, NAT flag function won't be activated and packets would be dropped because they come from a different source.
Debug CCSIP Messages shows in this example 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 shows media direction set to rtp_type:3:SENDRECV and no NAT flag function.
//27/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2
As there is no NAT flag, the show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets: shows increments in the Wrong source for flow section.
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
For MGCP:
When MGCP is used, CUCM sends an MDCX in order to change the media direction already negotiated when the call originally connected, so no change in IP Address or Signaling, but after the MDCX the RTP is now streamed from another source.
Since M: recvonly is sent to the Voice Router, NAT flag function gets enabled.
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 shows media direction set to rtp_type:2:RECVONLY and NAT flag function, which allows the RTP to flow through.
//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
If a different Attribute for Media Direction is sent to the Voice Router when this happens, NAT flag function won't be activated and packets would be dropped because they come from a different source.
Debug MGCP Packets shows in this example 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 shows media direction set to rtp_type:3:SENDRECV and no NAT flag function.
//29/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2
As there is no NAT flag, the show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets: shows increments in the Wrong source for flow section.
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
For SCCP:
Debug SCCP Messages shows when the call is placed on hold.
CUCM first instructs the Voice Router to switch to media inactive with a CloseReceiveChannel and a 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
Then CUCM Instructs the Voice Router to switch to recvonly with an 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 shows the ripaddr and rportas 0.0.0.0:0; The router expects the RTP to come from that source.
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 shows media direction set to rtp_type:2:RECVONLY and NAT flag function, which allows the RTP to flow through.
//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
Tip: OpenReceiveChannel messages are used to instruct the Voice Router to receive RTP and the Voice Router tells CUCM over the OpenReceiveChannelAck where it wants to receive that media.
StartMediaTransmission message is used to instruct the Voice Router to send RTP to the specified destination.
In other words, if only OpenReceiveChannel is exchanged is a way to tell the media resource that it only receives RTP (recvonly) and if only StartMediaTransmission is exchanged, it is a way to tell the media resource it only sends RTP (sendonly), but if both are exchanged it is equal to sendrecv.
If the media direction is set to sendonly or sendrecv and the RTP comes from a different source, then no NAT flag is activated and the show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets: shows packets dropped.
Tip: If there is a need to allow RTP sourced from a different address than the one negotiated through signaling and recvonly can't be used, nat force-on under Voice Service Voip, Sip can be used to add a manual expection. This was previously not working properly but was fixed on defect CSCvo15141 . Keep in mind this only works for SIP.
Warning: If pass-thru content sdp under voice service voip, sip is configured, this does not allow the FPI layer to activate the NAT Flag Function when recvonly is received.
Tip: In some situations where NAT Flag is active for a call and audio works fine, dropped packets value under show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets: can still increase in a much lower rate, this is because in some situations and call flows, Real Time Control Protocol (RTCP) can still be sent to the Voice Router and from a different source which would cause this behaviour.