Cisco IP Gateway Encoder (CIVS-SGxx) doesnt work with VSMS for H.264

[samfielder]

Hi,

I have fourteen Cisco IP Gateway Encoder (CIVS-SGxx) Cards mounted in convergence Chassis. They work fine with our VSOM/VSMS using MPEG-4, however when I change it to H.264 in both the VSOM, and on the encoder (via the Stream Manager Configuration Tool) it doesnt ever start the proxy.

In the ims.log I see:

2009-10-14 10:33:01.669 [ proxy(31819).p_acam12_2 BE_PROXY=1 ] Incorrect video from encoder (expecting H.264, received MPEG4). Restarting.

2009-10-14 10:37:37.089 [ MediaOut(4961) GL_UTIL=1 ] Error retrieving H264 headers for proxy 'p_acam12_3'

2009-10-14 10:33:01.721 [ proxy(31819).p_acam12_2 BE_PROXY=1 ] Streaming error. Device disconnected or network error.

A few of these too:

2009-10-14 10:37:39.771 [ proxy(3616).p_acam12_3 GL_UTIL=1 ] ERROR: missed 1 RTP packet(s) [prev=2805, curr=2807]

They aren't necessarily always in that order.

Please note that I have restarted the encoder a few times.

Anyone have any suggestions?

[ivillegas]

For IP Video Surveillance, the media, whether it be TCP-based as is the case with Motion JPEG camera feeds, UDP/RTP-based for MPEG-4 and H.264 or TCP-based web delivery, the recommendation is to mark this traffic as DSCP decimal value 40 or CS5. The control plane traffic for video surveillance, such as RTSP, is recommended to be set at CS3 or decimal value 24. As a best practice, IP cameras are recommended to be configured for NTP, SNMP and Syslog, and these applications are suggested to be marked DSCP with decimal value 16 or CS2.

There is a very limited amount of network traffic in a video surveillance deployment for control plane and network management applications compared to media streams. Because of this, some network managers may find it both practical and expedient to mark media as CS5 and all other traffic from cameras, clients and servers as either CS3 or CS2.

http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/IPVS/IPVS_DG/IPVSchap6.html#wp1057937

[samfielder]

I can see why you thought the missed packet might be part of a QOS problem, however not the root of the question.

Anyway, as it turns out it is a Bug. Here is the ID: CSCtd52865