I installed Cisco IP Communicator 126.96.36.199 on my Win7 machine recently.
It works fine but one thing is confusing me:
I tried to capture packets by Wireshark during some troubleshooting.
Most of the time RTP packets are sent with DSCP=0 by the Communicator.
But sometimes they are sent with DSCP=EF.
What is the rule?
Where can I configure it?
Does anybody know?
The recommended practice is to identify any pc traffic that is UDP based and is using the RTP port 16384 - 32767 or that is TCP based and using port 2000-2002..
Example of a config..
! Class Map to deal with SoftPhones
class-map match-all SOFTPHONE-VOICE
match access-group name SOFTPHONE-VOICE
class-map match-all SOFTPHONE-SIGNALING
match access-group name SOFTPHONE-SIGNALING
! Policy Map to deal with Softphones
set ip dscp 46
police 128000 8000 exceed-action policed-dscp-transmit
set ip dscp 24
police 32000 8000 exceed-action policed-dscp-transmit
set ip dscp 0
police 5000000 8000 exceed-action policed-dscp-transmit
Then configure ACLs to identify the traffic you want your policies to act on..
ip access list extended SOFTPHONE-VOICE
permit udp any any range 16384 32767
ip access list extended SOFTPHONE-SIGNALING
permit tcp any any range 2000 2002
a nice reply, but does not answer my original question.
Generally, wouldn't it be easier letting the softphone to mark the RTP traffic with EF and trust it?
While applying the recommended policy any traffic sent by any application using any udp port within 16384 - 32767 range would get marked as EF, wouldn't it?
So my question again:
WHEN does the Cisco softphone mark the RTP traffic as EF?
Why only sometimes and not always or never?
If we were able to force it to mark the RTP traffic as EF always, we could even modify the recommended policy to trust the traffic on udp ports 16384 - 32767 AND marked as EF by the application which would be safer I guess?
Cisco IPC marks packets with qos values but whether the OS is able to handle those correctly and/or whether the computer IPC is running on has enough resources to route packets out of the network interface as quick as possible is another matter. It's not only the application itself (CIPC) but the surrounding technology that has to work. Think qos as a chain...if one of the links is broken, the whole chain is unusable.
So, for things to work with CIPC:
-the OS needs to be capable of handling qos-marked packets. For windows, check this link out
-the laptop/pc needs to have enough resources (cpu/ram) to handle several applications at once without impacting any of them.
Read more on this thread here
the link you provided lead me to the answer I was looking for:
" In Windows 7 you need to be sure that IPC / Cisco UC for MOC is running with administrator rights, as only it has the rights to mark the packets."
So I guess the Cisco IP Communicator is marking any time, but the NIC driver is accepting the marking only from applications running with administrator rights?