Specified Multiplexing category of SDP Attribute. Rules governing SDP Attribute multiplexing are as per draft-ietf-mmusic-sdp-mux-attributes
public enum AttributeCategory
The attributes in the CAUTION category are advised against multiplexing since their usage under multiplexing might lead to incorrect behaviour.
The attributes and their associated values (if any) in the IDENTICAL category MUST be repeated across all the media descriptions under multiplexing.
The attributes in the IDENTICAL-PER-PT category define the RTP payload configuration on per Payload Type basis and MUST have identical values across all the media descriptions for a given RTP Payload Type when repeated. These Payload Types identify the same codec configuration as defined in the Section 10.1.2 of [I-D.ietf-mmusic-sdp-bundle-negotiation] under this context.
The attributes in the INHERIT category encapsulate other SDP attributes or parameters. These attributes inherit their multiplexing characteristics from the attributes or parameters they encapsulate. Such attributes are defined in [RFC3407], [RFC5939] and [RFC6871] as part of a generic framework for indicating and negotiating transport, media, and media format related capabilities in the SDP.
The inheritance manifests itself when the encapsulated attribute or parameter is being leveraged. In the case of SDP Capability Negotiation [RFC5939] for example, this occurs when a capability (encapsulating attribute) is used as part of a configuration; the configuration inherits the multiplexing category of each of its constituent (encapsulated) attributes and parameters. The inherited attributes MUST be coherent in order to form a valid configuration from a multiplexing point of view (see Section 14 for further details).
The attributes in the NORMAL category can be independently specified when multiplexed and they retain their original semantics.
For the attributes in the SPECIAL category, the text in the specification defining the attribute MUST be consulted for further handling when multiplexed.
The attributes in the SUM category can be set as they are normally used but software using them in the multiplexing scenario MUST apply the sum of all the attributes being multiplexed instead of trying to use them independently.This is typically used for bandwidth or other rate limiting attributes to the underlying transport.
The attributes in the TRANSPORT category can be set normally for multiple items in a multiplexed group but the software MUST pick the one that's associated with the "m=" line whose information is used for setting up the underlying transport.