Extra interfaces provided by this media description. This SHOULD NOT include the Description interface itself.

If this is set to True by the CM in a MediaDescriptionOffer, it means "This is an offer under the SDP Offer/Answer model. Whatever you accept this offer with is what I will send to the other side in my answer." If this is set to False by the CM then it means "This is an Answer under the SDP Offer/Answer model, and if it remains False in the Accept(), no further codec negotiation needs to happen." If this is set to True by the streaming implementation (e.g. in an Accept or UpdateLocalMediaDescription call) then a new SDP Offer/Answer round-trip will be initiated.

True if this offer contains information from the remote side: If False then the Accept response solely depends on the capabilities and preferences of the local side. In most protocols this property will be False for the initial DescriptionOffer on an outgoing call.

A list of codecs the remote contact supports. When used with Accept, it means the locally supported codecs.

The contact handle that this description applies to. This property can be used as an opaque identifier, and searched for in RemoteMembers for each Stream in this Content, to determine which Stream this MediaDescription applies to. If multiple MediaDescriptions apply to the same Stream, the SSRCs property should be used to separate media before decoding. If this property is 0, this MediaDescription applies to all streams, so the above matching method is unneccesary (e.g. in conference calls with a mixer, media from all participants is mixed into one stream). When calling Accept or UpdateLocalMediaDescription, this should always be set to 0, or omitted, because it is assumed that you send the same MediaDescription to everyone (Encoding a stream separately for each contact in a call is inefficient, and should be avoided).

A map from Handle to list of Synchronisation Sources, as defined by RFC 3550.

Some protocols require the negotiation of SSRC identifiers for RTP streams. If this is the case, then MediaDescription offers will appear with this property set. The streaming implementation should then call Accept with a map from 0 to a list containing a single SSRC (which does not collide with these, or any previously seen SSRCs). If a new MediaDescription offer appears with an SSRC the same as one in LocalMediaDescriptions, then the streaming implementation should pick a new SSRC to resolve the collision.

It is expected that this list will normally be at most one element long, but it is kept as a list for extensibility. The concatenation of all SSRCs associated with a Stream should contain no duplicate entries. If there are collisions, then it is the responsibility of the protocol implementation to resolve them and generate new offers.

If this property is omitted, then the streaming implementation can assume that there is only one MediaDescription per Stream.

If there is a single multicast Call Stream with multiple Remote Members, and all members are forced to use the same MediaDescription, this map can be used by the streaming implementation to determine which video sources belong to which contacts (e.g. in order to put a name under each face in the call)