Contents

Introduction

Prerequisites

Requirements

Components Used

Background Information

RTP Source Validation Definition and Uses

RTP Source Validation in IOS Voice Routers

Source Filter

Configuration

Behaviour and Detection

Voice RTP Source-Filter

Configuration

Behaviour and Detection per Protocol

RTP Source Validation on IOS-XE Voice Routers

Behaviour and Detection per Protocol

Introduction

This document describes the behaviour of RTP Source Validation feature in Cisco IOS and IOS-XE Voice Routers for different call flows and versions.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

- IOS and IOS-XE Software

- H.323

- Session Initiation Protocol (SIP)

- Media Gateway Control Protocol (MGCP)

- Skinny Call Control Protocol (SCCP)

- Real-time Transport Protocol (RTP)

Components Used

The information in this document is based on these software and hardware versions:

- ISRG2 Routers (ISR2900, ISR3900)

- ISRG3 Routers (ISR4400 and ISR4300)

- ASR Routers (ASR1001-X, ASR1002-X, ASR1004, ASR1006 and ASR1006-X with RP2 and ESP40)

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.

Background Information

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 Definition and Uses

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.

RTP Source Validation in IOS Voice Routers

IOS has two different flavors of this feature.

- Source Filter which was introduced in 12.4(6)T

- Voice RTP Source-Filter which was introduced in 15.5(3)M9, 15.6(3)M6 and latter versions

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.

Source Filter

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.

Configuration

voice service voip

sip

source filter

Behaviour and Detection

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.

Voice RTP Source-Filter

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.

1. Voice RTP Source-Filter works for SIP, H.323, MGCP and SCCP

2. The feature also added an error message in Debug VoIP RTP Error in order to easily detect when the RTP is dropped due to a source validation failure

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

Configuration Terminal

voice rtp source-filter

Behaviour and Detection per Protocol

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

RTP Source Validation on IOS-XE Voice Routers

The most important things to highlight about it in IOS-XE are.

1. It is not configurable

2. It is enabled by default

3. Cannot be disabled

4. Media direction in the VoIP signaling is the only exception that allows the RTP to flow from an unknown source

Behaviour and Detection per Protocol

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.