RTP and RTCP traffic jumping rule

Showing results for 
Show  only  | Search instead for 
Did you mean: 

RTP and RTCP traffic jumping rule

L4 Transporter



We have created a rule for Voice IP.


Zone A to Zone B / Application RTP - RTCP / Service ANY / PERMIT


So all the voice RTP connections should matched in the previous rule, but we are seeing connections which should be matched the previous rule but its matching in this rule:


Zone A to Zone B / ANY / ANY / PERMIT


Its like some connections are jumping the first rule, but we can see in log traffic how the sessions are being identified like RTP and RTCP.


Any idea?


Cyber Elite
Cyber Elite


Once it's been properly identified by your catch-all rule, do you see subsequent sesions between source/destination on the same port properly matching the first rule? 

No, Its not about 3way handshake. I thought it when this case was opened. 

I was thinking that maybe some voice (RTCP) connections are differents and for that its jumping the first rule. But i can not see anythign different between them.

I will try to take pcaps to see the behaviour. 


This is the rule to match voice sessions. Numbers 32 and 33.




And these two rules are below, and sometimes the RTCP  and RTP sessions are matching here. Source and destinations arent problem.




Here we can session browser. the 3 sessions should match in the third rule. 



Recently when  locking down my voice networks I ran into an issue similarly where RTP was matching the incorrect rule.  Come to find out that it was matching the parent session, which in my case was SCCP, that is opening up pinholes and predicting RTP traffic and was causing it to match against a different rule than expected (my signalling rule). 


To resolve the issue, I disabled ALG for the SCCP protocol.  I opened a case with Palo Alto who came back and had stated that this was working as expected.  I dug a little deeper reading and found out that SCCP (and others) performed ALG by default.  I had to disable ALG for SIP as well to get Cisco Telepresence to work correctly.



Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!