Cisco Video Surveillance Media Server Software

Monitor IP Camera Availability in VSMS 6.2 Using SNMP Configuration Example

Document ID: 111978

Updated: May 10, 2010



This document is targeted to Cisco Video Surveillance Manager (VSM) customers running Video Surveillance Media Server (VSMS) 6.2.x or earlier who are interested in monitoring for IP camera availability via SNMP or an SNMP-triggered alerting mechanism. It contains an overview of SNMP trapping services available in VSMS 6.2.x and earlier to deploy a simple IP camera alerting and network monitoring strategy, as well as a step-by-step process for enabling SNMP on VSMS in addition to basic call-flows and troubleshooting examples. This configuration does not apply to any 6.3.x or later versions of VSMS, as VSMS 6.3 introduces the Health Monitoring dashboard, which will obviate the procedures contained in this document via introduction of a comprehensive video surveillance monitoring framework. In addition, the BROADWARE-EVENT-MIB will no longer be used in 6.3.x and later releases of VSMS. Please refer to 6.3 documentation for information regarding available network monitoring and camera management strategies in 6.3.x and later versions of VSMS.



There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco IP Camera 2500 running Firmware 2.1.2

  • VSMS running 6.2.1-12d

  • Video Surveillance Operations Manager (VSOM) running 4.2.1-14

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.


Refer to Cisco Technical Tips Conventions for more information on document conventions.

Network Diagram


SNMP Overview

The Simple Network Management Protocol (SNMP) describes a client-server framework allowing an SNMP Manager to collect information from (or configure) an SNMP Agent using a Management Information Base (MIB), where an SNMP Agent is running on any managed node. Included in this information collecting is the ability for an SNMP Agent to transmit management information to an SNMP Manager without being solicited to do so by the SNMP Manager. This managed node (which houses the SNMP Agent) could be a server, an IP Phone, a network router, network switch, or any IP capable device which includes an SNMP software stack and is therefore capable of being managed via SNMP. In summary, SNMP enables network managers to remotely monitor and control the evolution of network objects.


Three commonly deployed versions of SNMP exist: SNMPv1, SNMPv2c, and SNMPv3. The remainder of this article concentrates specifically on the SNMPv2c Trapping capability as configured in VSMS. Using the above diagram as a reference, the SNMP Agent resides on the VSMS server (the managed node) and reports SNMP Trapping information to the SNMP Manager, which could be a third-party Network Management System (NMS) platform. Common NMSs include HP Open View Network Node Manager, Tivoli Netview, and Solarwinds Orion.

Note: A detailed analysis of the SNMP protocol, including versioning differences, is beyond the scope of this document.

SNMPv2c traps utilize the UDP transport protocol (dest. port 162) and are therefore considered unreliable. For example, if an SNMP trap reporting an IP camera streaming error is lost in transit to the NMS, the VSMS will be unaware of this loss and the SNMP trap will not be retransmitted by VSMS. As a result, the Network Operations Center (NOC) operator relying solely on SNMP will be unaware of the IP camera failure. This unreliable behavior is applicable to all SNMP trapping architectures and is therefore not specific to VSMS. Besides the use of UDP port 162 (common to all SNMP trapping implementations), each trap transmitted from VSMS to the NMS includes some other common event-diagnostic information:

  • The SNMPv2c Community String “broadware-snmp”

    The NMS trap receiver daemon must be configured such that it is capable of processing and presenting SNMPv2c traps ingress with community “broadware-snmp”. SNMP Community names are a simple password-like security mechanism meant to authenticate communications between the SNMP NMS and the SNMP managed node. Unlike the version of SNMP or the trapping destination station address, the VSMS default of ‘broadware-snmp” cannot be changed. See the section entitled Configuration Procedure to confirm which aspects of the VSMS SNMP implementation are configurable.

  • sysUpTime (OID

    sysUpTime is a non-Enterprise MIB object defined in the SNMPv2-MIB (RFC 1213) and reports the time (in hundredths of a second) since the network management portion of the system was last re-initialized, which typically matches the uptime of the VSMS server.

In order to utilize the procedure below to monitor VSMS components, an NMS capable of receiving, parsing, and presenting SNMPv2c traps is required. Further, to translate BROADWARE-EVENT-MIB SNMPv2c traps to understandable event names, the BROADWARE-EVENT-MIB.txt definition file should be installed on the NMS. In order to downloaded this file in the appropriate format, connect to the VSMS via http://<ip_address_or name of_vsms>/vsmc.html, navigate to SNMP Trap Destinations, and click on the VS Event MIB hyperlink.

VSMS is capable of transmitting both SNMPv1 and SNMPv2c traps, although SNMPv2c is recommended due to enhanced MIB support. VSMS also supports SNMPv2c inform messages, which are identical to trap messages, except that an inform is acknowledged by the NMS. As a result, a layer of reliability is added.

Note: In VSMS 6.2 and earlier only unsolicited SNMP trapping is supported. SNMP polling of the BROADWARE-EVENT-MIB on the VSMS from an NMS station is an unsupported operation. In Appendix C, the MAX-ACCESS clause for bwEventDesc object is set to accessible-for-notify.

VSMS SNMP Monitoring Use-Cases

Use-Case #1 IP Camera Availability Monitoring

The VSMS maintains a proxy instance for each encoding device, which is used to receive the media stream from the encoding device and write it to shared memory for later transmission to a VSOM viewing client, another VSMS (child feed), or to local storage via an archive. From a protocol perspective, each proxy instance behaves according to the device type being managed and type of media configuration. For example, proxies created for Cisco 4500 IP Cameras configured for 1080P using H.264 will first be authenticated by VSMS. Subsequent to authentication, the VSMS will inform the camera of its desired streaming properties using Real-Time Streaming Protocol (RTSP). Finally, using streaming information derived via RTSP, the Cisco 4500 IP camera will begin to stream its media flow to the VSMS using Real-Time Protocol (RTP). This entire transaction can be captured on the VSMS CLI using the tcpdump –nn host <IP_of_encoding_device> command.

Note: Cisco IP cameras will authenticate the VSMS by default using HTTPS in 6.x versions of VSMS. If using non-Cisco encoding devices, check for authentication requirement and method by engaging third-party product support.

After handshaking with HTTPS and RTSP, VSMS will transmit a bwProxyEvent trap stating Proxy [proxy_name] Connected to device #a_#b@ip_address, where #a is the device input number and #b is the configuration number for the input. It is important to note this bwProxyEvent trap is transmitted after the HTTPS/RTSP handshake, regardless as to whether the media stream is being received by VSMS. See Appendix A.2 for an example bwProxyEvent Connected to Device trap and check the ims.log for success/failure status of the HTTPS and RTSP control plane:

  • HTTPS handshake successful:

    [ proxy(851).p_s1_Mathers_1 GL_UTIL=1 <HttpsClient.cxx:267> ] 
    got reply header
  • HTTPS handshake unsuccessful:

    [ proxy(851).p_s1_Mathers_1 GL_UTIL=1 <HttpsClient.cxx:246> ] 
    Https(curl): Unable to curl perform[couldn't connect to host]
  • RTSP handshake unsuccessful:

    [ proxy(851).p_s1_Mathers_1 GL_UTIL=1 <RtspClient.cxx:546> ] 
    connect(addr='', fd=6): Connection timed out

If either HTTPS or RTSP connections from VSMS to the IP camera are unsuccessful, eventually, a bwConnectionEvent trap is sent stating Proxy [proxy_name] Unable to configure or handshake with the device #a_#b@ip_address and is accompanied by this ims.log message:

[ proxy(851).p_s1_Mathers_1 BE_PROXY=1 <Proxy.cxx:169> ] 
Unable to configure or handshake with the device

See Appendix A.3 for an example “Unable to configure or handshake” bwConnectionEvent Trap.

After a successful handshake, if the VSMS proxy fails to receive the media stream from the encoding device (IP Camera) for a period of 10s, the VSMS transmits a bwConnectionEvent trap informing that a problem connecting to a given encoding device exists. This trap states Proxy [proxy_name] Streaming error. Device disconnected or network error and is accompanied by these ims.log entries:

[ proxy(17741).p_s1_Mathers_1 GL_UTIL=1 <RtpClient.cxx:703> ] 
Timeout (10 secs) waiting for data from encoder.
[ proxy(17741).p_s1_Mathers_1 BE_PROXY=1 <Proxy.cxx:207> ] 
Streaming error. Device disconnected or network error.

Consult the drivers or analyze network traces to confirm the handshake and streaming protocol behavior of a non-Cisco encoding device.

Note: Generally speaking, in the event an analog camera connected to a multiport encoder loses power or is removed from service, the encoding device will still stream black-screen. As a result, the VSMS will not be able to understand the analog camera failure and no SNMP track for streaming loss will be generated.

Use-Case #2 Archive start/stop Notification

The bwArchiverEvent Notification-Type can be used to signal the start and stop events of configured loop, recurring, or one-time archives.

  • When an archive is started, a bwArchiverEvent trap is generated stating Start archive SUCCESSFUL for archive_name.

  • When an archive is stopped, a bwArchiverEvent trap is generated stating Stop archive SUCCESSFUL for archive_name.

VSMC Overview for Configuring SNMP

Video Surveillance Management Console (VSMC) is a web-based configuration GUI used to view and configure VSMS systems management options directly, without using VSOM or the HTTP API. Generally speaking, VSOM is a user-facing GUI, primarily used to configure and view application specific items, such as proxies, archives, events and views. Conversely, system-wide management items can be viewed and configured in VSMC, including system logs, SNMP, data backups, etc.

Configuration Procedure

Access the VSMC of the Media Server via http://<ip_or name of_media_server>/vsmc.html, choose SNMP Trap Destinations > SNMPv2c from the Protocol pull-down list, and enter the IP address of the NMS to which the traps will be sent:


After updating SNMP Trap Destinations in the VSMC console, verify they are successfully placed in /usr/BWhttpd/etc/snmpd.conf:

bxb-vsm:~ # more /usr/BWhttpd/etc/snmpd.conf | grep trap2sink
# trap2sink: A SNMPv2c trap receiver
#trap2sink  localhost broadware-snmp
trap2sink broadware-snmp

In addition to BROADWARE-EVENT-MIB Traps, enabling SNMP per this process initiates some generic system-level traps. See for a detailed description of these additional traps.

Appendix A: Ethernet Captures of bwConnectionEvent and bwProxyEvent Traps

A.1 bwConnectionEvent (Streaming Error)


A.2 bwProxyEvent (Connected to Device)


A.3 bwConnectionEvent (Unable to configure or handshake)


Appendix B: Trigger to Trap Matrix


Appendix C: BROADWARE-EVENT-MIB Definition


    MODULE-IDENTITY, OBJECT-TYPE, Integer32, enterprises,
    NOTIFICATION-TYPE                       FROM SNMPv2-SMI
    SnmpAdminString                         FROM SNMP-FRAMEWORK-MIB
    netSnmp                                 FROM NET-SNMP-MIB
    RowStatus, StorageType                  FROM SNMPv2-TC
    InetAddressType, InetAddress            FROM INET-ADDRESS-MIB

    LAST-UPDATED "200701300000Z"
         "postal:   BroadWare Support
                    3333 Octavius Dr.
                    Santa Clara CA 95054

        "Top-level infrastructure of the Broadware enterprise MIB tree"
    REVISION     "200701300000Z"
        "First draft"
    ::= { enterprises 28196}

events    OBJECT IDENTIFIER ::= { broadware 1 }

!---  Broadware Notifications

broadwareEventNotificationPrefix  OBJECT IDENTIFIER ::= { events 1 }
broadwareEventNotifications OBJECT IDENTIFIER ::= 
{ broadwareEventNotificationPrefix 0 }
broadwareEventNotificationObjects OBJECT IDENTIFIER ::= 
{ broadwareEventNotificationPrefix 1 }

!---  Broadware Notificationi Desc

        OBJECTS   { bwEventDesc }
        STATUS    current
                "Notification that the proxy hosted in Broadware Media 
         Server (BMS) has changed its state. Proxy is a process which maintains
         the view of a particular video cam."
::= { broadwareEventNotifications 1 }

        OBJECTS   { bwEventDesc }
        STATUS    current
            "Notification that the archiver hosted in Broadware Media 
         Server (BMS) has changed its state. Archiver stores the captured
         video information into a secondary storage device."
::= { broadwareEventNotifications 2 }

        OBJECTS   { bwEventDesc }
        STATUS    current
            "Notification that the network connection has been lost with the
        encoder/ camera".
::= { broadwareEventNotifications 3 }

!--- Broadware Notification Objects

        SYNTAX   SnmpAdminString
        MAX-ACCESS accessible-for-notify
        STATUS  current
                "This object describes the event corresponding to 
the notifying entity."
::= { broadwareEventNotificationObjects 1 }


Appendix D: Additional VSMS Traps


Related Information

Updated: May 10, 2010
Document ID: 111978