[cisco-voip] Nbar missing some RTP traffic

[Patrick Shoemaker]

Thanks for the responses, everybody.

No, I am not directly connected to the SIP provider, and the provider 
suggests that compiling a list of all the audio path origination points 
would be tedious/impossible. They are not all funneled through a single 
gateway- they come from all over the Internet, according to the 
provider. Customers connect into my network through a last mile wireless 
system that is completely under my control, so maintaining the markings 
on outbound traffic is no problem.

I have also tried "match protocol rtp" to see if the payload type was 
the issue, even though it shouldn't be since everything is g.711 or 
g.729 with no dynamic payload types. I get the same problem- most 
traffic is identified but some streams are missed.

I would like to avoid marking based on a static UDP port range. As this 
is an ISP network, you never know what kind of random applications will 
be traversing it. I don't want some rouge filesharing app using a port 
range that gets placed into a high priority queue.

It looks like the only reliable option at this point is maintaining 
giant ACLs on each border router with the IP addresses of all the 
registered ATAs on my network, then marking all the UDP traffic destined 
to them. This is going to turn into a management nightmare after a 
while, but is there another solution?

One idea I had was to use reflexive ACLs to identify outgoing streams 
tagged with the EF bit, then apply the same treatment to the 
corresponding incoming stream. However, it is not necessarily true that 
the outgoing voice traffic is traversing the same router as the incoming 
traffic.

Patrick Shoemaker
President, Vector Data Systems LLC
shoemakerp at vectordatasystems.com
office: (301) 358-1690 x36
mobile: (410) 991-5791
http://www.vectordatasystems.com



Ryan West wrote:
> 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
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip