AVP Flag Manipulation

You can manipulate the AVP flags by configuring the header-type parameter to avp-flags, this invokes operation on the flags byte in the AVP header. AVP flags are 1 byte long, where the first 3 bits represent (1) vendor, (2) must and (3) protected. The last 5 bits are reserved.

The vendor flag is critical to consider here, since it has interdependency with Vendor-Id field in the header shown above. As per RFC 3588, The 'V' bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set, the AVP Code belongs to the specific vendor code address space. Please find specific details about the rest of the flags in RFC3588 Section 4.1.

When manipulating AVP flags, a bitwise comparison is performed between the received value and the match value. For ease of configuration, the match value is configured as a comma-separated enumerated list of vendor, must, and protected. So the new value and the match value will be used to indicate what bit in the avp-flag to operate on. If the match value is empty, the configured action is performed without any matching tests. In addition, the new value is configured using the same enumerations. The AVP header rules configuration element appears as follows:

avp-header-rules
   name         replaceAvpFlags
   header-type  avp-flags
   action       replace
   match-value  must,protected
   new-value		 must

According to the example configuration, the Oracle Communications Session Border Controller makes a positive match when only the must and protected bits are set in the received avp-flags. If only the 'M' bit is set, then the match fails, the Oracle Communications Session Border Controller continues to the next header-rule.

When the match is successful (or if the match value is left empty), the configured action is performed. Consider all following actions applicable to the avp header rules sub element:

• none— no action will be performed
• add—the flags specified in the new value are enabled in the header, and state of the existing flags will not be changed.

  If new value is empty, the add operation will not be performed.

  If the new value=vendor, and the 'V' bit was not originally set, then the 'V' bit is now be set including a vendor-id of 9148 inserted into AVP. 9148 is the Acme Packet vendor-id assigned by IANA. It is expected that a second header-rule will be used to change this to the desired vendor-id.

• replace—all the received avp-flags will be reset. The values in the new value parameter will be set.

  If the new value is empty, the replace operation will not be performed.

  If the new value=vendor, and the 'V' bit was not originally set, then the 'V' bit will now be set and also a vendor-id of 9148 (Acme Packet’s vendor-id) is added to the AVP header. A second header-rule may be used to change this to the desired vendor-id.

  If the new value does not contain vendor, and the 'V' bit was originally set, then the 'V' bit will be cleared and the vendor-id will also be set to 0 effectively removing it from the AVP header.

• delete—all flags configured in new value, will be deleted from the AVP header

  If the new value is empty, then no flags are deleted.

  If the particular flag is already empty, then it will be skipped. For example, if the new value=must and 'M' bit is not set, after applying the DMR the 'M' bit will still be not set.

  If the new value=vendor, then the 'V' bit will be cleared (if not cleared already) and the vendor-id is set to 0, effectively removing the vendor-id from the avp-header.