The Info panel is used to describe the camera features. Set all features to yes, as desired. If a camera does not support a feature set to yes, no harm. All features can be set yes, available at the camera or not.

The most important Info panel setting is Event by network type. If available in the list, select EBNT_FAMID. This event type processes event meta-data from the camera that is embedded in the video stream. Not all cameras have this option available (it won't be in the list); use another event type.

For Axis cameras, models AXIS_V4 and AXIS_V5, to use EBNT_FAMID requires sending a few parameters to the camera to enable the in-stream event data. This needs to be done only once. There is a macro offered to do this. Alternatively, the following URI can be sent from a browser:

For AXIS_V4 and AXIS_V5:

   /axis-cgi/param.cgi?action=update&Image.I0.TriggerData.IOEnabled=yes&Image.I0.TriggerData.MotionDetectionEnabled=yes&Image.I0.MPEG.UserDataEnabled=yes&Image.TriggerDataEnabled=yes&Image.I0.TriggerData.AudioEnabled=yes 

To disable this in-stream event data, use this URI for AXIS_V4 or AXIS_V5:

   (http://1.2.3.4)/axis-cgi/param.cgi?action=update&Image.TriggerDataEnabled=no

Early-version Axis v4.x firmware cameras use different parameters for this, though these were enabled by default. Later FW versions disable in-stream event data by default. Axis cameras have versatile event server support. For an example of setting up an event server for Axis cameras, see the Event servers section in this guide, under TCP.

If Event by network type is not set, no event processing is performed, so no motion detect (et al.) events are placed into recordings, and no event actions can be performed.

If the camera supports Onvif event processing - and most Onvif-compatible cameras do - you can select EBNT_ONVIF even if the camera make/model in the ID panel was not set to Onvif. For example, Hikvision and Dahua cameras should typically use EBNT_ONVIF.

For using EBNT_HTTP, EBNT_TCP, or EBNT_FTP, see the Event servers section of this guide. These event types require setting the camera to send HTTP, TCP, or FTP messages on events. A final option, EBNT_TGS, can be set for cameras that don't offer event notifications that CAMNET server can use, but you want the camera responding to other cameras' events (for event-based recording).

If processing DI (digital input) is yes, DI base states is consulted to determine the normal, initial state of the digital input. The DI base states is shown and entered as a regular, base-10 value, from 0 to 127, representing 7 bits of input.

         bit 0  digital input 0 (DI0)    1
         bit 1  digital input 1 (DI1)    2
         bit 2  digital input 2 (DI2)    4
         bit 3  digital input 3 or Ext2  8
         bit 4  Ext1                    16
         bit 5  PIR                     32
         bit 6  audio                   64
                                       ---
                                       127

For some cameras, PIR is tied to DI0 (bit0). For digital inputs (DI) 0 to 2 (or 3, if applicable), their base states should be 0; changes to their states is what fires an event. Unless otherwise specified, DI base states should be 0. Ext1 and Ext2 are extension events, used when a camera can do more than DI, audio, and PIR. For example, line crossing, field intrusion/intrusion detection, or loitering, could have the camera send an Ext1 or Ext2 event. Bit7 is used internally to indicate a triggered event, either generated by another camera's regular event, or by an HTTP trigger event (sent from another device to the CAMNET server).

Event processing requires active recording. Events do not make it into recordings, and event actions are not performed, and events are not logged, for a camera that is not recording.

An event log is maintained for the month at the server's base directory for all recording cameras:

   # c:\camnet\camnetserver\20150500_eventlog.txt
   # 2015.05.01 04:00:27    Motion     012XxPAT    EvtA
   2015.05.01 09:07:14	   1.......    ........    ....     cam_c111       [camera signalled this MD]
   2015.05.01 09:07:14	   ........    .......T    ....     cam_pana210    [internally triggered by MD above]
     :
   2015.05.01 09:10:11	   12345678    012XxPA.    ..4.     cam_m1031      [externally triggered]

This brief excerpt shows one camera (c111) with an MD event (window 1) that also triggered other cameras (pana210 shown) in its trigger group. The third entry shown indicates an external trigger, specific to that camera since all MD bits are set and all but one DI bit is set. This was done using the below HTTP GET (a browser can be used to do this; cam_m1031 is at 192.168.0.110):

   http://192.168.0.187:4042/trigger=192.168.0.110

To externally trigger all cameras:

   http://192.168.0.187:4042/trigger=all

This sets only the T bit (bit7) of the event record, for all cameras, similar to the second event log entry for pana210 (above). The evtA column in the month's event log indicates which event-actions were performed, if any. The ..4. for m1031 indicates that the event-action with the value 4 (which is the third row in the Cam setup, Evt-actions panel, at the EVENT ACTIONS section) was done. For this camera, that event-action performs an e-mail send.

The RTCP receiver report and RTSP keep-alive fields should be fine at their defaults of after SR and UDP only. These actions are used to indicate to the camera that its stream is still in use, and for it to not disconnect due to what the camera may perceive as inactivity.