Negotiate mixed streams and extended offers

Mixed forms across packets need agreement; a single packet still has one element format.

• The preferred one-byte form MUST be supported by all receivers. A stream MUST use only one-byte or only two-byte headers unless every recipient is known to support mixing. Transmitters SHOULD NOT use two-byte form when everything fits one-byte form; a sender expecting an intermediary to add extensions SHOULD use two-byte form. IDs above 14 SHOULD signal intended two-byte use where applicable (§4.1.2).
• a=extmap-allow-mixed takes no value and may be session- or media-level. A proposer SHALL support receiving mixed forms. When SDP Offer/Answer is supported and used, mixed-mode negotiation MUST use it. An offer wishing to mix MUST include the attribute; an answerer supporting and wishing to mix SHALL also include it (§6).
• If the attribute is excluded, both clients SHALL NOT mix forms in the same RTP stream; they MAY use either form exclusively. Without Offer/Answer, mixed forms MUST NOT occur unless the transmitter has out-of-band knowledge that all potential recipients support them (§6). A lone offer flag or a guessed capability is insufficient.
• With mixing established, packet A can use 0xBEDE and packet B can use 0x1000. Each packet still contains only its selected element format: extension types that do not match it MUST NOT be used there. The common ID space means an ID 1–14 has the same assigned meaning in either format (§§4.1.2,4.3,11).
• Offer/Answer MAY use extended identifiers 4096–4351 to propose mutually exclusive alternatives or more extensions than fit the usable range. The answerer SHOULD select desired alternatives (at most one from a shared negotiation ID) and remap to a free valid ID. A copied extended ID can indicate support but cannot be used on wire until assigned a valid ID. This is different from remapping an already-valid offered ID, which is forbidden (§7).