QOS for Call Signaling

Unanswered Question
Sep 9th, 2009

Hello,

I am wondering if you can help me. I am looking to mark call signaling traffic across my clients WAN, please see some stats below:-

packet loss <0.1%

<10ms Latency

<3ms Jitter

Now I am looking to mark DSCP AF31 across the network at 200k. I have come up with the following basic config with hope to expand if required for future traffic:-

class-map match-any call_signaling

match ip dscp af31

policy-map WAN

class call_signaling

bandwidth 200000

class class-default

fair-queue

int fa0/0

service-policy output WAN

I am hoping if someone can advise if this looks to be sufficiant to deliver the requirements at a basic level (need to make sure the support for my team is not over complicated).

Any comments or pointers would be much appreciated.

All the best

Steven

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Wed, 09/09/2009 - 01:34

Hello Steven,

two notes:

1)you are assuming that call signalling traffic is marked with AF31 you may need another policy-map applied to lan interface(s) to mark traffic in this way.

bandwidth commands are expressed in kbps so if you want to give 200 kbps you should use

bandwidth 200

2) you should provide an LLQ class for the bearer streams carrying VoIP

class voip_bearer

priority 1000

(to be placed in first place in creating the policy-map)

policy-map WAN

class voip_bearer

priority 1000

class call_signaling

bandwidth 200

class class-default

fair-queue

from the codec choice you can know how much BW is used by a single conversation and you need to adjust CAC on call manager or other IP PBX accordingly so that only N calls are possible at a given time.

also for the voip_bearer class you may need to mark on the lan interfaces with DSCP EF.

Hope to help

Giuseppe

sadcock123 Wed, 09/09/2009 - 02:12

Hello Giuseppe,

Thank you for the quick response!!

I was asked to by the 3rd party VOIP provider to mark AF31 at 300k, so I had a base line for the delivery.

Thank you for pointing out the bandwidth statment, much appreciated.

The third party looks after the LAN which is not a great solution, but it was the only one for this project, so I am hoping they mark as close to the source as well as myself on my CPE devices.

So would you agree with the requirements set from the 3rd party would deliver (obviusoly with an ammendment to my bandwidth statement)?

Also if I was to exapnd on this for EF on the CPE I am guessing it would just be an additional class-map with an extra addition to the policy-map with a bandwidth statement?

Thank you again for your response.

Kind Regards

Steven

Giuseppe Larosa Wed, 09/09/2009 - 02:51

Hello Steven,

>> So would you agree with the requirements set from the 3rd party would deliver (obviusoly with an ammendment to my bandwidth statement)?

yes

>> Also if I was to exapnd on this for EF on the CPE I am guessing it would just be an additional class-map with an extra addition to the policy-map with a bandwidth statement?

No, as I wrote QoS best practice asks to use priority command not bandwidth, the difference is that with priority the small RTP packets are placed in a priority queue that is served first this reduces latency and jitter.

So I would suggest an additional class-map with priority not bandwidth.

Hope to help

Giuseppe

Joseph W. Doherty Wed, 09/09/2009 - 04:21

Beyond the information that Giuseppe already provided, two other possible issues come to mind.

First, FQ within class-default on many IOS/platform combinations can distort the bandwidth defined in other classes. Often not an issue, but to avoid it you can use a bandwidth statement in class-default.

(BTW, I really like FQ. What you might also try is only use LLQ for the VoIP bearer packets, as suggested by Giuseppe, and leave signalling in class-default. Where, also on many platforms/IOSs, FQ is really WFQ so AF31 packets might receive a larger guarantee of bandwidth.)

Second, notice your WAN interface is Ethernet. If the end-to-end WAN bandwidth is not as much as the physical interface, for QoS to be effective, you generally need to shape all traffic to the available bandwidth.

Actions

This Discussion