[cisco-voip] Nbar missing some RTP traffic

[Ryan West]

The big problem here is using a non-directly connected carrier.  The more mature SIP implementations out there will avoid offering any SLA's or even recommending connecting through another carrier.  Although almost all of your congestions are at the edge router, you still need an effective way to determine the traffic.  An implicit trust of previous markings, which should be done at the other edge device, is the way to go.  Matching on protocol rtp audio is extremely effective coming from a CM or CME device, then again, it is already marked with EF anyhow.

-ryan

-----Original Message-----
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ellington, Chris
Sent: Thursday, April 17, 2008 11:03 AM
To: Jeffrey Ollie
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Nbar missing some RTP traffic

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

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip