[cisco-voip] Nbar missing some RTP traffic

[Patrick Shoemaker]

Hello list, new member here and first time posting. Hopefully this topic 
hasn't been discussed recently- I couldn't find anything about it in the 
archives.

I am trying to implement QoS for voip on a small ISP network. At the 
border routers that connect to our upstreams, I am attempting to tag all 
incoming voip traffic with the DSCP "expedited forwarding" bit so that 
it is appropriately handled by our internal network, particularly the 
customer last mile connection. I am also tagging all SIP traffic with 
DSCP af31. This is being done by activating nbar on the border routers 
for all incoming traffic using the following (abridged) configuration:

class-map match-all sip
match protocol sip
class-map match-all voice
match protocol rtp audio

policy-map input-mark
class voice
set ip dscp ef
class sip
set ip dscp af31

interface FastEthernet0/0.300
service-policy input input-mark

Using the above configuration, most all RTP traffic is caught and tagged 
as expected, however some is missed. I have captured some packets that 
are correctly tagged, and some that are not, using a sniffer. Comparing 
the two packets shows that there are no differences in the two except 
for the source IP addresses, and the UTP port numbers (source 60250, 
60164; destination 13456, 13460), and obviously the payload.

My theory is that cisco's nbar engine uses the SDP packet that sets up 
the RTP stream to identify the subsequent RTP packets. Therefore, if the 
SDP packet enters the network through a different boundary router, the 
router seeing the subsequent RTP packets won't be able to classify them. 
Does anyone know what specific criteria nbar uses to classify RTP packets?

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