Video services

Stream selection is a simple selection algorithm that is applicable to any number of input streams. It is a prerequisite for stream selection that RTPv2 encapsulation be used in UDP.

Each service is identified by multicast source, group/destination address and current synchronization source (SSRC). After the service has been identified, the ISA monitors its ingress for:

• traffic with a DA of the multicast group

• traffic with a DA of the ISA (unicast)

Traffic is further checked as having RTP-in-UDP payload, RTP version 2.

The SSRC of each incoming RTP packet is learned as a unique source. Only one SSRC is supported for each stream; as SSRC may change during abnormal situations (such as encoder failover), it can be updated.

An SSRC can only be updated when a Loss of Transport (LoT) occurs, as other perfect streams (with the original SSRC) may still be operational. When an LoT occurs, the SSRC is deleted, the buffers are purged, and the RTP sequence counters are reset. The SSRC is extracted from the next valid RTP packet and the sequence starts over.

One RTP packet from the perfect stream is selected for insertion into the video ISA buffer. After a packet is selected, the RTP sequence counter is incremented and any further RTP packets received by the ISA with the previous sequence number are discarded.

In summary, perfect stream selection is a FIFO algorithm for RTP packet selection; this is considered optimal because:

• All stream sources are identical. Therefore, for any sequence number, the payload should also be identical.

• Most bit errors should be detected by the CRC-32 algorithm applied to Ethernet, SDH, and so on.

  These devices typically discard frames where bit errors occur, with the net result being that the video ISA receives a bit error-free stream (though packet loss can occur).

• The UDP checksum is verified by the video ISA (after input VQM) and any failures result in a silent discard of the packet.

• VQM can be used in conjunction with perfect stream protection.

  VQM can be used to monitor the quality of two duplicate ingress multicast streams and the egress multicast stream (after perfect stream selection). This is particularly useful to compare between the ingress and egress multicast. Monitoring the egress multicast after perfect stream selection can provide an insight to the customer viewing experience.

When a service is defined and is administratively enabled, the video ISA monitors for valid RTP packets and on first receipt of a valid RTP packet learn the following information:

• SSRC

• sequence number

• timestamp (as timestamp is profile-specific, MPEG2-TS are assumed)

The packet is inserted into the video ISA playout buffer associated with that particular service and playout when directed (playout algorithm).

Each valid RTP packet received for a specific service is inserted into the buffer if there is no existing RTP packet that matches the sequence number. When sequence numbers and timestamps discontinue, the video ISA makes a limited attempt to validate the MPEG stream. The video ISA code adopts a philosophy to ensure that sequence numbers and timestamps increment correctly. If packets are non-contiguous, the packet selection algorithm adapts.

Duplicate packets are detected by sequence number or timestamp, unless M-bit resets the timestamp. A packet that is already in the buffer and which has the same sequence number as a received packet (or one recently played out) is discarded. The system monitors the incoming sequence number on each RTP packet. If a packet takes more than 1.5 seconds, it is considered late and is discarded.

In a multiprogram transport stream (MPTS), the timestamp is uniquely set for every RTP packet, as any RTP packet many contain a number of multiplexed elementary streams. As a result, playout is based on the embedded timestamp in each RTP packet. In a single-program transport stream the inverse occurs. Many RTP packets can share the same timestamp as it is referenced from the start of a picture (and a picture can span many RTP packets). As an SPTS does not contain audio, its application is limited to content production and so only MPTS are supported.

Timestamp discontinuities do occur and are normally represented with the Marker bit (M) being set.

Playout time is determined by an internal playout timestamp. The playout timestamp is set independently from the actual timestamp in the packet. The recovered clock can compute the expected timestamp for the very next incoming RTP packet.

When a packet is received, it is first compared to existing packets in the buffer based on sequence number (assuming that a stream may be delayed for hundreds of milliseconds by a backup path yet still be valid); jitter tolerance is only evaluated if this packet is determined to be a new RTP packet eligible for buffer insertion. If jitter tolerance is exceeded, then a timestamp discontinuity is assumed and instead of setting the playout timestamp based on the contained RTP timestamp, the actual received time (offset by playout-buffer) is set for the RTP packet playout timestamp.

In normal operation, the clock is recovered from the timestamp field in the RTP header, is offset by the playout buffer configuration parameter, and is used to schedule playout of the packet. The playout clock is synchronized with the sender by using an adaptive clock recovery algorithm to correct for wander.

Algorithm summary

• For a service marked LoT, if a loss of transport occurred, purge the buffer and reset all counters/timers.

• If the service is UP, check the RTP packet sequence number. Compare to sequence numbers contained in the buffer. If no match then check last played sequence number. If the sequence number of this packet is between last played and last played + 4096 then consider this packet late and discard.

• Check the expected timestamp recovered clock value and compare to RTP timestamp. If the expected timestamp is (-ve)jitter tolerance<timestamp<(+ve)jitter tolerance then the packet is admitted to the buffer with a playout timestamp per the embedded RTP timestamp. If jitter tolerance is not maintained this marks a discontinuity event. Set playout timestamp to current clock + playout buffer and enqueue.

RFC 2250, RTP Payload Format for MPEG1/MPEG2 Video, defines the timestamp format for MPEG2 video streams (which may carry H.264 video): a 90kHz clock referenced to the PCR. Each ingest RTP packet has it’s timestamp inspected and it is used in an adaptive clock recovery algorithm. Importantly, these adjustments occur on ingress (not on playout). This serves as a long-term, stable, ingress stream recovered clock.

The 90kHz ingress stream recovered clock is adjusted for each service to account for the encoder’s reference clock/difference between the clock in the 7750 SR. This input timestamp is derived from the same RTP packet that is inserted into the buffer, and therefore may be subjected to significant jitter. The clock adjustment algorithm must only adjust clock in extremely small increments (in the order of microseconds) over a very long sample period (not bitrate) of at least 30 minutes.

Playout is the process of regenerating the stream based on the playout timestamp.

The playout is an exact offset to the ingress stream-recovered clock and serves as playout time for the video ISA. Because the timestamp is used for buffer playout, CBR, capped VBR, and VBR streams are all supported without pre-configuration. The playout buffer mechanism effectively removes network-induced jitter and restores the output to the rate of the original encoder.

In the circumstance that the playout buffer is emptied an LoT is indicated. The video ISA resets playout timestamp, clock, sequence number, and so on for this event and awaits the next valid RTP packet for this service.

Perfect stream can enhance the end user experience by removing network induced faults to the multicast stream. The egress of the perfect stream can be fed back into a separate ISA for the FCC/RET application. This ensures that the end user gets the best IPTV viewing experience from the start of a channel change. The perfect stream can be sent to the FCC/RET ISA by using extranet where FCC/RET resides on a separate VPRN instance.

Perfect stream uses two identical multicast streams traversing two diverse network paths to construct a multicast stream that is less susceptible to network faults. VQM can be configured in conjunction with perfect stream, which allows VQM to monitor the two ingress as well as the egress streams. By using the VQM statistics from all three streams, the operator can assess the quality of the network transporting the multicast stream, the performance of perfect stream, and the viewing quality for the end user. VQM and Perfect Stream can be enabled on the same video-group (the same ISA).

The feature provides ability to measure and provide statistics to allow reporting on voice and video quality for VoIP and teleconferencing (A/V) applications. A sampled deployment is shown in Voice/video monitoring deployment example . Although a distributed model is shown, a hub-and spoke model, with AA-ISA deployed only on one side of the traffic flow, is also supported.

Because of network-based AA, the operator has an ability to monitor voice, video, teleconferencing applications for an AA subscriber regardless of the type of that subscriber (a residential subscriber vs. a user of a business VPN service). AA-ISA monitors UDP/RTP/RTCP/SDP headers for each initiated call/application session (sampling may be provided, although it is expected that a sampling rate is smaller than that of TCP-applications because of the nature of the voice/video applications, which are longer lasting with smaller numbers of sessions or calls per subscriber). AA ISA gathers statistics and computes MOS-scores/R-factor results per each call or application session. At the end of a call (application session closure), AA-ISA sends the statistics and computed scores to a Cflowd collector (the Cflowd infrastructure that was introduced for TCP-performance but modified to carry voice/video specific data is used). The collector summarizes and presents the results to the operator/end user.

AA-ISA integrates a third party MOS software stack to perform VoIP and video MOS measurements. This software provides:

• call quality analysis using optimized ITU-T G.107

• measurements of perceptual effects of burst packet loss and recency using ETSI TS 101 329-5 Annex E Extensions

• measurements and analysis of RTCP XR (RFC3611) VoIP metrics payloads

AA software monitors the associated SDP channel and passes codec information (when available) to the subsystem which monitors VoIP. The video bearer channels traffic generates a wide variety of A/V performance metrics such as:

• call quality metrics

  • listening and conversational quality MOS scores (MOS-LQ, MOS-CQ)

  • listening and conversational quality R-factors (R-LQ, R-CQ)

  • estimated PESQ scores (MOS-PQ)

  • separate R-factors for burst and gap conditions (R-Burst, R-Gap)

  • video MOS-V and audio MOS-A

  • video transmission quality (VSTQ)

• video stream metrics

  • good and impaired I, B, P, SI, SP frame counts

  • automatic detection of GoP structure and other key video stream attributes such as image size, bit rate, codec type

• transport (IP/RTP) metrics

  • packet loss rate, packet discard rate, burst/gap loss rates

  • packet delay variation/jitter

• degradation factors (degradation because of loss, jitter, codec, delay, signal level, noise level, echo, recency)

When a flow terminates, AA software retrieves the flow MOS parameters from the subsystems, formats the info into a Cflowd record and forwards the record to a configured Cflowd collector (RAM).

RAM collects Cflowd records, summarizes these records using route of interest information (source/destinations). In addition, RAM provides the user with statistics (min/max/ avg values) for the different performance parameters that are summarized.

Retransmission (RET) for RTP (RFC 3550, RTP: A Transport Protocol for Real-Time Applications) is based on a client/server model where the client sends negative acknowledgments (NACKs) using Real-time Transport Control Protocol (RTCP) (RFC 4585, Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)) to a RET server when the client detects missing sequence numbers in the RTP stream. The RET server which caches the RTP stream, for example in a circular buffer, detects missing sequence numbers in the replies to the NACKs by resending the missing RTP packets as illustrated in RET server retransmission of a missing frame.

The format of the reply must be agreed upon by the RET client and server and can be an exact copy (Payload Type 33 as defined in RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control) or sent with a different Payload Type using an encapsulating RET header format (RFC 4588, RTP Retransmission Payload Format).

RET has been defined in standards organizations by the IETF in the above-noted RFCs and Digital Video Broadcasting (DVB) in ‟Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks (DVB-IPTV Phase 1.4)” which describes the STB standards.

STBs that have a port of the Nokia RET/FCC Client SDK are an example of a standards-compliant RET Client implementation.

FCC is an Nokia method based on a client/server model for providing fast channel changes on multicast IPTV networks distributed over RTP. During a fast channel change, the FCC client initiates a unicast FCC session with the FCC server where the FCC server caches the video stream and sends the channel stream to the FCC client starting at the beginning of a Group of Pictures (GOP). Beginning at a GOP in the past minimizes the visual channel transition on the client/STB, but the FCC unicast stream must be sent at an accelerated rate in the time domain to allow the unicast stream to catch up to the main multicast stream, at which point, the FCC server signals to the client to join the main RTP stream.

FCC client/server protocol illustrates the FCC client and server communication.

There are two techniques for compressing the FCC unicast stream in time to allow the unicast session to catch up to the multicast stream: bursting and denting. When bursting, the stream is sent at a rate faster than multicast stream, for example, the stream can be ‟bursted” at 130% (or 30% over the nominal) multicast rate. ‟Denting” is a technique where less important video frames are dropped by the FCC server and not sent to the FCC client. Hybrid mode combines bursting and denting.

Bursting is illustrated in FCC bursting sent faster than nominal rate and denting is illustrated in FCC denting removing less important frames .

When the unicast session has caught up to the multicast session, the FCC server signals to the FCC client to join the main multicast stream. The FCC server then sends the unicast session at a lower rate called the ‟handover” rate until the unicast session is terminated.

The FCC server functionality requires the Nokia 5910 Video Services Appliance (VSA) Re-Wrapper which is used to encapsulate and condition the multicast channel streams into RTP, adding important information in the RTP extension header. Also, the ISA FCC server requires an STB FCC client based on the Nokia FCC/RET Client SDK.

Even though the previous sections discussed the RET server and FCC server as separate entities, the ISA can support RET and FCC servers at the same service at the same time. Therefore, the configuration commands and operational commands for the services are intermingled. If both the RET server and FCC server are enabled for a specific channel, a single buffer is used for caching of the channel.

A maximum bandwidth limit for all server requests can be defined for a specific ‟subscriber” which is equated with the source IP address. Before an ISA server processes a request, the ISA calculates the bandwidth to the subscriber required, and drops the request if the subscriber bandwidth limit is exceeded.

The ISA services RET and FCC requests on a first in, first out (FIFO) basis. Before servicing any request, the ISA calculates whether its egress bandwidth can handle the request. If there is insufficient egress bandwidth to handle the service request, the request is dropped. Near the ISA’s egress limits, RET requests generally continue to be serviced whereas FCC requests are dropped because RET sessions are generally a fairly small percentage of the nominal rate and FCC sessions are slightly below to above the nominal channel rate.

The ISA hardware has an MDA form factor that is provisioned in the same manner as other MDAs.

Use the following commands to configure an ISA module.

configure card card-type
configure card mda mda-type

[ex:/configure card 9]
A:admin@node-2# info
    card-type iom4-e-b
    mda 1 {
        mda-type isa2-aa
    }
    mda 2 {
        mda-type isa2-aa
    }
    fp 1 {
    }

A:node-2>config>card# info
----------------------------------------------
        card-type iom4-e-b
        mda 1
            mda-type isa2-bb
        exit
        mda 2
            mda-type isa2-bb
        exit
        fp 1
        exit
----------------------------------------------

When used for video services, ISA-MSes are logically grouped into video groups that pool the ISA buffering and processing resources into a single logical entity.

Use the commands in the following context to configure a video group.

configure isa video-group 

The following example shows video-group 1 with a single ISA configured in slot 2/MDA 1.

[ex:/configure isa]
A:admin@node-2# info
    video-group 1 {
        admin-state enable
        description "Video Group 1"
        mda 1/2 { }
    }

A:node-2>config>isa# info
===============================================================================
        video-group 1 create
            description "Video Group 1"
            primary 7/2
            no shutdown
        exit
===============================================================================

Video features in a VPRN service require the user to create the following:

• a video SAP

• a video interface

A video SAP is similar to other SAPs in the system in that QoS and filter policies can be associated with the SAP on ingress (traffic leaving the ISA and ingressing the system) and egress (traffic leaving system and entering the ISA).

The video SAP is associated with a video group. Channels are also associated with a video group which is what establishes the link between what channels can be referenced through the video SAP. The multicast information policy associated with the service is where the channel to video group association is defined.

A single VPRN service can be used to support all video applications. However, it is possible to use two different VPRNs for a FCC/RET service; one VPRN is configured with a FCC/RET server to process FCC/RET requests, and a second VPRN is configured to support only the buffering of the multicast video content. In this case, within the FCC/RET server VPRN, the multicast service of the VPRN (service ID) must be specified.

Another important video services option in a multicast information policy is the administrative bandwidth defined for the channel. Many video applications use the bandwidth to determine if sufficient ISA egress bandwidth exists to service or drop a service request.

[ex:/configure service ies "1"]
A:admin@node-2# info
    customer "1"
    video-interface "video-100" {
        multicast-service 5
        video-sap {
            video-group-id 4
        }
        address 10.1.1.254/8 { }
        address 192.168.0.254/8 { }
    }

A:node-2>config>service>ies# info
----------------------------------------------
            shutdown
            video-interface "video-100" create
                shutdown
                video-sap 4
                exit
                address 10.1.1.254/8
                address 192.168.0.254/8
                multicast-service 5
            exit
----------------------------------------------

Multicast information policies are used by the video applications to define multicast channel attributes and video policies which contains application-specific configuration for a video interface IP address.

It is within the multicast information policy bundles, channels and source-overrides that a video group is assigned to a channel. The video group association is inherited from the more general construct unless it is explicitly disabled.

The administrative bandwidth for channels at the bundle, channel or source-override level is also defined in the multicast information policy. Video applications use the administrative bandwidth here when a channel rate estimate is needed.

A video policy is defined within the multicast information policy for a specific video interface IP address. The IP address for the video policy is the key value that associates it with a specific video interface IP address within a service associated with overall multicast information policy.

See the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide for CLI command descriptions and syntax usage information to configure multicast info policies.

The following example displays a multicast information policy configuration.

[ex:/configure multicast-management]
A:admin@node-2# info
    multicast-info-policy "ies100" {
        bundle "10.5.6.140" {
            admin-bw 8000
            video {
                local-rt-server true
                rt-buffer-size 3000
                video-group 1
            }
            channel start 10.5.6.140 end 10.5.6.140 {
            }
        }
        bundle "10.5.6.241-10.5.6.243" {
            admin-bw 12000
            video {
                rt-buffer-size 4000
                video-group 1
            }
            channel start 10.5.6.241 end 10.5.6.243 {
            }
        }
    }

A:node-2>config>mcast-mgmt># info   
----------------------------------------------
            multicast-info-policy "ies100" create
                bundle "10.5.6.140" create
                    admin-bw 8000
                    video
                        video-group 1
                        local-rt-server
                        rt-buffer-size 3000
                    exit
                    channel "10.5.6.140" "10.5.6.140" create
                    exit
                exit
                bundle "default" create
                exit
                bundle "5.6.241-5.6.243" create
                    admin-bw 12000
                    video
                        video-group 1
                        rt-buffer-size 4000
                    exit
                    channel "10.5.6.241" "10.5.6.243" create
                    exit
                exit                  
            exit
----------------------------------------------

This section provides an example configuration for the RET server. The configuration example has the following assumptions:

• a single ISA-MS in slot 2/1 in video group 1

• a single channel 192.0.2.1 within multicast bundle ‟b1” with an administrative bandwidth of 2700 kb/s defined in multicast-info-policy policy-name

• a retransmission buffer for the channel set to 300 milliseconds

• RET rate is 5% of nominal

• local RET server address is 10.3.3.3 and destination port is UDP 4096

The first step is to configure the video group, including the RET server, and the ISA-MS hardware. The local-rt-server command in the example enables the local RET server on the video group.

[ex:/configure isa]
A:admin@node-2# info
    video-group 1 {
        admin-state enable
        local-rt-server true
        mda 2/1 { }
    }

[ex:/configure card 2 mda 1]
A:admin@node-2# info
    mda-type isa-ms-v

A:node-2>config>isa# info
----------------------------------------------
        video-group 1 create
            local-rt-server
            primary 2/1
            no shutdown
        exit
----------------------------------------------

A:node-2>config>card>mda# info
----------------------------------------------
            mda-type isa-ms
----------------------------------------------

[ex:/configure multicast-management multicast-info-policy "ies100"]
A:admin@node-2# info
    bundle "bl" {
        admin-bw 2700
        video {
            local-rt-port 4096
            rt-buffer-size 300
            video-group 2
        }
        channel start 192.0.2.1 end 192.0.2.1 {
        }
    }
    video-policy {
        video-interface 10.3.3.3 {
            rt-rate 5
            hd {
                local-rt-server true
            }
            pip {
                local-rt-server true
            }
            sd {
                local-rt-server true
            }
        }
    }

A:node-2>config>mcast-mgmt>mcast-info-plcy# info
----------------------------------------------
            bundle "default" create
                local-rt-port 4096
            exit
            bundle "b1" create
                admin-bw 2700
                video
                    video-group 2
                    rt-buffer-size 300
                exit
                channel "192.0.2.1" "192.0.2.1" create
                exit
            exit
            video-policy
                video-interface 10.3.3.3 create
                    rt-rate 5
                    hd
                        local-rt-server
                    exit
                    sd
                        local-rt-server
                    exit
                    pip
                        local-rt-server
                    exit
                exit
            exit
----------------------------------------------

[ex:/configure service ies "100"]
A:admin@node-2# info
    video-interface "vi" {
        admin-state enable
        video-sap {
            video-group-id 1
        }
        address 10.3.3.3/32 { }
        }
    }

[ex:/configure router "base"]
A:admin@node-2# info  
        multicast-info-policy "ies100"
        igmp
            interface "vi"
                static
                    group 192.0.2.1
                        starg
                    }
                }
            }
        }
        pim
            interface "vi" {
        }
 

A:node-2>config>service>ies# info
----------------------------------------------
            video-interface "vi" create
                video-sap 1
                exit
                address 10.3.3.3/32
                no shutdown
            exit

A:node-2>config>router# info
----------------------------------------------
    ...
    multicast-info-policy "ies100"
    igmp
        interface "vi"
            static
                group 192.0.2.1
                    starg
                exit
            exit
        exit
    pim 
        interface "vi"
        exit
    exit
----------------------------------------------

This section provides an example configuration for the FCC server. The configuration example has the following assumptions:

• a single ISA-MS in slot 2/1 in video group 1

• a single channel 192.0.2.1 within multicast bundle ‟b1” with an administrative bandwidth of 8000 kb/s defined using the multicast-info-policy command

• FCC mode burst with a rate 130% of nominal for HD, 200% for SD, and disabled for PIP

• local FCC server address10.3.3.3 and destination port UDP 4098

The first step in the configuration is to configure video group 1 enabling the FCC server and the ISA-MS hardware. The fcc-server command in the example enables the FCC server on the video group.

[ex:/configure isa]
A:admin@node-2# info
    video-group 1 {
        admin-state enable
        fcc-server true
        mda 2/1 { }
    }

[ex:/configure card 2 mda 1]
A:admin@node-2# info
    mda-type isa-ms

A:node-2>config>isa# info
----------------------------------------------
        video-group 1 create
            fcc-server
            primary 2/1
            no shutdown
        exit
----------------------------------------------

A:node-2>config>card>mda# info
----------------------------------------------
            mda-type isa-ms
----------------------------------------------

[ex:/configure multicast-management multicast-info-policy "ies100"]
A:admin@node-2# info
    bundle "bl" {
        admin-bw 8000
        video {
            fcc-server true
            fcc-channel-type hd
            local-fcc-port 4098
            video-group 1
        }
        channel start 192.0.2.1 end 192.0.2.1 {
        }
    }
    video-policy {
        video-interface 10.3.3.3 {
            rt-rate 5
            hd {
                fcc-server {
                    mode burst
                }
                fcc-burst 30
            }
            pip
            }
            sd {
                fcc-server {
                    mode burst
                }
                fcc-burst 100
            }
        }
    }

A:node-2>config>mcast-mgmtmcast-info-plcy# info
----------------------------------------------
            bundle "default" create
                local-fcc-port 4098
            exit
            bundle "b1" create
                admin-bw 8000
                video
                    video-group 1
                    fcc-server 
                    fcc-channel-type hd
                exit
                channel "192.0.2.1" "192.0.2.1" create
                exit
            exit
            video-policy
                video-interface 10.3.3.3 create
                    rt-rate 5
                    hd
                        fcc-server mode burst
                        fcc-burst 30
                    exit
                    sd
                        fcc-server mode burst
                        fcc-burst 100
                    exit
                    pip
                        no fcc-server
                    exit
                exit
            exit
----------------------------------------------

[ex:/configure service ies "100"]
A:admin@node-2# info
    video-interface "vi" {
        admin-state enable
        video-sap {
            video-group-id 1
        }
        address 10.4.4.4/32 { }
        }
    }

[ex:/configure router "base"]
A:admin@node-2# info  
        ....
        multicast-info-policy "ies100"
        igmp
            interface "vi"
                static
                    group 192.0.2.1
                        starg
                    }
                }
            }
        }
        pim
            interface "vi" {
        }
        ...
 

A:node-2>config>service>ies# info
----------------------------------------------
            video-interface "vi" create
                video-sap 1
                exit
                address 10.4.4.4/32
                no shutdown
            exit
----------------------------------------------

A:node-2>config>router# info
----------------------------------------------
    ...
    multicast-info-policy "ies100"
    igmp
        interface "vi"
            static
                group 192.0.2.1
                    starg
                exit
            exit
        exit
    pim 
        interface "vi"
    exit
    ...
----------------------------------------------

The following example shows logging and accounting configuration for collecting video statistics. Accounting requires the platforms support no more than 256,000 sessions and the FCC/RET timer must be set to 5 minutes. If these conditions are not met, the accounting record may not be accurate.

[ex:/configure log]
A:admin@node-2# info
        file 1
            compact-flash-location {
                primary cf3:
        }
        accounting-policy 1 {
            admin-state disable
            collection-interval 5
            record video
            destination {
                file "1"
            }
        }
    }

A:node-2>config>log# info
----------------------------------------------
        file-id 1
            location cf3:
        exit
        accounting-policy 1
            shutdown
            record video
            collection-interval 5
            to file 1
        exit
----------------------------------------------

[ex:/configure service ies "300"]
A:admin@node-2# info
    video-interface "vi" {
        admin-state enable
        accounting-policy 1 {
            admin-state enable
        }
    }

A:node-2>config>service>ies# info
  video-interface "vi" create
        accounting-policy "1"
            no shutdown
        exit
        no shutdown
  exit