Ok, I see what you mean!

But the system you explain me don't allow to prioritize some phone call. What I'm tring to do is to ensure that packet flux from very important call phone won't be discarded whereas another voip flux would be police.

I just read this document

http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a0080087b13.html

and i saw it could be possible : Here is this example

"In this example, voice1 and voice2 classes of traffic go into the high priority queue and get strict

priority queueing over data traffic. However, voice1 traffic will be rate-limited to 24 kbps and

voice2 traffic will be rate-limited to 48 kbps. The classes will be individually rate-limited"

PS: Mohammed, I also read that tail drop couldn't be use with LLQ

Well it seems to me this in a confusing example.

You will have two priority queues, one limited to 24, one to 48. What will be total? 48, or 24+48 ? The document fails to say that. And, I'm not 100% sure now, but more recent IOS could allow to configure only 1 priority queue.

Anyway, if you want to try that, all what you have to do is make the classification based on IP addresses so that the calls fail in different classes.

Thanks for your help, I gonna try to test this configuration.

I think you need to do hierarchal queuing/embedded policy maps.

Here is an example I just tried out.

First setup your class maps to whatever method you are using to match.

Then create a policy map for your normal calls like the one I created below named default-call.

policy-map default-call

class default-call

priority 128

Next create a new policy as the parent policy and configure the class for critical calls like normal. Then embedded your default-call policy like I did under the "class crit-call". example below.

policy-map crit-call

class crit-call

priority 256

service-policy default-call

class class-default

fair-queue

From there you can create whatever other classes you need like it was any other policy.

The only draw back is I believe that the embedded policy has to draw upon the bandwidth reserved in the parent. In this case I configured the parent with 256k and then configure the default for 128k. If my reasoning is right then if the parent doesn't use up all 256k then the default would be allowed up to 128. This should get your critical calls scheduled before your normal calls

I'm use to doing hierarchal queuing in other vendor routers but if the logic is the same it should work.

You would have to do this in every router along the traffic path - at least the bottle necks.

While this could be a way to do it with policy maps I think I'm with PB in saying that using call admission control to prioritize who gets to establish a call first would be the best way.

Excellent solution! I gonna try to put in pratice what you advise me.

Thank you very much!!!