I need to be able to change the DSCP value of a packet on the fly based on the rate of a particular udp stream going through a router.
The application is VOIP + internet, where the VOIP packets get higher DSCP markers. I want to guarantee support for only 2 voice calls. When a third voice call is made I would like to be able to change the DSCP value for only the packets in the 3rd udp stream to a lower value (or even better if I can drop the third call .. ie not allow it altogether).
Is this possible to do in cisco IOS ? Or anything like this possible which will dynamically change DSCP values ?
What you are trying to do is not possible using QoS in the router. Restricting the number of simultaneous calls is a function of call setup and is done using CallManager, your H323, or SIP gateway (whichever one you are using). The exact details will vary based upon your implementation.
While it's not possible at the moment to match number of calls, you can calculate bandwidth requirements for each call. In following example I take that two calls require 64Kbps (this is not accurte number, so don't use it in real config):
! class-map match-all VOICE match ip dscp ef ! policy-map SP_IN class VOICE_IN police 64000 conform-action transmit exceed-action set-dscp-transmit default violate-action set-dscp-transmit default class class-default set dscp default ! policy-map SP_OUT class VOICE priority 64 class class-default fair-queue ! interface FastEthernet0/1 ip address 10.0.1.2 255.255.255.0 service-policy input SP_IN ! interface Serial1/0 ip address 192.168.128.18 255.255.255.252 service-policy output SP_OUT !
Notcie that in 'police' you specify value in Bits-per-second, while in 'priority' you use Kilobits-per-second.
The above configuration will give voice packets no less and no more than
64Kbps of bandwidth in strict priority queue, and everything in excess of it will be demoted to best effort class. Keep in mind that this will not care about to which call packets belong, so you may end up with service degrade for all calls. If instead of lowering DSCP you want to drop excessive traffic all together, you can just remove policy-map SP_IN - 'priority' command in the output policy will not pass excessive traffic.
Common way how such things are organized is that provider and customer get into agreement, that service quality is guaranteed (to certain degree) only if customer keeps his traffic under pre-determined level, should traffic exceed this level, then guarantee is void.
This would not help him, the gotcha being, he want to have the "existing calls" kept in the 'good' QoS, while the 'above the limit call' in the 'best effort' or whatever. Since the router in this case has no 'distinction' from one call to another, all the RTP traffic would be seen as "a bundle", and he would have all calls affected (or at least, chances are that all calls will be affected :-).
That's what I have already said (see quoted lines from my previous message). While indeed it will not limit number of calls, this is still common way how functionality can be provided at least partically - ensuring that voice traffic does not get above certain bandwidth limit. After this customer just needs to be warned that 'as long as you are within limit, you'll have good voice quality, exceed the limit - and all calls will be affected", so it becomes matter of SLA and not technical issue.