1. Home
  2. Cisco Systems
  3. Tandberg Duo Video across Cisco WAN

Tandberg Duo Video across Cisco WAN

Hi, We are having a major issue with this H.239 implementation from Tandberg called Duo Video. For those that don't know, it's the ability to put a presentation from the PC side-by-side or Picture-in-Picture with a Videoconference. The problem we are experiencing is that it drops packets. This occurs at the WAN edge router whenever we send the Duo Video from the PC; not when we send normal video. It turns out the "Sharpness" setting on the endpoint will convert the PC image to an XVGA protocol. As soon as we begin to send that H.239 stream the packets start dropping like mad. What can it be? If we send the entire video call 'best-effort' then the packets don't drop; however, as soon as we begin marking and matching the QoS policy, packets drop. Also, if we set the Duo Video to "Motion" and the image is converted to a CIF protocol, we don't drop packets but the PC image is illegible. Anyone out there using Duo Video?? Sure could use the help.

Thanks!

Reply to
ecstillman
Loading thread data ...

Hello, snipped-for-privacy@hotmail.com! You wrote on 16 Feb 2006 16:31:42 -0800:

e> If we send the entire video call 'best-effort' then the packets e> don't drop; however, as soon as we begin marking and matching the e> QoS policy, packets drop.

Can you post QoS config of your WAN routers? Are you using "priority" for video traffic?

With best regards, Andrey.

Reply to
Andrey Tarasov

Hi Andrey

Yes, we are using priority. The QoS config con be found below:

Regards, Erik

class-map match-all VideoRTP match ip dscp af41 class-map match-any CCMReplication match access-group 100 class-map match-any AutoQoS-VoIP-RTP-Trust match ip dscp ef class-map match-any AutoQoS-VoIP-Control-Trust match ip dscp cs3 match ip dscp af31 ! ! policy-map VideoQoSPolicy class AutoQoS-VoIP-RTP-Trust priority 150 class AutoQoS-VoIP-Control-Trust bandwidth 100 class VideoRTP priority 902 class class-default fair-queue ! ! interface Serial2/0:0 description T1 to LEX for video traffic ip address 10.2.2.1 255.255.255.252 service-policy output VideoQoSPolicy

class-map match-all VideoRTP match ip dscp af41 class-map match-any AutoQoS-VoIP-R match ip dscp ef class-map match-any AutoQoS-VoIP-C match ip dscp cs3 match ip dscp af31 ! ! policy-map VideoQoSPolicy class AutoQoS-VoIP-RTP-Trust priority 150 class AutoQoS-VoIP-Control-Trust bandwidth 100 class VideoRTP priority 902 class class-default fair-queue policy-map AutoQoS-Policy-Trust class AutoQoS-VoIP-RTP-Trust priority percent 15 class AutoQoS-VoIP-Control-Trust bandwidth percent 5 class VideoRTP priority percent 30 class class-default fair-queue policy-map dscp2cos class AutoQoS-VoIP-RTP-Trust set cos 5 ! ! interface Serial0/2/0:0 description T1 to LOU S0/2/0:0 ip address 10.2.2.2 255.255.255.252 service-policy output VideoQoSPolicy

-end

Andrey Tarasov wrote:

Reply to
ecstillman

Hello, snipped-for-privacy@hotmail.com! You wrote on 16 Feb 2006 18:50:21 -0800:

e>>> If we send the entire video call 'best-effort' then the packets e>>> don't drop; however, as soon as we begin marking and matching e>>> the QoS policy, packets drop. ??>>

??>> Can you post QoS config of your WAN routers? Are you using ??>> "priority" for video traffic?

e> Yes, we are using priority. The QoS config con be found below:

Queue configured with priority command has built-in policer for incoming traffic. Chances are you are trying to send a little bit more than configured in QoS map. Excessive traffic is being dropped by policer.

With best regards, Andrey.

Reply to
Andrey Tarasov

Actually the problem is you are not correctly marking the H.263/264 content from the endpoint. You must ensure the "video data" QoS settings is set to AS41 in your use case. This is not the Video RTP setting on the end point, it is the Video Data or Data QoS settings. Do not confuse this with control data, it is actually "Video Data Source"

Reply to
user

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.