Interface to use by a software implementation of media streaming. The reason behind splitting the members of this interface out from the main Content.DRAFT interface is that the software is not necessarily what controls the media. An example of this is in GSM phones, where the CM just tells the phone to dial a number and it does the audio routing in a device specific hardware way and the CM does not need to concern itself with codecs.

Codec negotiation

When a new Call.DRAFT channel appears, whether it was requested or not, a Description.DRAFT object will either be waiting in the DescriptionOffer property, or will appear at some point via the NewDescriptionOffer signal.

If the remote codecs and other content information is available then the EmptyDescription property will be false and the RemoteCodecs property on the description offer lists the codecs which are supported by the remote contact, and so will determine the codecs that should be proposed by the local user's streaming implementation.

For incoming calls on protocols where the content is described when starting the call (for example, Jingle), the RemoteCodecs will contain information on the codecs that have already been proposed by the remote contact, otherwise the EmptyDescription property will be true

The streaming implementation should look at the remote description and the codecs and other features known by the local user and call Description.DRAFT.Accept with the locally supported description.

This means that in practice, outgoing calls will have a content description pop up with EmptyDescription, property true so the local user will call Accept with a description of all supported codecs and other features. If this description is accepted, then LocalDescriptionsChanged will fire with the details of description passed into Accept. If the call is incoming, then the RemoteCodecs will contain details of the remote contact's codecs and the local user will call Accept with the codecs that both sides understand. After the codec set is accepted, both LocalDescriptionsChanged and RemoteDescriptionsChanged will fire to signal their respective changes.

Protocols without negotiation

For protocols where the codecs are not negotiable, instead of popping up the initial content's Description.DRAFT object with EmptyDescription, set to true and no codecs/features being defined, the CM should set the supported codec values to known codec values in said object's codec map.

Changing codecs mid-call

To update the local codecs in all local descriptions mid-call, the UpdateCodecs method should be called with details of the new codec list. If this is accepted, then LocalDescriptionsChanged will be emitted with the new codec set.

If the other side decides to update his or her codec list during a call, a new Description.DRAFT object will appear through NewDescriptionOffer which should be acted on as documented above.