<commit_before><?xml version="1.0" ?>
<node name="/Call_Content_Media_Description"
  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
  <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
  <tp:copyright>Copyright © 2009-2010 Nokia Corporation</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.Call.Content.MediaDescription.DRAFT"
      tp:causes-havoc="experimental">
    <tp:added version="UNRELEASED">(draft 1)</tp:added>

    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
      This object represents a remote Description Offer to which the local
      streaming implementation should reply with its local Description.

      This is intended as a temporary transactional object for use with <tp:dbus-ref
          namespace="ofdT.Call">Content.Interface.Media.DRAFT2</tp:dbus-ref>.
      There will always be 0 or 1 MediaDescription object per Content.
      In most cases, this object will stay alive until you call either
      <tp:member-ref>Accept</tp:member-ref> or
      <tp:member-ref>Reject</tp:member-ref>, and then disappear.
      There are some cases (e.g. an endpoint being removed from the call)
      where a MediaDescription object will disappear before you have had a
      chance to either Accept or Reject it.
    </tp:docstring>

    <method name="Accept" tp:name-for-bindings="Accept">
      <arg name="Local_Media_Description" direction="in"
        type="a{sv}" tp:type="Media_Description_Properties">
        <tp:docstring>
          The local description to send to the remote contacts and
          to use in the <tp:dbus-ref
          namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>.
        </tp:docstring>
      </arg>
      <tp:docstring>
        Accepts the updated Description and update the corresponding
        local description. If FurtherNegotiationRequired is True,
        calling this method will generally cause a network round-trip
        and a new MediaDescription to be offered (hopefully with
        FurtherNegotiationRequired set to False).
      </tp:docstring>
      <tp:possible-errors>
        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
          <tp:docstring>
            The description given is invalid in some way.
          </tp:docstring>
        </tp:error>
      </tp:possible-errors>
    </method>

    <method name="Reject" tp:name-for-bindings="Reject">
      <tp:docstring>
        Reject the proposed update to the remote description
        FIXME add error codes and strings here
      </tp:docstring>
    </method>

    <property name="Interfaces" tp:name-for-bindings="Interfaces"
      type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>Extra interfaces provided by this media description. This SHOULD
          NOT include the Description interface itself.</p>
      </tp:docstring>
    </property>

    <property name="FurtherNegotiationRequired"
      tp:name-for-bindings="Further_Negotiation_Required" type="b"
      access="read" tp:immutable="yes">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml" >
        <p> 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.
        </p>
      </tp:docstring>
    </property>

    <property name="HasRemoteInformation"
      tp:name-for-bindings="Has_Remote_Information" type="b"
      access="read" tp:immutable="yes">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml" >
        <p> 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.
        </p>
      </tp:docstring>
    </property>

    <property name="Codecs"
      tp:name-for-bindings="Codecs"
      type="a(usuua{ss})" tp:type="Codec[]" access="read"
      tp:immutable="yes">
      <tp:docstring>
        A list of codecs the remote contact supports. When used with
        <tp:member-ref>Accept</tp:member-ref>, it means the locally supported
        codecs.
      </tp:docstring>
    </property>

    <property name="RemoteContact" tp:name-for-bindings="Remote_Contact"
      type="u" tp:type="Contact_Handle" access="read" tp:immutable="yes">
      <tp:docstring>
        The contact handle that this description applies to.

        This property can be used as an opaque identifier, and searched for in
        <tp:dbus-ref namespace="ofdT.Call.Stream.DRAFT"
        >RemoteMembers</tp:dbus-ref> for each Stream in this Content, to
        determine which Stream this MediaDescription applies to. If multiple
        MediaDescriptions apply to the same Stream, the
        <tp:member-ref>SSRCs</tp:member-ref> 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).
      </tp:docstring>
    </property>

    <property name="SSRCs" tp:name-for-bindings="SSRCs"
      type="au" access="read" tp:immutable="yes">
      <tp:docstring>
        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
        <tp:member-ref>Accept</tp:member-ref> with 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 the one in <tp:dbus-ref
        namespace="ofdT.Call.Content.Interface.Media.DRAFT2"
        >LocalMediaDescription</tp:dbus-ref>, then the streaming
        implementation should pick a new SSRC to resolve the collision.

        It is expected that this list will always be at most one element long,
        but it is kept as a list for extensibility. The concatenation of all
        SSRCs associated with a Stream hould 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.
      </tp:docstring>
    </property>

    <tp:mapping name="Media_Description_Properties">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>
          A mapping containing all properties that define the information from a
          <tp:dbus-ref
            namespace="ofdT.Call.Content"<commit_msg>SSRCs probably need to include handles as well.<commit_after><?xml version="1.0" ?>
<node name="/Call_Content_Media_Description"
  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
  <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
  <tp:copyright>Copyright © 2009-2010 Nokia Corporation</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.Call.Content.MediaDescription.DRAFT"
      tp:causes-havoc="experimental">
    <tp:added version="UNRELEASED">(draft 1)</tp:added>

    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
      This object represents a remote Description Offer to which the local
      streaming implementation should reply with its local Description.

      This is intended as a temporary transactional object for use with <tp:dbus-ref
          namespace="ofdT.Call">Content.Interface.Media.DRAFT2</tp:dbus-ref>.
      There will always be 0 or 1 MediaDescription object per Content.
      In most cases, this object will stay alive until you call either
      <tp:member-ref>Accept</tp:member-ref> or
      <tp:member-ref>Reject</tp:member-ref>, and then disappear.
      There are some cases (e.g. an endpoint being removed from the call)
      where a MediaDescription object will disappear before you have had a
      chance to either Accept or Reject it.
    </tp:docstring>

    <method name="Accept" tp:name-for-bindings="Accept">
      <arg name="Local_Media_Description" direction="in"
        type="a{sv}" tp:type="Media_Description_Properties">
        <tp:docstring>
          The local description to send to the remote contacts and
          to use in the <tp:dbus-ref
          namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>.
        </tp:docstring>
      </arg>
      <tp:docstring>
        Accepts the updated Description and update the corresponding
        local description. If FurtherNegotiationRequired is True,
        calling this method will generally cause a network round-trip
        and a new MediaDescription to be offered (hopefully with
        FurtherNegotiationRequired set to False).
      </tp:docstring>
      <tp:possible-errors>
        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
          <tp:docstring>
            The description given is invalid in some way.
          </tp:docstring>
        </tp:error>
      </tp:possible-errors>
    </method>

    <method name="Reject" tp:name-for-bindings="Reject">
      <tp:docstring>
        Reject the proposed update to the remote description
        FIXME add error codes and strings here
      </tp:docstring>
    </method>

    <property name="Interfaces" tp:name-for-bindings="Interfaces"
      type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>Extra interfaces provided by this media description. This SHOULD
          NOT include the Description interface itself.</p>
      </tp:docstring>
    </property>

    <property name="FurtherNegotiationRequired"
      tp:name-for-bindings="Further_Negotiation_Required" type="b"
      access="read" tp:immutable="yes">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml" >
        <p> 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.
        </p>
      </tp:docstring>
    </property>

    <property name="HasRemoteInformation"
      tp:name-for-bindings="Has_Remote_Information" type="b"
      access="read" tp:immutable="yes">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml" >
        <p> 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.
        </p>
      </tp:docstring>
    </property>

    <property name="Codecs"
      tp:name-for-bindings="Codecs"
      type="a(usuua{ss})" tp:type="Codec[]" access="read"
      tp:immutable="yes">
      <tp:docstring>
        A list of codecs the remote contact supports. When used with
        <tp:member-ref>Accept</tp:member-ref>, it means the locally supported
        codecs.
      </tp:docstring>
    </property>

    <property name="RemoteContact" tp:name-for-bindings="Remote_Contact"
      type="u" tp:type="Contact_Handle" access="read" tp:immutable="yes">
      <tp:docstring>
        The contact handle that this description applies to.

        This property can be used as an opaque identifier, and searched for in
        <tp:dbus-ref namespace="ofdT.Call.Stream.DRAFT"
        >RemoteMembers</tp:dbus-ref> for each Stream in this Content, to
        determine which Stream this MediaDescription applies to. If multiple
        MediaDescriptions apply to the same Stream, the
        <tp:member-ref>SSRCs</tp:member-ref> 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).
      </tp:docstring>
    </property>

    <tp:mapping name="Contact_SSRCs_Map">
      <tp:member name="Contact" type="u" tp:type="Handle">
        <tp:docstring>
          The remote contact these SSRCs belong to or 0.
        </tp:docstring>
      </tp:member>
      <tp:member name="SSRCs" type="au">
        <tp:docstring>
          The list of maps
        </tp:docstring>
      </tp:member>
    </tp:mapping>

    <property name="SSRCs" tp:name-for-bindings="SSRCs"
      type="a{uau}" tp:type="Contact_SSRCs_Map" access="read" tp:immutable="yes">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>A map from Handle to list of Synchronisation Sources, as defined by
        RFC 3550.</p>

        <p>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
        <tp:member-ref>Accept</tp:member-ref> 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 <tp:dbus-ref
        namespace="ofdT.Call.Content.Interface.Media.DRAFT2"
        >LocalMediaDescription</tp:dbus-ref>, then the streaming
        implementation should pick a new SSRC to resolve the collision.</p>

        <p>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.</p>

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

        <p>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)</p>
      </tp:docstring>
    </property>

    <tp:mapping name="Media_Description_Properties">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>
          A mapping containing all properties that define the information from a
          <tp:dbus-ref
            namespace="ofdT.Call.Content"
{'fraction_non_alphanumeric': 0.08470859147979604, 'fraction_numerical': 0.008388617797028345, 'mean_word_length': 2.8849840255591053, 'pattern_counts': {'":': 0, '<': 201, '<?xml version=': 2, '>': 199, 'https://': 0, 'lorem ipsum': 0, 'www.': 13, 'xml': 17}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '809133', 'n_tokens_mistral': 5084, 'n_tokens_neox': 4895, 'n_words': 1889}