[cisco-voip] Nbar missing some RTP traffic

[Ellington, Chris]

It is a lot of ports, however if you look at something like wireshark it figures out the ports and maps them to RTP - generally - I also realize that video shares this port range, at least in Cisco implementations, and some deeper analysis will have to occur, potentially.  I say potentially, because even with video don't you want to prioritize the audio path  (because if the video gets distorted, nobody seems to mind, audio distortions are generally deemed unacceptable).

chris

-----Original Message-----
From: Jeffrey Ollie [mailto:jeff at ocjtech.us] 
Sent: Thursday, April 17, 2008 10:46 AM
To: Ellington, Chris
Cc: Jorge L. Rodriguez Aguila; cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Nbar missing some RTP traffic

On Thu, Apr 17, 2008 at 9:35 AM, Ellington, Chris
<Chris.Ellington at inin.com> wrote:
> Well, yes that is true - however you can pick a range of ports to match - I do it all of the time.  Use an extended ACL to match by port range if you like.  Much more granular than trying to use nbar

By default RTP on Cisco kit uses UDP ports in the range of 16K - 32K.
That's a lot of ports... Plus don't you think that that will match non
RTP data?  Plus not all RTP data is alike... you need to assign
different DSCP mappings to packets depending on if the packet contains
audio or video data.  That's why trying to match based on UDP port
number is inadequate and why I hoped that using nBAR to match RTP
packets would work better.  Unfortunately, since nBAR doesn't work
properly if your RTP streams are using dynamically negotiated payload
types using nBAR to classify RTP traffic is useless to me.

Jeff