path: root/spec/Media_Stream_Handler.xml

<?xml version="1.0" ?>
<node name="/Media_Stream_Handler" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
  <tp:copyright> Copyright (C) 2005-2008 Collabora Limited </tp:copyright>
  <tp:copyright> Copyright (C) 2005-2008 Nokia Corporation </tp:copyright>
  <tp:copyright> Copyright (C) 2006 INdT </tp:copyright>
  <tp:license xmlns="http://www.w3.org/1999/xhtml">
    <p>This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.</p>

<p>This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Lesser General Public License for more details.</p>

<p>You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</p>
  </tp:license>
  <interface name="org.freedesktop.Telepathy.Media.StreamHandler">

    <tp:docstring>
    Handles signalling the information pertaining to a specific media stream.
    A client should provide information to this handler as and when it is
    available.
    </tp:docstring>

    <tp:struct name="Media_Stream_Handler_Candidate"
      array-name="Media_Stream_Handler_Candidate_List">
      <tp:member type="s" name="Name"/>
      <tp:member type="a(usuussduss)" name="Transports"
        tp:type="Media_Stream_Handler_Transport[]"/>
    </tp:struct>

    <tp:struct name="Media_Stream_Handler_Transport"
      array-name="Media_Stream_Handler_Transport_List">
      <tp:member type="u" name="Component_Number"/>
      <tp:member type="s" name="IP_Address"/>
      <tp:member type="u" name="Port"/>
      <tp:member type="u" tp:type="Media_Stream_Base_Proto" name="Protocol"/>
      <tp:member type="s" name="Subtype"/>
      <tp:member type="s" name="Profile"/>
      <tp:member type="d" name="Preference_Value"/>
      <tp:member type="u" tp:type="Media_Stream_Transport_Type"
        name="Transport_Type"/>
      <tp:member type="s" name="Username"/>
      <tp:member type="s" name="Password"/>
    </tp:struct>

    <tp:struct name="Media_Stream_Handler_Codec"
      array-name="Media_Stream_Handler_Codec_List">
      <tp:docstring>
        Information about a codec supported by a client or a peer's client.
      </tp:docstring>

      <tp:member type="u" name="Codec_ID">
        <tp:docstring>
          The codec's payload identifier, as per RFC 3551 (static or dynamic)
        </tp:docstring>
      </tp:member>
      <tp:member type="s" name="Name">
        <tp:docstring>The codec's name</tp:docstring>
      </tp:member>
      <tp:member type="u" tp:type="Media_Stream_Type" name="Media_Type">
        <tp:docstring>Type of stream this codec supports</tp:docstring>
      </tp:member>
      <tp:member type="u" name="Clock_Rate">
        <tp:docstring>Sampling frequency in Hertz</tp:docstring>
      </tp:member>
      <tp:member type="u" name="Number_Of_Channels">
        <tp:docstring>Number of supported channels</tp:docstring>
      </tp:member>
      <tp:member type="a{ss}" name="Parameters" tp:type="String_String_Map">
        <tp:docstring>Codec-specific optional parameters</tp:docstring>
      </tp:member>
    </tp:struct>

    <property name="STUNServers" tp:name-for-bindings="STUN_Servers"
      type="a(sq)" tp:type="Socket_Address_IP[]" access="read">
      <tp:added version="0.17.22"/>
      <tp:docstring>
        The IP addresses of possible STUN servers to use for NAT traversal, as
        dotted-quad IPv4 address literals or RFC2373 IPv6 address literals.
        This property cannot change once the stream has been created, so there
        is no change notification. The IP addresses MUST NOT be given as DNS
        hostnames.

        <tp:rationale>
          High-quality connection managers already need an asynchronous
          DNS resolver, so they might as well resolve this name to an IP
          to make life easier for streaming implementations.
        </tp:rationale>
      </tp:docstring>
    </property>

    <property name="CreatedLocally" tp:name-for-bindings="Created_Locally"
      type="b" access="read">
      <tp:added version="0.17.22"/>
      <tp:docstring>
        True if we were the creator of this stream, false otherwise.
        <tp:rationale>
          This information is needed for some nat traversal mechanisms, such
          as ICE-UDP, where the creator gets the role of the controlling agent.
        </tp:rationale>
      </tp:docstring>
    </property>

    <property name="NATTraversal" tp:name-for-bindings="NAT_Traversal"
      type="s" access="read">
      <tp:added version="0.17.22"/>
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>The transport (NAT traversal technique) to be used for this
          stream. Well-known values include:</p>

        <dl>
          <dt>none</dt>
          <dd>Raw UDP, with or without STUN, should be used. If the
            <tp:member-ref>STUNServers</tp:member-ref> property is non-empty,
            STUN SHOULD be used.</dd>

          <dt>stun</dt>
          <dd>A deprecated synonym for 'none'.</dd>

          <dt>gtalk-p2p</dt>
          <dd>Google Talk peer-to-peer connectivity establishment should be
            used, as implemented in libjingle 0.3.</dd>

          <dt>ice-udp</dt>
          <dd>Interactive Connectivity Establishment should be used,
            as defined by the IETF MMUSIC working group.</dd>

          <dt>wlm-8.5</dt>
          <dd>The transport used by Windows Live Messenger 8.5 or later,
            which resembles ICE draft 6, should be used.</dd>

          <dt>wlm-2009</dt>
          <dd>The transport used by Windows Live Messenger 2009 or later,
            which resembles ICE draft 19, should be used.</dd>
        </dl>

        <p>This property cannot change once the stream has been created, so
          there is no change notification.</p>
      </tp:docstring>
    </property>

    <property name="RelayInfo" type="aa{sv}" access="read"
      tp:type="String_Variant_Map[]" tp:name-for-bindings="Relay_Info">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>A list of mappings describing TURN or Google relay servers
          available for the client to use in its candidate gathering, as
          determined from the protocol. Map keys are:</p>

        <dl>
          <dt><code>ip</code> - s</dt>
          <dd>The IP address of the relay server as a dotted-quad IPv4
            address literal or an RFC2373 IPv6 address literal. This MUST NOT
            be a DNS hostname.

            <tp:rationale>
              High-quality connection managers already need an asynchronous
              DNS resolver, so they might as well resolve this name to an IP
              and make life easier for streaming implementations.
            </tp:rationale>
          </dd>

          <dt><code>type</code> - s</dt>
          <dd>
            <p>Either <code>udp</code> for UDP (UDP MUST be assumed if this
              key is omitted), <code>tcp</code> for TCP, or
              <code>tls</code>.</p>

            <p>The precise meaning of this key depends on the
              <tp:member-ref>NATTraversal</tp:member-ref> property: if
              NATTraversal is <code>ice-udp</code>, <code>tls</code> means
              TLS over TCP as referenced by ICE draft 19, and if
              NATTraversal is <code>gtalk-p2p</code>, <code>tls</code> means
              a fake SSL session over TCP as implemented by libjingle.</p>
          </dd>

          <dt><code>port</code> - q</dt>
          <dd>The UDP or TCP port of the relay server as an ASCII unsigned
            integer</dd>

          <dt><code>username</code> - s</dt>
          <dd>The username to use</dd>

          <dt><code>password</code> - s</dt>
          <dd>The password to use</dd>

          <dt><code>component</code> - u</dt>
          <dd>The component number to use this relay server for, as an
            ASCII unsigned integer; if not included, this relay server
            may be used for any or all components.

            <tp:rationale>
              In ICE draft 6, as used by Google Talk, credentials are only
              valid once, so each component needs relaying separately.
            </tp:rationale>
          </dd>
        </dl>

        <tp:rationale>
          <p>An equivalent of the gtalk-p2p-relay-token property on
            MediaSignalling channels is not included here. The connection
            manager should be responsible for making the necessary HTTP
            requests to turn the token into a username and password.</p>
        </tp:rationale>

        <p>The type of relay server that this represents depends on
          the value of the <tp:member-ref>NATTraversal</tp:member-ref>
          property. If NATTraversal is ice-udp, this is a TURN server;
          if NATTraversal is gtalk-p2p, this is a Google relay server;
          otherwise, the meaning of RelayInfo is undefined.</p>

        <p>If relaying is not possible for this stream, the list is empty.</p>

        <p>This property cannot change once the stream has been created, so
          there is no change notification.</p>
      </tp:docstring>
    </property>

    <signal name="AddRemoteCandidate"
      tp:name-for-bindings="Add_Remote_Candidate">
      <arg name="Candidate_ID" type="s">
        <tp:docstring>
          String identifier for this candidate
        </tp:docstring>
      </arg>
      <arg name="Transports" type="a(usuussduss)"
        tp:type="Media_Stream_Handler_Transport[]">
        <tp:docstring>
          Array of transports for this candidate with fields,
          as defined in NewNativeCandidate
        </tp:docstring>
      </arg>
      <tp:docstring>
        Signal emitted when the connection manager wishes to inform the
        client of a new remote candidate.
      </tp:docstring>
    </signal>
    <signal name="Close" tp:name-for-bindings="Close">
      <tp:docstring>
        Signal emitted when the connection manager wishes the stream to be
        closed.
      </tp:docstring>
    </signal>
    <method name="CodecChoice" tp:name-for-bindings="Codec_Choice">
      <arg direction="in" name="Codec_ID" type="u"/>
      <tp:docstring>
        Inform the connection manager of codec used to receive data.
      </tp:docstring>
    </method>
    <method name="Error" tp:name-for-bindings="Error">
      <arg direction="in" name="Error_Code" type="u" tp:type="Media_Stream_Error">
        <tp:docstring>
          ID of error, from the MediaStreamError enumeration
        </tp:docstring>
      </arg>
      <arg direction="in" name="Message" type="s">
        <tp:docstring>
          String describing the error
        </tp:docstring>
      </arg>
      <tp:docstring>
        Inform the connection manager that an error occured in this stream. The
        connection manager should emit the StreamError signal for the stream on
        the relevant channel, and remove the stream from the session.
      </tp:docstring>
    </method>
    <tp:enum name="Media_Stream_Error" type="u">
      <tp:enumvalue suffix="Unknown" value="0">
        <tp:docstring>
          An unknown error occured.
        </tp:docstring>
      </tp:enumvalue>
      <tp:enumvalue suffix="EOS" value="1">
        <tp:docstring>
          The end of the stream was reached.
        </tp:docstring>
        <tp:deprecated version="0.17.27">
          This error has no use anywhere. In Farsight 1 times, it was used to
          indicate a GStreamer EOS (when the end of a file is reached). But
          since this is for live calls, it makes no sense.
        </tp:deprecated>
      </tp:enumvalue>
      <tp:enumvalue suffix="Codec_Negotiation_Failed" value="2">
        <tp:added version="0.17.27"/>
        <tp:docstring>
          There are no common codecs between the local side
          and the other particpants in the call. The possible codecs are not
          signalled here: the streaming implementation is assumed to report
          them in an implementation-dependent way, e.g. Farsight should use
          GstMissingElement.
        </tp:docstring>
      </tp:enumvalue>
      <tp:enumvalue suffix="Connection_Failed" value="3">
        <tp:added version="0.17.27"/>
        <tp:docstring>
          A network connection for the Media could not be established or was
          lost.
        </tp:docstring>
      </tp:enumvalue>
      <tp:enumvalue suffix="Network_Error" value="4">
        <tp:added version="0.17.27"/>
        <tp:docstring>
          There was an error in the networking stack
          (other than the connection failure).
        </tp:docstring>
      </tp:enumvalue>
      <tp:enumvalue suffix="No_Codecs" value="5">
        <tp:added version="0.17.27"/>
        <tp:docstring>
          There are no installed codecs for this media type.
        </tp:docstring>
      </tp:enumvalue>
      <tp:enumvalue suffix="Invalid_CM_Behavior" value="6">
        <tp:added version="0.17.27"/>
        <tp:docstring>
          The CM is doing something wrong.
        </tp:docstring>
      </tp:enumvalue>
      <tp:enumvalue suffix="Media_Error" value="7">
        <tp:added version="0.17.27"/>
        <tp:docstring>
          There was an error in the media processing stack.
        </tp:docstring>
      </tp:enumvalue>
    </tp:enum>
    <method name="NativeCandidatesPrepared"
      tp:name-for-bindings="Native_Candidates_Prepared">
      <tp:docstring>
        Informs the connection manager that all possible native candisates
        have been discovered for the moment.
      </tp:docstring>
    </method>
    <method name="NewActiveCandidatePair"
      tp:name-for-bindings="New_Active_Candidate_Pair">
      <arg direction="in" name="Native_Candidate_ID" type="s"/>
      <arg direction="in" name="Remote_Candidate_ID" type="s"/>
      <tp:docstring>
        Informs the connection manager that a valid candidate pair
        has been discovered and streaming is in progress.
      </tp:docstring>
    </method>
    <method name="NewActiveTransportPair"
      tp:name-for-bindings="New_Active_Transport_Pair">
      <arg direction="in" name="Native_Candidate_ID" type="s"/>
      <arg direction="in" name="Native_Transport" type="(usuussduss)"
        tp:type="Media_Stream_Handler_Transport"/>
      <arg direction="in" name="Remote_Candidate_ID" type="s"/>
      <arg direction="in" name="Remote_Transport" type="(usuussduss)"
        tp:type="Media_Stream_Handler_Transport"/>
      <tp:docstring>
        <p>Informs the connection manager that a valid transport pair
          has been discovered and streaming is in progress. Component
          id MUST be the same for both transports and the pair is
          only valid for that component.</p>

        <tp:rationale>
          <p>The connection manager might need to send the details of
            the active transport pair (e.g. c and o parameters of SDP
            body need to contain address of selected native RTP transport
            as stipulated by RFC 5245). However, the candidate ID might
            not be enough to determine these info if the transport was
            found after <tp:member-ref>NativeCandidatesPrepared</tp:member-ref>
            has been called (e.g. peer reflexive ICE candidate). </p>
        </tp:rationale>

        <p>This method must be called before
          <tp:member-ref>NewActiveCandidatePair</tp:member-ref>.</p>

        <tp:rationale>
          <p>This way, connection managers supporting this method can
            safely ignore subsequent
            <tp:member-ref>NewActiveCandidatePair</tp:member-ref> call.</p>
        </tp:rationale>

        <p>Connection managers SHOULD NOT implement this method unless
          they need to inform the peer about selected transports. As a
          result, streaming implementations MUST NOT treat errors raised
          by this method as fatal.</p>

        <tp:rationale>
          <p>Usually, connection managers only need to do one answer/offer
            round-trip. However, some protocols give the possibility to
            to send an updated offer (e.g. ICE defines such mechanism to
            avoid some race conditions and to properly set the state of
            gateway devices).</p>
        </tp:rationale>
      </tp:docstring>
    </method>
    <tp:enum name="Media_Stream_Base_Proto" type="u">
      <tp:enumvalue suffix="UDP" value="0">
        <tp:docstring>UDP (User Datagram Protocol)</tp:docstring>
      </tp:enumvalue>
      <tp:enumvalue suffix="TCP" value="1">
        <tp:docstring>TCP (Transmission Control Protocol)</tp:docstring>
      </tp:enumvalue>
    </tp:enum>
    <method name="NewNativeCandidate"
      tp:name-for-bindings="New_Native_Candidate">
      <arg direction="in" name="Candidate_ID" type="s">
        <tp:docstring>
          String identifier for this candidate
        </tp:docstring>
      </arg>
      <arg direction="in" name="Transports" type="a(usuussduss)"
        tp:type="Media_Stream_Handler_Transport[]">
        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
          Array of transports for this candidate, with fields:
          <ul>
            <li>component number</li>
            <li>IP address (as a string)</li>
            <li>port</li>
            <li>base network protocol (one of the values of MediaStreamBaseProto)</li>
            <li>proto subtype (e.g. RTP)</li>
            <li>proto profile (e.g. AVP)</li>
            <li>our preference value of this transport (double in range 0.0-1.0
              inclusive); 1 signals the most preferred transport</li>
            <li>transport type, one of the values of MediaStreamTransportType</li>
            <li>username if authentication is required</li>
            <li>password if authentication is required</li>
          </ul>
        </tp:docstring>
      </arg>
      <tp:docstring>
        Inform this MediaStreamHandler that a new native transport candidate
        has been ascertained.
      </tp:docstring>
    </method>
    <tp:enum name="Media_Stream_Transport_Type" type="u">
      <tp:enumvalue suffix="Local" value="0">
        <tp:docstring>
          A local address
        </tp:docstring>
      </tp:enumvalue>
      <tp:enumvalue suffix="Derived" value="1">
        <tp:docstring>
          An external address derived by a method such as STUN
        </tp:docstring>
      </tp:enumvalue>
      <tp:enumvalue suffix="Relay" value="2">
        <tp:docstring>
          An external stream relay
        </tp:docstring>
      </tp:enumvalue>
    </tp:enum>
    <method name="Ready" tp:name-for-bindings="Ready">
      <arg direction="in" name="Codecs" type="a(usuuua{ss})"
        tp:type="Media_Stream_Handler_Codec[]">
        <tp:docstring>
          Locally-supported codecs.
        </tp:docstring>
      </arg>
      <tp:docstring>
        Inform the connection manager that a client is ready to handle
        this StreamHandler. Also provide it with info about all supported
        codecs.
      </tp:docstring>
    </method>
    <method name="SetLocalCodecs" tp:name-for-bindings="Set_Local_Codecs">
      <arg name="Codecs" type="a(usuuua{ss})" direction="in"
        tp:type="Media_Stream_Handler_Codec[]">
        <tp:docstring>
          Locally-supported codecs
        </tp:docstring>
      </arg>
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>Used to provide codecs after Ready(), so the media client can go
          ready for an incoming call and exchange candidates/codecs before
          knowing what local codecs are available.</p>

        <p>This is useful for gatewaying calls between two connection managers.
          Given an incoming call, you need to call
          <tp:member-ref>Ready</tp:member-ref> to get the remote codecs before
          you can use them as the "local" codecs to place the outgoing call,
          and hence receive the outgoing call's remote codecs to use as the
          incoming call's "local" codecs.</p>

        <p>In this situation, you would pass an empty list of codecs to the
          incoming call's Ready method, then later call SetLocalCodecs on the
          incoming call in order to respond to the offer.</p>
      </tp:docstring>
    </method>
    <signal name="RemoveRemoteCandidate"
      tp:name-for-bindings="Remove_Remote_Candidate">
      <arg name="Candidate_ID" type="s">
        <tp:docstring>
          String identifier for remote candidate to drop
        </tp:docstring>
      </arg>
      <tp:deprecated version="0.17.18">
        There is no case where you want to release candidates (except
        for an ICE reset, and there you'd want to replace then all,
        using <tp:member-ref>SetRemoteCandidateList</tp:member-ref>).
      </tp:deprecated>
      <tp:docstring>
        Signal emitted when the connection manager wishes to inform the
        client that the remote end has removed a previously usable
        candidate.

        <tp:rationale>
          It seemed like a good idea at the time, but wasn't.
        </tp:rationale>
      </tp:docstring>
    </signal>
    <signal name="SetActiveCandidatePair"
      tp:name-for-bindings="Set_Active_Candidate_Pair">
      <arg name="Native_Candidate_ID" type="s"/>
      <arg name="Remote_Candidate_ID" type="s"/>
      <tp:docstring>
        Emitted by the connection manager to inform the client that a
        valid candidate pair has been discovered by the remote end
        and streaming is in progress.
      </tp:docstring>
    </signal>
    <signal name="SetRemoteCandidateList"
      tp:name-for-bindings="Set_Remote_Candidate_List">
      <arg name="Remote_Candidates" type="a(sa(usuussduss))"
        tp:type="Media_Stream_Handler_Candidate[]">
        <tp:docstring>
        A list of candidate id and a list of transports
        as defined in NewNativeCandidate
        </tp:docstring>
      </arg>
      <tp:docstring>
        Signal emitted when the connection manager wishes to inform the
        client of all the available remote candidates at once.
      </tp:docstring>
    </signal>
    <signal name="SetRemoteCodecs" tp:name-for-bindings="Set_Remote_Codecs">
      <arg name="Codecs" type="a(usuuua{ss})"
        tp:type="Media_Stream_Handler_Codec[]">
        <tp:docstring>
          Codecs supported by the remote peer.
        </tp:docstring>
      </arg>
      <tp:docstring>
        Signal emitted when the connection manager wishes to inform the
        client of the codecs supported by the remote end.
        If these codecs are compatible with the remote codecs, then the client
        must call <tp:member-ref>SupportedCodecs</tp:member-ref>,
        otherwise call <tp:member-ref>Error</tp:member-ref>.
      </tp:docstring>
    </signal>
    <signal name="SetStreamPlaying" tp:name-for-bindings="Set_Stream_Playing">
      <arg name="Playing" type="b"/>
      <tp:docstring>
        If emitted with argument TRUE, this means that the connection manager
        wishes to set the stream playing; this means that the streaming
        implementation should expect to receive data. If emitted with argument
        FALSE this signal is basically meaningless and should be ignored.

        <tp:rationale>
          We're very sorry.
        </tp:rationale>
      </tp:docstring>
    </signal>
    <signal name="SetStreamSending" tp:name-for-bindings="Set_Stream_Sending">
      <arg name="Sending" type="b"/>
      <tp:docstring>
        Signal emitted when the connection manager wishes to set whether or not
        the stream sends to the remote end.
      </tp:docstring>
    </signal>
    <signal name="StartTelephonyEvent"
      tp:name-for-bindings="Start_Telephony_Event">
      <arg name="Event" type="y" tp:type="DTMF_Event">
        <tp:docstring>
          A telephony event code.
        </tp:docstring>
      </arg>
      <tp:docstring>
        Request that a telephony event (as defined by RFC 4733) is transmitted
        over this stream until StopTelephonyEvent is called.
      </tp:docstring>
    </signal>
    <signal name="StartNamedTelephonyEvent"
      tp:name-for-bindings="Start_Named_Telephony_Event">
      <tp:added version="0.21.2"/>
      <arg name="Event" type="y" tp:type="DTMF_Event">
        <tp:docstring>
          A telephony event code as defined by RFC 4733.
        </tp:docstring>
      </arg>
     <arg name="Codec_ID" type="u">
        <tp:docstring>
          The payload type to use when sending events. The value 0xFFFFFFFF
          means to send with the already configured event type instead of using
          the specified one.
        </tp:docstring>
      </arg>
      <tp:docstring>
        Request that a telephony event (as defined by RFC 4733) is transmitted
        over this stream until StopTelephonyEvent is called. This differs from
        StartTelephonyEvent in that you force the event to be transmitted
        as a RFC 4733 named event, not as sound. You can also force a specific
        Codec ID.
      </tp:docstring>
    </signal>
    <signal name="StartSoundTelephonyEvent"
      tp:name-for-bindings="Start_Sound_Telephony_Event">
      <tp:added version="0.21.2"/>
      <arg name="Event" type="y" tp:type="DTMF_Event">
        <tp:docstring>
          A telephony event code as defined by RFC 4733.
        </tp:docstring>
      </arg>
      <tp:docstring>
        Request that a telephony event (as defined by RFC 4733) is transmitted
        over this stream until StopTelephonyEvent is called. This differs from
        StartTelephonyEvent in that you force the event to be transmitted
        as sound instead of as a named event.
      </tp:docstring>
    </signal>
    <signal name="StopTelephonyEvent"
      tp:name-for-bindings="Stop_Telephony_Event">
      <tp:docstring>
        Request that any ongoing telephony events (as defined by RFC 4733)
        being transmitted over this stream are stopped.
      </tp:docstring>
    </signal>
    <method name="StreamState" tp:name-for-bindings="Stream_State">
      <arg direction="in" name="State" type="u" tp:type="Media_Stream_State"/>
      <tp:docstring>
        Informs the connection manager of the stream's current state, as
        as specified in Channel.Type.StreamedMedia::ListStreams.
      </tp:docstring>
    </method>

    <method name="SupportedCodecs" tp:name-for-bindings="Supported_Codecs">
      <arg direction="in" name="Codecs" type="a(usuuua{ss})"
        tp:type="Media_Stream_Handler_Codec[]">
        <tp:docstring>
          Locally supported codecs.
        </tp:docstring>
      </arg>
      <tp:docstring>
        Inform the connection manager of the supported codecs for this session.
        This is called after the connection manager has emitted SetRemoteCodecs
        to notify what codecs are supported by the peer, and will thus be an
        intersection of all locally supported codecs (passed to Ready)
        and those supported by the peer.
      </tp:docstring>
    </method>

    <method name="CodecsUpdated" tp:name-for-bindings="Codecs_Updated">
      <arg direction="in" name="Codecs" type="a(usuuua{ss})"
        tp:type="Media_Stream_Handler_Codec[]">
        <tp:docstring>
          Locally supported codecs, which SHOULD be the same as were previously
          in effect, but possibly with different parameters.
        </tp:docstring>
      </arg>
      <tp:docstring>
        Inform the connection manager that the parameters of the supported
        codecs for this session have changed. The connection manager should
        send the new parameters to the remote contact.

        <tp:rationale>
          This is required for H.264 and Theora, for example.
        </tp:rationale>
      </tp:docstring>
    </method>

    <signal name="SetStreamHeld" tp:name-for-bindings="Set_Stream_Held">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>Emitted when the connection manager wishes to place the stream on
          hold (so the streaming client should free hardware or software
          resources) or take the stream off hold (so the streaming client
          should reacquire the necessary resources).</p>

        <p>When placing a channel's streams on hold, the connection manager
          SHOULD notify the remote contact that this will be done (if
          appropriate in the protocol) before it emits this signal.</p>

        <tp:rationale>
          <p>It is assumed that relinquishing a resource will not fail.
            If it does, the call is probably doomed anyway.</p>
        </tp:rationale>

        <p>When unholding a channel's streams, the connection manager
          SHOULD emit this signal and wait for success to be indicated
          via HoldState before it notifies the remote contact that the
          channel has been taken off hold.</p>

        <tp:rationale>
          <p>This means that if a resource is unavailable, the remote
            contact will never even be told that we tried to acquire it.</p>
        </tp:rationale>
      </tp:docstring>
      <tp:added version="0.17.3"/>

      <arg name="Held" type="b">
        <tp:docstring>
          If true, the stream is to be placed on hold.
        </tp:docstring>
      </arg>
    </signal>

    <method name="HoldState" tp:name-for-bindings="Hold_State">
      <tp:docstring>
        Notify the connection manager that the stream's hold state has
        been changed successfully in response to SetStreamHeld.
      </tp:docstring>
      <tp:added version="0.17.3"/>
      <arg direction="in" name="Held" type="b">
        <tp:docstring>
          If true, the stream is now on hold.
        </tp:docstring>
      </arg>
    </method>

    <method name="UnholdFailure" tp:name-for-bindings="Unhold_Failure">
      <tp:docstring>
        Notify the connection manager that an attempt to reacquire the
        necessary hardware or software resources to unhold the stream,
        in response to SetStreamHeld, has failed.
      </tp:docstring>
      <tp:added version="0.17.3"/>
    </method>

    <tp:struct name="RTCP_Feedback_Message_Properties">
      <tp:added version="0.22.1"/>
      <tp:changed version="0.23.4">This struct is also used by Call, but
        in call, the CM should know about RTP profiles, and never use MAXUINT
        as a default value, because it complicates things unnecessarily.
      </tp:changed>
      <tp:member type="u" name="RTCPMinimumInterval">
        <tp:docstring>
          The minimum interval between two regular RTCP packets in
          milliseconds for this content. If no special value is desired, one
          should put MAXUINT (0xFFFFFFFF).

          Implementors and users of Call's <tp:dbus-ref
          namespace="ofdT.Call1.Content.MediaDescription.Interface"
          >RTCPFeedback</tp:dbus-ref> should not use the MAXUINT default.
          Instead, in RTP/AVP, the default should be 5000 (5 seconds).
          If using the RTP/AVPF profile, it can be set to a lower value,
          the default being 0.
        </tp:docstring>
      </tp:member>
      <tp:member type="a(sss)" tp:type="RTCP_Feedback_Message[]"
                 name="Messages">
        <tp:docstring>
          The RTCP feedback messages for this codec.
        </tp:docstring>
      </tp:member>
    </tp:struct>

    <tp:struct name="RTCP_Feedback_Message"
               array-name="RTCP_Feedback_Message_List">
      <tp:added version="0.22.1"/>
      <tp:docstring>
        A struct defining an RTCP feedback message.
      </tp:docstring>
      <tp:member type="s" name="Type">
        <tp:docstring>
          Feedback type, for example "ack", "nack", or "ccm".
        </tp:docstring>
      </tp:member>
      <tp:member type="s" name="Subtype">
        <tp:docstring>
          Feedback subtype, according to the Type, can be an empty string (""),
          if there is no subtype.
          For example, generic nack is Type="nack" Subtype="".
        </tp:docstring>
      </tp:member>
      <tp:member type="s" name="Parameters">
        <tp:docstring>
          Feedback parameters as a string. Format is defined in the relevant RFC
        </tp:docstring>
      </tp:member>
    </tp:struct>

    <tp:mapping name="RTCP_Feedback_Message_Map">
      <tp:added version="0.22.1"/>
      <tp:docstring>
        A map of codec and its feedback properties.
      </tp:docstring>
      <tp:member type="u" name="Codec_Identifier">
        <tp:docstring>
          Numeric identifier for the codec. This will be used as the
          PT in the SDP or content description.
        </tp:docstring>
      </tp:member>
      <tp:member type="(ua(sss))" tp:type="RTCP_Feedback_Message_Properties"
                 name="Properties">
        <tp:docstring>
          The RTCP feedback properties for this codec.
        </tp:docstring>
      </tp:member>
    </tp:mapping>

    <signal name="SetRemoteFeedbackMessages"
            tp:name-for-bindings="Set_Remote_Feedback_Messages">
      <tp:added version="0.22.1"/>
      <arg name="Messages" type="a{u(ua(sss))}"
           tp:type="RTCP_Feedback_Message_Map">
        <tp:docstring>
          Remote Feedback messages desired by the remote side
        </tp:docstring>
      </arg>
      <tp:docstring>
        Signal emitted when the connection manager wishes to inform the
        client of the feedback messages supported by the remote end.
        This signal is emitted before
        <tp:member-ref>SetRemoteCodecs</tp:member-ref>. If the client
        supports any of these messages, it must call
        <tp:member-ref>SupportedFeedbackMessages</tp:member-ref> before calling
        <tp:member-ref>SupportedCodecs</tp:member-ref>.
      </tp:docstring>
    </signal>

    <method name="SupportedFeedbackMessages"
            tp:name-for-bindings="Supported_Feedback_Messages">
      <tp:added version="0.22.1"/>
      <arg name="Messages" direction="in" type="a{u(ua(sss))}"
           tp:type="RTCP_Feedback_Message_Map">
        <tp:docstring>
          Locally supported feedback messages.
        </tp:docstring>
      </arg>
      <tp:docstring>
        Inform the connection manager of the supported feedback messages
        for this session.
        This is called a before calling
        <tp:member-ref>SupportedCodecs</tp:member-ref>,
        <tp:member-ref>Ready</tp:member-ref> or
        <tp:member-ref>CodecsUpdated</tp:member-ref> to indicate the local,
        or negotiated feedback messages.
      </tp:docstring>
    </method>

    <tp:struct name="RTP_Header_Extension"
      array-name="RTP_Header_Extensions_List">
      <tp:added version="0.22.1"/>
      <tp:docstring>
        A struct defining a RTP Header extension
      </tp:docstring>
      <tp:member type="u" name="ID">
        <tp:docstring>
          Identifier to be negotiated
        </tp:docstring>
      </tp:member>
      <tp:member type="u" tp:type="Media_Stream_Direction"  name="Direction">
        <tp:docstring>
          Direction in which the Header Extension is negotiated.
        </tp:docstring>
      </tp:member>
      <tp:member type="s" name="URI">
        <tp:docstring>
          URI defining the extension
        </tp:docstring>
      </tp:member>
      <tp:member type="s" name="Parameters">
        <tp:docstring>
          Feedback parameters as a string. Format is defined in the relevant RFC
        </tp:docstring>
      </tp:member>
    </tp:struct>

    <signal name="SetRemoteHeaderExtensions"
            tp:name-for-bindings="Set_Remote_Header_Extensions">
      <tp:added version="0.22.1"/>
      <arg name="Header_Extensions" type="a(uuss)"
           tp:type="RTP_Header_Extension[]">
        <tp:docstring>
          Header extensions desired by the remote side
        </tp:docstring>
      </arg>
      <tp:docstring>
        Signal emitted when the connection manager wishes to inform the
        client of the RTP header extensions supported by the remote end.
        This signal is emitted before
        <tp:member-ref>SetRemoteCodecs</tp:member-ref>. If the client
        supports any of these messages, it must call
        <tp:member-ref>SupportedHeaderExtensions</tp:member-ref> before calling
        <tp:member-ref>SupportedCodecs</tp:member-ref>.
      </tp:docstring>
    </signal>

    <method name="SupportedHeaderExtensions"
            tp:name-for-bindings="Supported_Header_Extensions">
      <tp:added version="0.22.1"/>
      <arg name="Header_Extensions" direction="in" type="a(uuss)"
           tp:type="RTP_Header_Extension[]">
        <tp:docstring>
          Locally supported RTP header extensions.
        </tp:docstring>
      </arg>
      <tp:docstring>
        Inform the connection manager of the supported RTP header extensions
        for this session.
        This is called before calling
        <tp:member-ref>SupportedCodecs</tp:member-ref>,
        <tp:member-ref>Ready</tp:member-ref> or
        <tp:member-ref>CodecsUpdated</tp:member-ref> to indicate the local
        or negotiated RTP header extensions.
      </tp:docstring>
    </method>

  </interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->