RTP traffic not matching App-ID Rule

[IanGraham]

I have a strange issue where I have a configured rule to allow the "rtp" and "rtcp" App-IDs with application-default service from any-to-any. Below that rule I have a generic permit-any rule with application service any. Screenshots below. The behavior I am running into is that positively identified rtp and rtcp sessions are not matching my higher rule, and instead are flowing down to the permit-any-any rule, however when I check the security logs, they are showing the app being correctly identified as rtp or rtcp.

There doesn't appear to be anything in common between the traffic that does or does not match, such as a port number. The APP-ID for RTP lists the port range as dynamic so I am assuming this isn't an issue related to the port range.

I also looked into weather or not the issue is related to pinhole traffic from the SIP session which sets up the RTP predict session, but according to the documentation there is still a requirement to have an APP-ID rule matching the RTP/RTCP traffic. We do have SIP AGL enabled (default setting) but I would think since my rule is so permissive (any/any source/dest) the SIP AGL functionality is irrelevant.

Edit: We are running 10.1.5-h1 and I have checked known issues, but didn't find anything that sounded relevant.

Any help is appreciated!

[BPry · Accepted solution]

@IanGraham,

I've actually found in regards to RTP and RTCP that you actually do want to switch the service to any to reliably identify this traffic and have it match your policy appropriately. I'd want to scope that rule a bit better before making that change however since you've got it wide open at the moment. 

[ChrisHowell2]

This just helped me, I had a very similar situation on Prisma Access Global Protect for VPN users on a new VOIP project.

I had the new five9 voip rule above catch all deny all rule, confused why voip test calls would miss my new five9 voip rule. Watching logs saw hits but no counter in crease or mostly no hit on my new five9 voip rule at all passing it and hit the default deny any any rule and drop in summary. 

I added the vendor requested ports for five9 for UDP and TCP and everytime I added them into the rule it broke the app would stop hitting my rule for voip. 

The URL ports were good in another URL rule for this vendor as all the sites requested (about 20) were low risk computer info

It seemed the RTP and RTCP would fail

So I just used source: Prisma vpn user , destination vendor IP ranges from white paper, and then apps=RTP, RTCP, and SSL, Left URL Category checked on, and for service selected all since it was so dynamic.

It worked after the push the rule was being hit consistent, the drops stopped in the logs, and the app five9 when testing worked