Interface Channel.Type.StreamedMedia

Interface Index (Compact) | Summary | Description | Methods | Signals | Properties | Types

Methods

ListStreams () → a(uuuuuu): Streams
RemoveStreams (au: Streams) → nothing
RequestStreamDirection (u: Stream_ID, u: Stream_Direction) → nothing
RequestStreams (u: Contact_Handle, au: Types) → a(uuuuuu): Streams

Signals

StreamAdded (u: Stream_ID, u: Contact_Handle, u: Stream_Type)
StreamDirectionChanged (u: Stream_ID, u: Stream_Direction, u: Pending_Flags)
StreamError (u: Stream_ID, u: Error_Code, s: Message)
StreamRemoved (u: Stream_ID)
StreamStateChanged (u: Stream_ID, u: Stream_State)

Properties

InitialAudio b Read only
InitialVideo b Read only
ImmutableStreams b Read only

Types

Stream_ID Simple Type u
Media_Stream_Type Enum u
Media_Stream_State Enum u
Media_Stream_Direction Enum u
Media_Stream_Pending_Send Flags u
Channel_Media_Capabilities Flags u
Media_Stream_Info Struct (uuuuuu)
Objects implementing this interface must also implement:

Description

A channel that can send and receive streamed media such as audio or video. Provides a number of methods for listing and requesting new streams, and signals to indicate when streams have been added, removed and changed status.

To make a media call to a contact, clients should call CreateChannel with ChannelType = StreamedMedia, TargetHandleType = Contact, and one of TargetHandle or TargetID (which should yield a channel with the local user in Members, and the remote contact as TargetHandle but not in any group members list), then call RequestStreams to initiate the call (at which point the contact should appear in the channel's RemotePendingMembers).

In the past, several other patterns have been used to place outgoing calls; see 'Requesting StreamedMedia Channels' on the Telepathy wiki for the details.

Incoming calls should be signalled as TargetHandleType = Contact, TargetHandle set to the remote contact, with the local user in LocalPendingMembers; to accept the call, AddMembers can be used to move the local user to the group's members.

When the local user accepts an incoming call, the connection manager SHOULD change the direction of any streams with pending local send to be sending, without altering whether those streams are receiving.

Rationale:

This matches existing practice, and means that a client can answer incoming calls and get an unmuted microphone/activated webcam without having to take additional action to accept the stream directions.

It does, however, introduce a race condition: a client believing that it is accepting an audio-only call by calling AddMembers can inadvertantly accept an audio + video call (and hence activate sending from a webcam without the user's permission) if a video stream is added just before AddMembers is processed. This race should be removed when this specification is revised.

In general this should be used in conjunction with the MediaSignalling interface to exchange connection candidates and codec choices with whichever component is responsible for the streams. However, in certain applications where no candidate exchange is necessary (eg the streams are handled by specialised hardware which is controlled directly by the connection manager), the signalling interface can be omitted and this channel type used simply to control the streams.

Handler filters

For historical reasons, handlers must specify more than one filter if they want to correctly advertise support for audio and/or video calls. If they can handle channels using the MediaSignalling interface, they should also advertise various Handler_Capability_Tokens to indicate which codecs and transports they support. See InitialAudio and MediaSignalling/video/h264 for the gory details. In summary:

To advertise support for streamed media in general, include the following filter in HandlerChannelFilter:
{ '...Channel.Type': '...Channel.Type.StreamedMedia' ,
  '...Channel.TargetHandleType': Contact,
}
To advertise support for audio calls, also include the following filter:
{ '...Channel.Type': '...Channel.Type.StreamedMedia' ,
  '...Channel.TargetHandleType': Contact,
  '...Channel.Type.StreamedMedia.InitialAudio': True,
}
To advertise support for video calls, also include the following filter:
{ '...Channel.Type': '...Channel.Type.StreamedMedia' ,
  '...Channel.TargetHandleType': Contact,
  '...Channel.Type.StreamedMedia.InitialVideo': True,
}
If you use telepathy-farsight, and have H.264 support, you probably want these Capabilities:
[ "org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/ice-udp",
  "org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/gtalk-p2p",
  "org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264",
]

Methods

(Permalink)

ListStreams () → a(uuuuuu): Streams

Returns

  • Streams — a(uuuuuu) (Media_Stream_Info_List)
    • An array of structs containing:
    • the stream identifier
    • the contact handle who the stream is with (or 0 if the stream represents more than a single member)
    • the type of the stream
    • the current stream state
    • the current direction of the stream
    • the current pending send flags
Returns an array of structs representing the streams currently active within this channel. Each stream is identified by an unsigned integer which is unique for each stream within the channel.
(Permalink)

RemoveStreams (au: Streams) → nothing

Parameters

Request that the given streams are removed. If all streams are removed, the channel MAY close.

Clients SHOULD NOT attempt to terminate calls by removing all the streams; instead, clients SHOULD terminate calls by removing the Group.SelfHandle from the channel, using either RemoveMembers or RemoveMembersWithReason.

Possible Errors

(Permalink)

RequestStreamDirection (u: Stream_ID, u: Stream_Direction) → nothing

Parameters

  • Stream_ID — u
    • The stream identifier (as defined in ListStreams)
  • Stream_Direction — u (Media_Stream_Direction)
    • The desired stream direction (a value of MediaStreamDirection)

Request a change in the direction of an existing stream. In particular, this might be useful to stop sending media of a particular type, or inform the peer that you are no longer using media that is being sent to you.

Depending on the protocol, streams which are no longer sending in either direction should be removed and a StreamRemoved signal emitted. Some direction changes can be enforced locally (for example, BIDIRECTIONAL -> RECEIVE can be achieved by merely stopping sending), others may not be possible on some protocols, and some need agreement from the remote end. In this case, the MEDIA_STREAM_PENDING_REMOTE_SEND flag will be set in the StreamDirectionChanged signal, and the signal emitted again without the flag to indicate the resulting direction when the remote end has accepted or rejected the change.

Possible Errors

(Permalink)

RequestStreams (u: Contact_Handle, au: Types) → a(uuuuuu): Streams

Changed in 0.17.2.

It is valid to use a handle which is neither a current nor pending member in this channel's Group interface. If so, that handle will be added to the remote-pending set only when an attempt has actually been made to contact them. For further call-state notification, use the CallState interface, if supported. This usage was not allowed in spec versions below 0.17.2.

Parameters

  • Contact_Handle — u (Contact_Handle)
    • A contact handle with whom to establish the streams
  • Types — au (Media_Stream_Type_List)
    • An array of stream types (values of MediaStreamType)

Returns

  • Streams — a(uuuuuu) (Media_Stream_Info_List)
    • An array of structs (in the same order as the given stream types) containing:
    • the stream identifier
    • the contact handle who the stream is with (or 0 if the stream represents more than a single member)
    • the type of the stream
    • the current stream state
    • the current direction of the stream
    • the current pending send flags

Request that streams be established to exchange the given types of media with the given member. In general this will try and establish a bidirectional stream, but on some protocols it may not be possible to indicate to the peer that you would like to receive media, so a send-only stream will be created initially. In the cases where the stream requires remote agreement (eg you wish to receive media from them), the StreamDirectionChanged signal will be emitted with the MEDIA_STREAM_PENDING_REMOTE_SEND flag set, and the signal emitted again with the flag cleared when the remote end has replied.

If streams of the requested types already exist, calling this method results in the creation of additional streams. Accordingly, clients wishing to have exactly one audio stream or exactly one video stream SHOULD check for the current streams using ListStreams before calling this method.

Possible Errors

  • Invalid Handle
    • The handle specified is unknown on this channel or connection.
  • Invalid Argument
    • A stream type given is invalid.
  • Not Implemented
    • A stream type given is not implemented by the connection manager. Since 0.17.23, connection managers SHOULD raise this error in preference to InvalidArgument.
    Rationale:
    Connection managers can't know whether an unknown number is a valid stream type that was introduced in a later spec version.
  • Not Available
    • That contact's client does not implement one of the given stream types. For this method, clients SHOULD consider this error and NotCapable to be equivalent.
  • Not Capable
    • That contact's client does not implement one of the given stream types. Since 0.17.23, connection managers SHOULD raise this in preference to NotAvailable.

Signals

(Permalink)

StreamAdded (u: Stream_ID, u: Contact_Handle, u: Stream_Type)

Parameters

  • Stream_ID — u
    • The stream identifier (as defined in ListStreams)
  • Contact_Handle — u (Contact_Handle)
    • The contact handle who the stream is with (or 0 if it represents more than a single member)
  • Stream_Type — u (Media_Stream_Type)
    • The stream type (a value from MediaStreamType)

Emitted when a new stream has been added to this channel. Clients SHOULD assume that the stream's Media_Stream_State is initially Disconnected.

If a connection manager needs to represent the addition of a stream whose state is already Connecting or Connected, it MUST do this by emitting StreamAdded, closely followed by StreamStateChanged indicating a change to the appropriate state.

Rationale:

Historically, it was not clear from the StreamAdded signal what the state of the stream was. telepathy-spec 0.17.22 clarified this.

Similarly, clients SHOULD assume that the initial Media_Stream_Direction of a newly added stream is Receive, and that the initial Media_Stream_Pending_Send is Pending_Local_Send.

If a connection manager needs to represent the addition of a stream whose direction or pending-send differs from those initial values, it MUST do so by emitting StreamAdded, closely followed by StreamDirectionChanged indicating a change to the appropriate direction and pending-send state.

Rationale:

StreamAdded doesn't itself indicate the stream's direction; this is unfortunate, but is preserved for compatibility.

This is the appropriate direction for streams added by a remote contact on existing connection managers, and does not violate user privacy by automatically sending audio or video (audio streams start off muted, video streams start off not sending). For streams added by the local user using the client receiving the signal, the true direction can also be determined from the return value of the RequestStreams method.

Existing clients typically operate by maintaining a separate idea of the directions that they would like the streams to have, and enforcing these intended directions by calling RequestStreamDirection whenever needed.

(Permalink)

StreamDirectionChanged (u: Stream_ID, u: Stream_Direction, u: Pending_Flags)

Parameters

Emitted when the direction or pending flags of a stream are changed.

If the MEDIA_STREAM_PENDING_LOCAL_SEND flag is set, the remote user has requested that we begin sending on this stream. RequestStreamDirection should be called to indicate whether or not this change is acceptable.

Rationale:

This allows for a MSN-style user interface, "Fred has asked you to enable your webcam. (Accept | Reject)", if desired.

(Permalink)

StreamError (u: Stream_ID, u: Error_Code, s: Message)

Parameters

  • Stream_ID — u
    • The stream identifier (as defined in ListStreams)
  • Error_Code — u (Media_Stream_Error)
    • A stream error number, one of the values of MediaStreamError
  • Message — s
    • A string describing the error (for debugging purposes only)
Emitted when a stream encounters an error.
(Permalink)

StreamRemoved (u: Stream_ID)

Parameters

  • Stream_ID — u
    • stream_id - the stream identifier (as defined in ListStreams)
Emitted when a stream has been removed from this channel.
(Permalink)

StreamStateChanged (u: Stream_ID, u: Stream_State)

Parameters

  • Stream_ID — u
    • The stream identifier (as defined in ListStreams)
  • Stream_State — u (Media_Stream_State)
    • The new stream state (as defined in ListStreams)
Emitted when a member's stream's state changes.

Properties

Accessed using the org.freedesktop.DBus.Properties interface.
(Permalink)

InitialAudio — b

Read only

If set to true in a channel request that will create a new channel, the connection manager should immediately attempt to establish an audio stream to the remote contact, making it unnecessary for the client to call RequestStreams.

If this property, or InitialVideo, is passed to EnsureChannel (as opposed to CreateChannel), the connection manager SHOULD ignore these properties when checking whether it can return an existing channel as suitable; these properties only become significant when the connection manager has decided to create a new channel.

If true on a requested channel, this indicates that the audio stream has already been requested and the client does not need to call RequestStreams, although it MAY still do so.

If true on an unrequested (incoming) channel, this indicates that the remote contact initially requested an audio stream; this does not imply that that audio stream is still active (as indicated by ListStreams).

This property is immutable (cannot change), and therefore SHOULD appear wherever immutable properties are reported, e.g. NewChannels signals.

Rationale:

This reduces D-Bus round trips.

Connection managers capable of signalling audio calls to contacts SHOULD include a channel class in RequestableChannelClasses with ChannelType = StreamedMedia and TargetHandleType = Contact in the fixed properties dictionary, and InitialAudio (and also InitialVideo, if applicable) in the allowed properties list. Clients wishing to discover whether a connection manager can signal audio and/or video calls SHOULD use this information.

Rationale:

Not all protocols support signalling video calls, and it would be possible (although unlikely) to have a protocol where only video, and not audio, could be signalled.

Connection managers that support the ContactCapabilities interface SHOULD represent the capabilities of receiving audio and/or video calls by including a channel class in a contact's capabilities with ChannelType = StreamedMedia in the fixed properties dictionary, and InitialAudio and/or InitialVideo in the allowed properties list. Clients wishing to discover whether a particular contact is likely to be able to receive audio and/or video calls SHOULD use this information.

Rationale:

Not all clients support video calls, and it would also be possible (although unlikely) to have a client which could only stream video, not audio.

Clients that are willing to receive audio and/or video calls SHOULD include the following among their channel classes if calling UpdateCapabilities (clients of a ChannelDispatcher SHOULD instead arrange for the ChannelDispatcher to do this, by including the filters in their HandlerChannelFilter properties):

  • { ChannelType = StreamedMedia }
  • { ChannelType = StreamedMedia, InitialAudio = true } if receiving calls with audio is supported
  • { ChannelType = StreamedMedia, InitialVideo = true } if receiving calls with video is supported
Rationale:

Connection managers for protocols with capability discovery, like XMPP, need this information to advertise the appropriate capabilities for their protocol.

(Permalink)

InitialVideo — b

Read only

The same as InitialAudio, but for a video stream. This property is immutable (cannot change).

In particular, note that if this property is false, this does not imply that an active video stream has not been added, only that no video stream was active at the time the channel appeared.

This property is the correct way to discover whether connection managers, contacts etc. support video calls; it appears in capabilities structures in the same way as InitialAudio.

(Permalink)

ImmutableStreams — b

Read only

If True, once streams have been requested for this channel (either by setting InitialAudio or InitialVideo when the channel is requested, or by calling RequestStreams on a channel with no streams), a stream of a different content type cannot be added; subsequent calls to RequestStreams that attempt to do so will fail.

If this property is missing, clients SHOULD assume that it is false, and thus that the channel's streams can be changed once the call has started.

If this property is present in the "allowed" set in all of the StreamedMedia entries in a contact's capabilities, then user interfaces MAY choose to show a separate "call" option for each class of call.

Rationale:

For example, once an audio-only Google Talk call has started, it is not possible to add a video stream; both audio and video must be requested at the start of the call if video is desired. User interfaces may use this pseudo-capability as a hint to display separate "Audio call" and "Video call" buttons, rather than a single "Call" button with the option to add and remove video once the call has started for contacts without this flag.

This property is immutable, and therefore SHOULD be announced in NewChannels, etc.

Types

Simple Type (Permalink)

Stream_ID — u

An unsigned integer identifying a stream within a channel.

Enum (Permalink)

Media_Stream_Type — u

  • Audio (0)
    • An audio stream
  • Video (1)
    • A video stream
Enum (Permalink)

Media_Stream_State — u

  • Disconnected (0)
    • The stream is disconnected.
  • Connecting (1)
    • The stream is trying to connect.
  • Connected (2)
    • The stream is connected.
Enum (Permalink)

Media_Stream_Direction — u

  • None (0)
    • Media are not being sent or received
  • Send (1)
    • Media are being sent, but not received
  • Receive (2)
    • Media are being received, but not sent
  • Bidirectional (3)
    • Media are being sent and received
Flags (Permalink)

Media_Stream_Pending_Send — u

  • Local_Send (1)
    • The local user has been asked to send media by the remote user. Call RequestStreamDirection to indicate whether or not this is acceptable.
  • Remote_Send (2)
    • The remote user has been asked to send media by the local user. The StreamDirectionChanged signal will be emitted when the remote user accepts or rejects this change.
Flags (Permalink)

Channel_Media_Capabilities — u

The channel-type-specific capability flags used for Channel.Type.StreamedMedia in the Connection.Interface.Capabilities interface. See the InitialAudio property for details of the mechanisms that will replace this.
  • Audio (1)
    • The handle is capable of using audio streams within a media channel.
  • Video (2)
    • The handle is capable of using video streams within a media channel.
  • NAT_Traversal_STUN (4)
    • The handle is capable of performing STUN to traverse NATs.
  • NAT_Traversal_GTalk_P2P (8)
    • The handle is capable of establishing Google Talk peer-to-peer connections (as implemented in libjingle 0.3) to traverse NATs.
  • NAT_Traversal_ICE_UDP (16)
    • The handle is capable of establishing ICE UDP peer-to-peer connections (as defined by the IETF MMUSIC working group) to traverse NATs.
  • Immutable_Streams (32)
    • Channels whose target handle is this contact will have ImmutableStreams = True.
Struct (Permalink)

Media_Stream_Info — (uuuuuu)