QoS - SCCP vs. SIP

I have a Cisco CME running SCCP with a few phones located across an Internet L2L VPN.  The Internet router at the main site is an 1841 with a high bandwidth cable connection.  I have successfully implemettned QoS on this router to mark and class outbound VoIP while policing inbound ftp/http.  The remote phones work well with the CME system.

I implemented a Switchvox system at the main office which uses SIP for call control.  I applied the same style QoS policies to that traffic as that of the CME.  File downloads interfere with outbound audio to the remote site on the SIP system while simultaneous calls on the CME SCCP system to the remote site are perfect.

I'm having difficulty determining why the SIP based and SCCP based systems react differently under the same circumstances.  In theory, the RTP streams function similarly, while the call control is different.  Any opinions or advise would be appreciated.
LVL 1
fcnetimgAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

netbonesCommented:
Can you post your config for the SIP QoS?
0
fcnetimgAuthor Commented:
Sure.  The QoS settings apply to both the SCCP and SIP VoIP traffic.  As I said, the CME SCCP is flawless during file downloads while a simultaneous SwitchVox SIP call is severely chopped up.

The QoS portions of the config follow.  I look for any CS5 marked traffic or anything originating from the SwitchVox server (10.0.0.16) or the SIP phone (10.0.0.121) and remark it as EF as it goes out through the LAN interface.  The WAN interface policy looks for anything going out marked EF and puts it iin the priority queue.  At the same time, the WAN interface polices FTP/HTTP inbound to reserve bandwidth for voice.

class-map match-any FTP-Traffic
 match protocol ftp
 match protocol http
 match protocol secure-http
 match protocol secure-ftp
class-map match-any CS5
 match ip dscp cs5
 match access-group name switchvox-server
 match access-group name switchvox-phone
class-map match-any VOICE
 match ip dscp ef
class-map match-any Signaling
 match ip dscp cs3
 match ip dscp af31
class-map match-any INTERNETWORK-CONTROL
 match ip dscp cs6
 match access-group name IKE
class-map match-any TRANSACTIONAL-DATA
 match ip dscp af21  af22
policy-map Limit-FTP
 class FTP-Traffic
   police cir 16000000
     conform-action transmit
     exceed-action drop
policy-map MARKING
 class CS5
  set dscp ef
policy-map V3PN-EDGE
 class VOICE
    priority percent 33
 class INTERNETWORK-CONTROL
    bandwidth percent 5
 class TRANSACTIONAL-DATA
    bandwidth percent 21
    queue-limit 20 packets
 class SCAVENGER
    bandwidth percent 1
    queue-limit 1 packets
 class Signaling
    bandwidth percent 5
 class class-default
    fair-queue
     random-detect
interface FastEthernet0/0
 description connected to Private LAN
 ip address 10.0.0.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 zone-member security ZN-Inside_LAN
 ip tcp adjust-mss 1300
 duplex auto
 speed auto
 service-policy input MARKING
interface FastEthernet0/1
 description Cable modem
 bandwidth 2200
 ip address w.x.y.z 255.255.255.240
 ip nat outside
 ip virtual-reassembly
 zone-member security ZN-Outside_T1
 duplex auto
 speed auto
 crypto map combinedmap
 service-policy input Limit-FTP
 service-policy output V3PN-EDGE
ip access-list extended switchvox-phone
 permit ip host 10.0.0.121 any
ip access-list extended switchvox-server
 permit ip host 10.0.0.16 any
0
table9Commented:
The first thing I would do is make sure you are getting matches on the acls when you make a call.  Next I would get a trace and look at the packets and make sure they are being marked appropriately with dscp on the far end.  Then post the results.  
0
Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

fcnetimgAuthor Commented:
Here are some counters that demonstrate packets are being marked and evaluated by the routers.  

Local#sh  policy-map interface
 FastEthernet0/0

  Service-policy input: MARKING

    Class-map: CS5 (match-any)
      4345 packets, 978661 bytes
      5 minute offered rate 34000 bps, drop rate 0 bps
      Match: ip dscp cs5 (40)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: access-group name switchvox-server
        4345 packets, 978661 bytes
        5 minute rate 34000 bps
      QoS Set
        dscp ef
          Packets marked 4345

    Class-map: class-default (match-any)
      32415 packets, 2768899 bytes
      5 minute offered rate 166000 bps, drop rate 0 bps
      Match: any
 FastEthernet0/1

  Service-policy input: Limit-FTP

    Class-map: FTP-Traffic (match-any)
      69885 packets, 90475434 bytes
      5 minute offered rate 3979000 bps, drop rate 0 bps
      Match: protocol ftp
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: protocol http
        69136 packets, 89962823 bytes
        5 minute rate 3952000 bps
      Match: protocol secure-http
        749 packets, 512611 bytes
        5 minute rate 11000 bps
      Match: protocol secure-ftp
        0 packets, 0 bytes
        5 minute rate 0 bps
      police:
          cir 16000000 bps, bc 500000 bytes
        conformed 69885 packets, 90475434 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 10391000 bps, exceed 0 bps

    Class-map: class-default (match-any)
      7168 packets, 1548510 bytes
      5 minute offered rate 62000 bps, drop rate 0 bps
      Match: any

  Service-policy output: V3PN-EDGE

    queue stats for all priority classes:
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 4628/1297104

    Class-map: VOICE (match-any)
      4628 packets, 1038927 bytes
      5 minute offered rate 38000 bps, drop rate 0 bps
      Match: ip dscp ef (46)
        4628 packets, 1038927 bytes
        5 minute rate 38000 bps
      Priority: 33% (726 kbps), burst bytes 18150, b/w exceed drops: 0


    Class-map: INTERNETWORK-CONTROL (match-any)
      23 packets, 2116 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp cs6 (48)
        23 packets, 2116 bytes
        5 minute rate 0 bps
      Match: access-group name IKE
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 23/3082
      bandwidth 5% (110 kbps)

    Class-map: TRANSACTIONAL-DATA (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp af21 (18) af22 (20)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue limit 20 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
      bandwidth 21% (462 kbps)

    Class-map: SCAVENGER (match-all)
      2 packets, 330 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp cs1 (8)
      Queueing
      queue limit 1 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 2/120
      bandwidth 1% (22 kbps)

    Class-map: Signaling (match-any)
      83 packets, 6336 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: ip dscp cs3 (24)
        83 packets, 6336 bytes
        5 minute rate 0 bps
      Match: ip dscp af31 (26)
        0 packets, 0 bytes
        5 minute rate 0 bps
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 83/10802
      bandwidth 5% (110 kbps)

    Class-map: class-default (match-any)
      35547 packets, 2759527 bytes
      5 minute offered rate 158000 bps, drop rate 0 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0
      (pkts output/bytes output) 35542/2955648
      Fair-queue: per-flow queue limit 16
        Exp-weight-constant: 9 (1/512)
        Mean queue depth: 0 packets
        class     Transmitted       Random drop      Tail/Flow drop Minimum Maximum Mark
                  pkts/bytes    pkts/bytes       pkts/bytes    thresh  thresh  prob

        0           43127/3989545         0/0              0/0                 20            40  1/10
        1               0/0               0/0              0/0                 22            40  1/10
        2               0/0               0/0              0/0                 24            40  1/10
        3               0/0               0/0              0/0                 26            40  1/10
        4               0/0               0/0              0/0                 28            40  1/10
        5               0/0               0/0              0/0                 30            40  1/10
        6               0/0               0/0              0/0                 32            40  1/10
        7               0/0               0/0              0/0                 34            40  1/10
 
0
table9Commented:
I do not see the sip marking in the config.  I may be missing it though.
class-map match-any sip
match ip dscp cs3
match protocol sip
0
fcnetimgAuthor Commented:
As part of my troubleshooting, I'm taking all IP from the server and marking it EF.  The log I posted proved to me that the voice packet were seen by the VOICE class map on both sides.

class-map match-any CS5
 match access-group name switchvox-server
policy-map MARKING
 class CS5
  set dscp ef
0
table9Commented:
When troubleshooting something like this with qos be as specific as possible.  I would remove the acl and specifically mark the sip traffic.  As a note sip will use tcp or udp depending on the application.  
0
fcnetimgAuthor Commented:
It turns out that there was nothing wrong with my qos config (or any of its iterations throughout the troubleshooting process).  The problem was that the 1841 router processor was over-utilized.  Running IPSec VPN, SSL VPN, QoS, Zone-based firewall with NAT, content filtering, IPSLA for failover while processing downloads at 25Mbps from a broadband connection was too much for the device to handle.  I'm surprised at the result, since the device is marketed to handle all of these functions.  Even TAC concurs that this is the issue.

The initial question still remains however--why is the Cisco CME/SCCP system so much more resilient to poor bandwidth conditions than the SIP based SwitchVox system.  Since no one really commented on that and I have some closure on the SIP issue being related to router performance, I will go ahead and close this.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
table9Commented:
The short answer is that a greater amount of development has gone into sccp.  
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
IP Telephony

From novice to tech pro — start learning today.