Channels of type Streamed Media may support the Media Signalling interface.
If not, the connection manager is assumed to be presenting the media
streams to the user automatically (for instance, in a connection manager
like gnome-phone-manager or telepathy-snom that remotely controls a
telephone, the phone's own speaker and microphone will probably be
used directly).

If Media Signalling is supported, the Telepathy client is responsible for
actually streaming the media, using the Media Signalling interface to
provide signalling (connection managers might implement this interface in
terms of Jingle or SDP, for instance). The Telepathy project suggests that
client authors use the Farsight library for this; the glue between Media
Signalling and Farsight is currently done in telepathy-stream-engine, an
additional D-Bus service, but it will be provided as a library in future.

Channels of type Streamed Media may also support the DTMF and
CallState interfaces.

<tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>Request that the channel be put on hold (be instructed not to send any media streams to you) or be taken off hold.</p> <p>If the connection manager can immediately tell that the requested state change could not possibly succeed, this method SHOULD return the NotAvailable error. If the requested state is the same as the current state, this method SHOULD return successfully without doing anything.</p> <p>Otherwise, this method SHOULD immediately set the hold state to Local_Hold_State_Pending_Hold or Local_Hold_State_Pending_Unhold (as appropriate), emitting <tp:member-ref>HoldStateChanged</tp:member-ref> if this is a change, and return successfully.</p> <p>The eventual success or failure of the request is indicated by a subsequent HoldStateChanged signal, changing the hold state to Local_Hold_State_Held or Local_Hold_State_Unheld.</p> <p>If the channel has multiple streams, and the connection manager succeeds in changing the hold state of one stream but fails to change the hold state of another, it SHOULD attempt to revert all streams to their previous hold states.</p> <p>The following state transitions SHOULD be used, where appropriate:</p> <ul> <li>Successful hold: (Unheld, any reason) → (Pending_Hold, Requested) → (Held, Requested) </li> <li>Successful unhold: (Held, any reason) → (Pending_Unhold, Requested) → (Unheld, Requested) </li> <li>Attempting to unhold fails at the first attempt to acquire a resource: (Held, any reason) → (Pending_Unhold, Requested) → (Held, Resource_Not_Available) </li> <li>Attempting to unhold acquires one resource, but fails to acquire a second, and takes time to release the first: (Held, any reason) → (Pending_Unhold, Requested) → (Pending_Hold, Resource_Not_Available) → (Held, Resource_Not_Available) </li> </ul>

Emitted to indicate that the hold state has changed for this channel. This may occur as a consequence of you requesting a change with <tp:member-ref>RequestHold</tp:member-ref>, or the state changing as a result of a request from another process.