When does Cisco IP Communicator set DSCP to EF?

[milan.kulik]

Hi,

I installed Cisco IP Communicator 8.6.1.0 on my Win7 machine recently.

It works fine but one thing is confusing me:

I tried to capture packets by Wireshark during some troubleshooting.

And realized:

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?

Thanks,

Milan


 

[Ayodeji Okanlawon]

Milan,

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..

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoS-SRND-Book/QoSDesign.html#wp998323

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
!
policy-map SOFTPHONE-PC
class SOFTPHONE-VOICE
 set ip dscp 46
 police 128000 8000 exceed-action policed-dscp-transmit
class SOFTPHONE-SIGNALING
 set ip dscp 24
 police 32000 8000 exceed-action policed-dscp-transmit
class class-default
 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

[milan.kulik]

Hi,

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?

Thanks,

Milan

[Ayodeji Okanlawon]

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

http://technet.microsoft.com/en-us/magazine/2007.02.cableguy.aspx

-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

https://communities.cisco.com/thread/9872?tstart=0.

[milan.kulik]

Hi,

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?

Thanks,

Milan

[Anthony Holloway]

Using Trusted Relay Points in your telephony deployment allows your ACL's to be tied to destination addresses and not just a port range.