Use a spec directory layout more similar to tp-glib

9 files changed, 3111 insertions, 0 deletions

diff --git a/spec/Call_Content.xml b/spec/Call_Content.xml
new file mode 100644
index 0000000..17ed710
--- /dev/null
+++ b/spec/Call_Content.xml
@@ -0,0 +1,291 @@
+<?xml version="1.0" ?>
+<node name="/Call_Content"
+  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.DRAFT"
+      tp:causes-havoc="experimental">
+    <tp:added version="0.19.0">(draft 1)</tp:added>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      This object represents one Content inside a <tp:dbus-ref
+      namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>. For
+      example, in an audio/video call there would be one audio content
+      and one video content. Each content has one or more <tp:dbus-ref
+      namespace="ofdT.Call">Stream.DRAFT</tp:dbus-ref> objects which
+      represent the actual transport to one or more remote contacts.
+    </tp:docstring>
+
+    <tp:enum name="Content_Removal_Reason" type="u">
+      <tp:added version="0.21.2"/>
+      <tp:docstring>
+        A representation of the reason for a content to be removed,
+        which may be used by simple clients, or used as a fallback
+        when the DBus_Reason is not understood. This enum will be
+        extended with future reasons as and when appropriate, so
+        clients SHOULD keep up to date with its values, but also be
+        happy to fallback to the Unknown value when an unknown value
+        is encountered.
+      </tp:docstring>
+
+      <tp:enumvalue suffix="Unknown" value="0">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          We just don't know. Unknown values of this enum SHOULD also be
+          treated like this.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="User_Requested" value="1">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The local user requests that this content is removed
+            from the call.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Error" value="2">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>There is an error with the content which means that it
+            has to be removed from the call.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Unsupported" value="3">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Some aspect of the content is unsupported so has to be
+            removed from the call.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <method name="Remove" tp:name-for-bindings="Remove">
+      <tp:changed version="0.21.2">previously there were no
+        arguments</tp:changed>
+      <tp:docstring>
+        Remove the content from the call.
+      </tp:docstring>
+
+      <arg direction="in" name="Reason" type="u"
+        tp:type="Content_Removal_Reason">
+        <tp:docstring>
+          A generic hangup reason.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Detailed_Removal_Reason" type="s"
+        tp:type="DBus_Error_Name">
+        <tp:docstring>
+          A more specific reason for the content removal, if one is
+          available, or an empty string.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Message" type="s">
+        <tp:docstring>
+          A human-readable message for the reason of removing the
+          content, such as "Fatal streaming failure" or "no codec
+          intersection". This property can be left empty if no reason
+          is to be given.
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError" />
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+          <tp:docstring>
+            Raised when a Call doesn't support removing contents
+            (e.g. a Google Talk video call).
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <signal name="Removed" tp:name-for-bindings="Removed">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when the content is removed from the call. This
+          is the same as the <tp:dbus-ref
+          namespace="ofdT.Channel.Type">Call.DRAFT.ContentRemoved</tp:dbus-ref>
+          signal.</p>
+      </tp:docstring>
+    </signal>
+
+    <property name="Interfaces" tp:name-for-bindings="Interfaces"
+      type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
+      <tp:added version="0.19.11"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Extra interfaces provided by this content, such as <tp:dbus-ref
+          namespace="ofdT.Call">Content.Interface.Media.DRAFT</tp:dbus-ref> or
+          <tp:dbus-ref namespace="ofdT.Call">Content.Interface.Mute.DRAFT</tp:dbus-ref>.
+          This SHOULD NOT include the Content interface itself, and cannot
+          change once the content has been created.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="Name" tp:name-for-bindings="Name" type="s" access="read"
+      tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The name of the content.</p>
+
+        <tp:rationale>
+          The content name property should be meaningful, so should be
+          given a name which is significant to the user. The name
+          could be the "audio" or "video" string localized, or perhaps
+          include some string identifying the source, such as a webcam
+          identifier.
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="Type" tp:name-for-bindings="Type"
+        type="u" tp:type="Media_Stream_Type" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The media type of this content.</p>
+      </tp:docstring>
+    </property>
+
+    <tp:enum name="Call_Content_Disposition" type="u">
+      <tp:docstring>
+        The disposition of this content, which defines whether to
+        automatically start sending data on the streams when
+        <tp:dbus-ref
+        namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> is
+        called on the channel.
+      </tp:docstring>
+
+      <tp:enumvalue suffix="None" value="0">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The content has no specific disposition
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Initial" value="1">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The content was initially part of the call. When
+          <tp:dbus-ref
+          namespace="ofdT.Channel.Type.Call.DRAFT">Accept</tp:dbus-ref>
+          is called on the channel, all streams of this content with
+          <tp:dbus-ref
+          namespace="ofdT.Call.Stream.DRAFT">LocalSendingState</tp:dbus-ref>
+          set to <tp:type>Sending_State</tp:type>_Pending_Send will be
+          moved to <tp:type>Sending_State</tp:type>_Sending as if
+          <tp:dbus-ref
+          namespace="ofdT.Call.Stream.DRAFT">SetSending</tp:dbus-ref>
+          (True) had been called.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <property name="Disposition" tp:name-for-bindings="Disposition"
+        type="u" tp:type="Call_Content_Disposition" access="read"
+        tp:immutable="yes">
+      <tp:docstring>
+        The disposition of this content.
+      </tp:docstring>
+    </property>
+
+    <signal name="StreamsAdded" tp:name-for-bindings="Streams_Added">
+      <tp:changed version="0.21.2">plural version, renamed from
+        StreamAdded</tp:changed>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+         <p>Emitted when streams are added to a call.</p>
+      </tp:docstring>
+      <arg name="Streams" type="ao">
+         <tp:docstring>
+           The <tp:dbus-ref
+           namespace="ofdT.Call">Stream.DRAFT</tp:dbus-ref>s which were
+           added.
+         </tp:docstring>
+       </arg>
+    </signal>
+
+    <signal name="StreamsRemoved" tp:name-for-bindings="Streams_Removed">
+      <tp:changed version="0.21.2">plural version, renamed from
+        StreamRemoved</tp:changed>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+         <p>Emitted when streams are removed from a call</p>
+      </tp:docstring>
+      <arg name="Streams" type="ao">
+         <tp:docstring>
+           The <tp:dbus-ref
+           namespace="ofdT.Call">Stream.DRAFT</tp:dbus-ref>s which were
+           removed.
+         </tp:docstring>
+       </arg>
+    </signal>
+
+    <property name="Streams" tp:name-for-bindings="Streams"
+      type="ao" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The list of <tp:dbus-ref namespace="ofdT.Call"
+          >Stream.DRAFT</tp:dbus-ref> objects that exist in this
+          content.</p>
+
+        <tp:rationale>
+          In a conference call multiple parties can share one media
+          content (say, audio), but the streaming of that media can
+          either be shared or separate. For example, in a multicast
+          conference all contacts would share one stream, while in a
+          Muji conference there would be a stream for each
+          participant.
+        </tp:rationale>
+
+        <p>Change notification is through the
+          <tp:member-ref>StreamsAdded</tp:member-ref> and
+          <tp:member-ref>StreamsRemoved</tp:member-ref> signals.</p>
+      </tp:docstring>
+    </property>
+
+    <tp:enum name="Call_Content_Packetization_Type" type="u">
+      <tp:added version="0.21.2"/>
+      <tp:docstring>
+        A packetization method that can be used for a content.
+      </tp:docstring>
+
+      <tp:enumvalue suffix="RTP" value="0">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          Real-time Transport Protocol, as documented by RFC 3550.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Raw" value="1">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          Raw media.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="MSN_Webcam" value="2">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          MSN webcam. This is the video-only one-way type which was
+          used in earlier versions of WLM. Although no longer used,
+          modern WLM clients still support the MSN webcam protocol.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <property name="Packetization" tp:name-for-bindings="Packetization"
+      type="u" tp:type="Call_Content_Packetization_Type" access="read"
+      tp:immutable="yes">
+      <tp:added version="0.21.2"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The packetization method in use for this content.</p>
+      </tp:docstring>
+    </property>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Content_Codec_Offer.xml b/spec/Call_Content_Codec_Offer.xml
new file mode 100644
index 0000000..f88143f
--- /dev/null
+++ b/spec/Call_Content_Codec_Offer.xml
@@ -0,0 +1,87 @@
+<?xml version="1.0" ?>
+<node name="/Call_Content_Codec_Offer"
+  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.CodecOffer.DRAFT"
+      tp:causes-havoc="experimental">
+    <tp:added version="0.19.0">(draft 1)</tp:added>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      This object represents an offer of a Codec payload mapping.
+    </tp:docstring>
+
+    <method name="Accept" tp:name-for-bindings="Accept">
+      <arg name="Codecs" direction="in"
+        type="a(usuua{ss})" tp:type="Codec[]">
+        <tp:docstring>
+          The local codec mapping 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>
+        Accept the updated Codec mapping and update the local mapping.
+      </tp:docstring>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The codecs given as the argument are 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 codecs
+        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 codec offer.  This SHOULD
+          NOT include the CodecOffer interface itself, and cannot change
+          once the content has been created.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="RemoteContactCodecs"
+      tp:name-for-bindings="Remote_Contact_Codecs"
+      type="a(usuua{ss})" tp:type="Codec[]" access="read"
+      tp:immutable="yes">
+      <tp:docstring>
+        A list of codecs the remote contact supports.
+      </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 codec offer applies to.
+      </tp:docstring>
+    </property>
+
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Content_Interface_Media.xml b/spec/Call_Content_Interface_Media.xml
new file mode 100644
index 0000000..274d8b2
--- /dev/null
+++ b/spec/Call_Content_Interface_Media.xml
@@ -0,0 +1,331 @@
+<?xml version="1.0" ?>
+<node name="/Call_Content_Interface_Media"
+  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.Interface.Media.DRAFT"
+      tp:causes-havoc="experimental">
+    <tp:added version="0.19.0">(draft 1)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Call.Content.DRAFT"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>Interface to use by a software implementation of media
+        streaming. The reason behind splitting the members of this
+        interface out from the main <tp:dbus-ref
+        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> 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.</p>
+
+      <h4>Codec negotiation</h4>
+
+      <p>When a new <tp:dbus-ref
+        namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channel
+        appears, whether it was requested or not, a <tp:dbus-ref
+        namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
+        will either be waiting in the
+        <tp:member-ref>CodecOffer</tp:member-ref> property, or will
+        appear at some point via the
+        <tp:member-ref>NewCodecOffer</tp:member-ref> signal.</p>
+
+      <p>The <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>
+        property on the codec 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. An empty list means all codecs can be proposed.</p>
+
+      <p>For incoming calls on protocols where codecs are proposed when
+        starting the call (for example, <a
+        href="http://xmpp.org/extensions/xep-0166.html">Jingle</a>),
+        the <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>
+        will contain information on the codecs that have already been
+        proposed by the remote contact, otherwise the codec map will
+        be the empty list.</p>
+
+      <p>The streaming implementation should look at the remote codec
+        map and the codecs known by the local user and call
+        <tp:dbus-ref
+        namespace="ofdT.Call.Content">CodecOffer.DRAFT.Accept</tp:dbus-ref>
+        on the intersection of these two codec lists.</p>
+
+      <p>This means that in practice, outgoing calls will have a codec
+        offer pop up with no information in the <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>,
+        so the local user will call <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">Accept</tp:dbus-ref>
+        with the list of all codecs supported. If this codec offer is
+        accepted, then <tp:member-ref>CodecsChanged</tp:member-ref>
+        will fire with the details of the codecs passed into
+        <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">Accept</tp:dbus-ref>. If
+        the call is incoming, then the <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>
+        will contain details of the remote contact's codecs and the
+        local user will call <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">Accept</tp:dbus-ref>
+        with the codecs that both sides understand. After the codec
+        set is accepted, <tp:member-ref>CodecsChanged</tp:member-ref>
+        will fire to signal this change.</p>
+
+      <h4>Protocols without codec negotiation</h4>
+
+      <p>For protocols where the codecs are not negotiable, instead of
+        popping up the initial content's <tp:dbus-ref
+        namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
+        object with an empty <tp:dbus-ref
+        namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>,
+        the CM should set the supported codec values to known codec
+        values in the said object's codec map.</p>
+
+      <h4>Changing codecs mid-call</h4>
+
+      <p>To update the codec list used mid-call, the
+        <tp:member-ref>UpdateCodecs</tp:member-ref> method should be
+        called with details of the new codec list. If this is
+        accepted, then <tp:member-ref>CodecsChanged</tp:member-ref>
+        will be emitted with the new codec set.</p>
+
+      <p>If the other side decides to update his or her codec list
+        during a call, a new <tp:dbus-ref
+        namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
+        object will appear through
+        <tp:member-ref>NewCodecOffer</tp:member-ref> which should be
+        acted on as documented above.</p>
+
+    </tp:docstring>
+
+    <tp:struct name="Codec" array-name="Codec_List">
+      <tp:docstring>
+        A description of a codec.
+      </tp:docstring>
+      <tp:member name="Identifier" type="u">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          Numeric identifier for the codec. This will be used as the PT in the
+          SDP or content description.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Name" type="s">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The name of the codec.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Clockrate" type="u">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The clockrate of the codec.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Channels" type="u">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          Number of channels of the codec if applicable, otherwise 0.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Parameters" type="a{ss}" tp:type="String_String_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          Extra parameters for this codec.
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <tp:mapping name="Contact_Codec_Map">
+      <tp:docstring>
+        A map from contact to the list of codecs he or she supports.
+      </tp:docstring>
+      <tp:member name="Handle" type="u" tp:type="Contact_Handle">
+        <tp:docstring>
+          A contact handle.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Codecs" type="a(usuua{ss})" tp:type="Codec[]">
+        <tp:docstring>
+          The codecs that the contact supports.
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <tp:struct name="Codec_Offering">
+      <tp:docstring>
+        A codec offer and its corresponding remote contact codec map.
+      </tp:docstring>
+      <tp:member name="Codec_Offer" type="o">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The object path to the <tp:dbus-ref namespace="ofdT.Call.Content"
+          >CodecOffer.DRAFT</tp:dbus-ref>
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Remote_Contact" type="u" tp:type="Contact_Handle">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The contact handle that this codec offer applies to.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Remote_Contact_Codecs" type="a(usuua{ss})"
+          tp:type="Codec[]">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The <tp:dbus-ref namespace="ofdT.Call.Content"
+          >CodecOffer.DRAFT.RemoteContactCodecs</tp:dbus-ref> property
+          of the codec offer.
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <signal name="CodecsChanged" tp:name-for-bindings="Codecs_Changed">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when the codecs in use change.</p>
+
+        <p>As well as acting as change notification for the
+          <tp:member-ref>ContactCodecMap</tp:member-ref>, emission of this
+          signal implies that the <tp:member-ref>CodecOffer</tp:member-ref>
+          property has changed to <code>('/', {})</code>.</p>
+      </tp:docstring>
+      <arg name="Updated_Codecs" type="a{ua(usuua{ss})}"
+        tp:type="Contact_Codec_Map">
+        <tp:docstring>
+          A map from contact to his or her codecs. Each pair in this
+          map is added to the
+          <tp:member-ref>ContactCodecMap</tp:member-ref> property,
+          replacing any previous pair with that key.
+        </tp:docstring>
+      </arg>
+      <arg name="Removed_Contacts" type="au" tp:type="Contact_Handle[]">
+        <tp:docstring>
+          A list of keys which were removed from the
+          <tp:member-ref>ContactCodecMap</tp:member-ref>, probably because
+          those contacts left the call.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <method name="UpdateCodecs" tp:name-for-bindings="Update_Codecs">
+      <tp:docstring>
+        Update the local codec mapping. This method should only be
+        used during an existing call to update the codec mapping.
+      </tp:docstring>
+      <arg name="Codecs" direction="in"
+        type="a(usuua{ss})" tp:type="Codec[]">
+        <tp:docstring>
+          The codecs now supported by the local user.
+        </tp:docstring>
+      </arg>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            Raised when a <tp:dbus-ref
+            namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
+            object exists and is referred to in the
+            <tp:member-ref>CodecOffer</tp:member-ref> property which
+            should be used instead of calling this method, or before
+            the content's initial <tp:dbus-ref
+            namespace="ofdT.Call.Content">CodecOffer.DRAFT</tp:dbus-ref>
+            object has appeared.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <property name="ContactCodecMap" tp:name-for-bindings="Contact_Codec_Map"
+      type="a{ua(usuua{ss})}" tp:type="Contact_Codec_Map" access="read">
+      <tp:docstring>
+        <p>A map from contact handles (including the local user's own handle)
+          to the codecs supported by that contact.</p>
+
+        <p>Change notification is via the
+          <tp:member-ref>CodecsChanged</tp:member-ref> signal.</p>
+      </tp:docstring>
+    </property>
+
+    <signal name="NewCodecOffer" tp:name-for-bindings="New_Codec_Offer">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when a new <tp:dbus-ref namespace="ofdT.Call.Content"
+          >CodecOffer.DRAFT</tp:dbus-ref> appears. The streaming
+          implementation MUST respond by calling the <tp:dbus-ref
+          namespace="ofdT.Call.Content.CodecOffer.DRAFT"
+          >Accept</tp:dbus-ref> or <tp:dbus-ref
+          namespace="ofdT.Call.Content.CodecOffer.DRAFT"
+          >Reject</tp:dbus-ref> method on the codec offer object.</p>
+
+        <p>Emission of this signal indicates that the
+          <tp:member-ref>CodecOffer</tp:member-ref> property has changed to
+          <code>(Contact, Offer, Codecs)</code>.</p>
+      </tp:docstring>
+      <arg name="Contact" type="u">
+        <tp:docstring>
+          The contact the codec offer belongs to.
+        </tp:docstring>
+      </arg>
+      <arg name="Offer" type="o">
+        <tp:docstring>
+          The object path of the new codec offer. This replaces any previous
+          codec offer.
+        </tp:docstring>
+      </arg>
+      <arg name="Codecs" type="a(usuua{ss})" tp:type="Codec[]">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The <tp:dbus-ref namespace="ofdT.Call.Content"
+            >CodecOffer.DRAFT.RemoteContactCodecs</tp:dbus-ref> property
+            of the codec offer.</p>
+
+        <tp:rationale>
+          Having the <tp:dbus-ref
+          namespace="ofdT.Call.Content.CodecOffer.DRAFT">RemoteContactCodecs</tp:dbus-ref>
+          property here saves a D-Bus round-trip - it shouldn't be
+          necessary to get the property from the CodecOffer object, in
+          practice.
+        </tp:rationale>
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <property name="CodecOffer" tp:name-for-bindings="Codec_Offer"
+      type="(oua(usuua{ss}))" tp:type="Codec_Offering" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The object path to the current
+          <tp:dbus-ref namespace="ofdT.Call.Content"
+            >CodecOffer.DRAFT</tp:dbus-ref> object, its
+            <tp:dbus-ref namespace="ofdT.Call.Content"
+            >CodecOffer.DRAFT.RemoteContact</tp:dbus-ref> and
+            <tp:dbus-ref namespace="ofdT.Call.Content"
+            >CodecOffer.DRAFT.RemoteContactCodecs</tp:dbus-ref> properties.
+            If the object path is "/" then there isn't an outstanding
+            codec offer, and the mapping MUST be empty.</p>
+
+        <tp:rationale>
+          Having the <tp:dbus-ref
+          namespace="ofdT.Call.Content.CodecOffer.DRAFT"
+          >RemoteContact</tp:dbus-ref> and
+          <tp:dbus-ref namespace="ofdT.Call.Content.CodecOffer.DRAFT"
+          >RemoteContactCodecs</tp:dbus-ref>
+          properties here saves a D-Bus round-trip - it shouldn't be
+          necessary to get these properties from the CodecOffer object, in
+          practice.
+        </tp:rationale>
+
+        <p>Change notification is via the
+          <tp:member-ref>NewCodecOffer</tp:member-ref> (which replaces the
+          value of this property with a new codec offer), and
+          <tp:member-ref>CodecsChanged</tp:member-ref> (which implies that
+          there is no longer any active codec offer) signals.</p>
+      </tp:docstring>
+    </property>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Content_Interface_Mute.xml b/spec/Call_Content_Interface_Mute.xml
new file mode 100644
index 0000000..f926e03
--- /dev/null
+++ b/spec/Call_Content_Interface_Mute.xml
@@ -0,0 +1,85 @@
+<?xml version="1.0" ?>
+<node name="/Call_Content_Interface_Mute" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright> Copyright © 2005-2010 Nokia Corporation </tp:copyright>
+  <tp:copyright> Copyright © 2005-2010 Collabora Ltd </tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+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.
+
+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.
+
+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.
+  </tp:license>
+
+  <interface name="org.freedesktop.Telepathy.Call.Content.Interface.Mute.DRAFT" tp:causes-havoc="experimental">
+    <tp:added version="0.19.6">(draft version, not API-stable)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Call.Content.DRAFT"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>Interface for calls which may be muted.  This only makes sense
+        for channels where audio or video is streaming between members.</p>
+
+      <p>Muting a call content indicates that the user does not wish to send
+        outgoing audio or video.</p>
+
+      <p>Although it's client's responsibility to actually mute the microphone
+        or turn off the camera, using this interface the client can also
+        inform the CM and other clients of that fact.</p>
+
+      <tp:rationale>
+        For some protocols, the fact that the content is muted needs
+        to be transmitted to the peer; for others, the notification
+        to the peer is only informational (eg. XMPP), and some
+        protocols may have no notion of muting at all.
+      </tp:rationale>
+    </tp:docstring>
+
+    <signal name="MuteStateChanged" tp:name-for-bindings="Mute_State_Changed">
+      <tp:docstring>
+        Emitted to indicate that the mute state has changed for this call content.
+        This may occur as a consequence of the client calling
+        <tp:member-ref>SetMuted</tp:member-ref>, or as an indication that another
+        client has (un)muted the content.
+      </tp:docstring>
+      <arg name="MuteState" type="b">
+        <tp:docstring>
+          True if the content is now muted.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <property name="MuteState" type="b"
+      access="read" tp:name-for-bindings="Mute_State">
+      <tp:docstring>
+        True if the content is muted.
+      </tp:docstring>
+    </property>
+
+    <method name="SetMuted" tp:name-for-bindings="Set_Muted">
+      <tp:changed version="0.21.2">renamed from SetMuted to Mute</tp:changed>
+      <tp:changed version="0.21.3">renamed back from Mute to SetMuted</tp:changed>
+      <arg direction="in" name="Muted" type="b">
+        <tp:docstring>
+          True if the client has muted the content.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        <p>Inform the CM that the call content has been muted or unmuted by
+          the client.</p>
+
+        <p>It is the client's responsibility to actually mute or unmute the
+          microphone or camera used for the content. However, the client
+          MUST call this whenever it mutes or unmutes the content.</p>
+      </tp:docstring>
+    </method>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Stream.xml b/spec/Call_Stream.xml
new file mode 100644
index 0000000..1d7b281
--- /dev/null
+++ b/spec/Call_Stream.xml
@@ -0,0 +1,261 @@
+<?xml version="1.0" ?>
+<node name="/Call_Stream"
+  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.Stream.DRAFT"
+      tp:causes-havoc="experimental">
+    <tp:added version="0.19.0">(draft 1)</tp:added>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      One stream inside a <tp:dbus-ref
+      namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>.
+    </tp:docstring>
+
+    <method name="SetSending" tp:name-for-bindings="Set_Sending">
+      <tp:docstring>
+        Set the stream to start or stop sending media from the local
+        user to other contacts.
+      </tp:docstring>
+
+      <arg name="Send" type="b" direction="in">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>If True, the
+            <tp:member-ref>LocalSendingState</tp:member-ref> should
+            change to <tp:type>Sending_State</tp:type>_Sending, if it isn't
+            already.</p>
+
+          <p>If False, the
+            <tp:member-ref>LocalSendingState</tp:member-ref> should
+            change to <tp:type>Sending_State</tp:type>_None, if it isn't
+            already.</p>
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented" />
+      </tp:possible-errors>
+    </method>
+
+    <method name="RequestReceiving" tp:name-for-bindings="Request_Receiving">
+      <tp:docstring>
+        <p>Request that a remote contact stops or starts sending on
+          this stream.</p>
+
+        <p>The <tp:member-ref>CanRequestReceiving</tp:member-ref>
+          property defines whether the protocol allows the local user to
+          request the other side start sending on this stream.</p>
+      </tp:docstring>
+
+      <arg name="Contact" type="u" tp:type="Contact_Handle" direction="in">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Contact from which sending is requested</p>
+        </tp:docstring>
+      </arg>
+
+      <arg name="Receive" type="b" direction="in">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>If true, request that the given contact starts to send media.
+            If false, request that the given contact stops sending media.</p>
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidHandle"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The request contact is valid but is not involved in this
+            stream.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+          <tp:docstring>
+            The protocol does not allow the local user to request the
+            other side starts sending on this stream.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <signal name="RemoteMembersChanged"
+        tp:name-for-bindings="Remote_Members_Changed">
+      <tp:changed version="0.21.2">renamed from SendersChanged to MembersChanged</tp:changed>
+      <tp:changed version="0.21.3">renamed from MembersChanged to RemoteMembersChanged</tp:changed>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        Emitted when <tp:member-ref>RemoteMembers</tp:member-ref> changes.
+      </tp:docstring>
+
+      <arg name="Updates" type="a{uu}" tp:type="Contact_Sending_State_Map">
+        <tp:docstring>
+          A mapping from channel-specific handles to their updated sending
+          state, whose keys include at least the members who were added,
+          and the members whose states changed.
+        </tp:docstring>
+      </arg>
+      <arg name="Removed" type="au" tp:type="Contact_Handle[]">
+        <tp:docstring>
+          The channel-specific handles that were removed from the keys
+          of the <tp:member-ref>RemoteMembers</tp:member-ref>
+          property, as a result of the contact leaving this stream
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <signal name="LocalSendingStateChanged"
+        tp:name-for-bindings="Local_Sending_State_Changed">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        Emitted when <tp:member-ref>LocalSendingState</tp:member-ref> changes.
+      </tp:docstring>
+
+      <arg name="State" type="u" tp:type="Sending_State">
+        <tp:docstring>
+          The new value of
+          <tp:member-ref>LocalSendingState</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:enum name="Sending_State" type="u">
+      <tp:docstring>
+        Enum indicating whether a contact is sending media.
+      </tp:docstring>
+
+      <tp:enumvalue suffix="None" value="0">
+        <tp:docstring>
+          The contact is not sending media and has not been asked to
+          do so.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Pending_Send" value="1">
+        <tp:docstring>
+          The contact has been asked to start sending media.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Sending" value="2">
+        <tp:docstring>
+          The contact is sending media.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Pending_Stop_Sending" value="3">
+        <tp:docstring>
+          The contact has been asked to stop sending media.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <tp:mapping name="Contact_Sending_State_Map">
+      <tp:docstring>
+        A map from a contact to his or her sending state.
+      </tp:docstring>
+      <tp:member name="Contact" type="u" tp:type="Contact_Handle">
+        <tp:docstring>
+          The contact handle.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Sending" type="u" tp:type="Sending_State">
+         <tp:docstring>
+           The sending state of the contact.
+         </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <property name="Interfaces" tp:name-for-bindings="Interfaces"
+      type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
+      <tp:added version="0.19.11"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Extra interfaces provided by this stream, such as <tp:dbus-ref
+            namespace="ofdT.Call">Stream.Interface.Media.DRAFT</tp:dbus-ref>.
+          This SHOULD NOT include the Stream interface itself, and cannot
+          change once the stream has been created.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="RemoteMembers" tp:name-for-bindings="Remote_Members"
+        type="a{uu}" access="read" tp:type="Contact_Sending_State_Map">
+      <tp:changed version="0.21.2">renamed from Senders</tp:changed>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A map from remote contacts to their sending state. The
+          local user's sending state is shown in
+          <tp:member-ref>LocalSendingState</tp:member-ref>.</p>
+
+        <p><tp:type>Sending_State</tp:type>_Pending_Send indicates
+          that another contact has asked the local user to send
+          media.</p>
+
+        <p>Other contacts' handles in this map indicate whether they are
+          sending media to the contacts in this stream.
+          Sending_State_Pending_Send indicates contacts who are not sending but
+          have been asked to do so.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="LocalSendingState" tp:name-for-bindings="Local_Sending_State"
+        type="u" access="read" tp:type="Sending_State">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The local user's sending state. Media sent on this stream
+          should be assumed to be received, directly or indirectly, by
+          every other contact in the
+          <tp:member-ref>RemoteMembers</tp:member-ref> mapping. Change
+          notification is given via the
+          <tp:member-ref>LocalSendingStateChanged</tp:member-ref>
+          signal.</p>
+
+        <tp:rationale>
+          Implementations of the first Call draft had the self handle
+          in the <tp:member-ref>RemoteMembers</tp:member-ref> (then
+          called Members) map and this showed that it's annoying
+          having to keep track of the self handle so that it can be
+          special-cased.
+        </tp:rationale>
+
+        <p>A value of <tp:type>Sending_State</tp:type>_Pending_Send for
+          this property indicates that the other side requested the
+          local user start sending media, which can be done by calling
+          <tp:member-ref>SetSending</tp:member-ref>. When a call is
+          accepted, all initial contents with streams that have a
+          local sending state of
+          <tp:type>Sending_State</tp:type>_Pending_Send are
+          automatically set to sending. For example, on an incoming
+          call it means you need to <tp:dbus-ref
+          namespace="ofdT.Channel.Type.Call.DRAFT">Accept</tp:dbus-ref>
+          to start the actual call, on an outgoing call it might mean
+          you need to call <tp:dbus-ref
+          namespace="ofdT.Channel.Type.Call.DRAFT">Accept</tp:dbus-ref>
+          before actually starting the call.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="CanRequestReceiving" tp:name-for-bindings="Can_Request_Receiving"
+        type="b" access="read" tp:immutable="yes">
+      <tp:added version="0.21.2"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If true, the user can request that a remote contact starts
+          sending on this stream.</p>
+
+        <tp:rationale>Not all protocols allow the user to ask the
+          other side to start sending media.</tp:rationale>
+      </tp:docstring>
+    </property>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Stream_Endpoint.xml b/spec/Call_Stream_Endpoint.xml
new file mode 100644
index 0000000..4818168
--- /dev/null
+++ b/spec/Call_Stream_Endpoint.xml
@@ -0,0 +1,182 @@
+<?xml version="1.0" ?>
+<node name="/Call_Stream_Endpoint"
+  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.Stream.Endpoint.DRAFT"
+    tp:causes-havoc="experimental">
+    <tp:added version="0.19.0">(draft 1)</tp:added>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This object represents an endpoint for a stream. In a one-to-one
+        call, there will be one (bidirectional) stream per content and
+        one endpoint per stream (as there is only one remote
+        contact). In a multi-user call there is a stream for each remote
+        contact and each stream has one endpoint as it refers to the one
+        physical machine on the other end of the stream.</p>
+
+      <p>The multiple endpoint use case appears when SIP call forking
+        is used. Unlike jingle call forking (which is just making
+        multiple jingle calls to different resources appear as one
+        call), SIP call forking is actually done at the server so you
+        have one stream to the remote contact and then and endpoint for
+        each SIP client to be called.</p>
+    </tp:docstring>
+
+    <property name="RemoteCredentials"
+      tp:name-for-bindings="Remote_Credentials"
+      type="(ss)" tp:type="Stream_Credentials" access="read">
+      <tp:docstring>
+        The ICE credentials used for all candidates. If each candidate
+        has different credentials, then this property SHOULD be ("",
+        ""). Per-candidate credentials are set in the
+        <tp:type>Candidate</tp:type>'s
+        <tp:type>Candidate_Info</tp:type> a{sv}.
+      </tp:docstring>
+    </property>
+
+    <signal name="RemoteCredentialsSet"
+      tp:name-for-bindings="Remote_Credentials_Set">
+      <arg name="Username" type="s">
+        <tp:docstring>
+          The username set.
+        </tp:docstring>
+      </arg>
+      <arg name="Password" type="s">
+        <tp:docstring>
+          The password set.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        Emitted when the remote ICE credentials for the endpoint are
+        set. If each candidate has different credentials, then this
+        signal will never be fired.
+      </tp:docstring>
+    </signal>
+
+    <property name="RemoteCandidates" tp:name-for-bindings="Remote_Candidates"
+      type="a(usqa{sv})" tp:type="Candidate[]" access="read">
+      <tp:docstring>
+        A list of candidates for this endpoint.
+      </tp:docstring>
+    </property>
+
+    <signal name="RemoteCandidatesAdded"
+      tp:name-for-bindings="Remote_Candidates_Added">
+      <tp:docstring>
+        Emitted when remote candidates are added to the
+        <tp:member-ref>RemoteCandidates</tp:member-ref> property.
+      </tp:docstring>
+      <arg name="Candidates"
+        type="a(usqa{sv})" tp:type="Candidate[]">
+        <tp:docstring>
+          The candidates that were added.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <signal name="CandidateSelected"
+      tp:name-for-bindings="Candidate_Selected">
+      <tp:docstring>
+        Emitted when a candidate is selected for use in the stream.
+      </tp:docstring>
+      <arg name="Candidate"
+        type="(usqa{sv})" tp:type="Candidate">
+        <tp:docstring>
+          The candidate that has been selected.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <property name="SelectedCandidate"
+      tp:name-for-bindings="Selected_Candidate"
+      type="(usqa{sv})" tp:type="Candidate" access="read">
+      <tp:docstring>
+        The candidate that has been selected for use to stream packets
+        to the remote contact. Change notification is given via the
+        the <tp:member-ref>CandidateSelected</tp:member-ref> signal.
+      </tp:docstring>
+    </property>
+
+    <method name="SetSelectedCandidate"
+      tp:name-for-bindings="Set_Selected_Candidate">
+      <tp:docstring>
+        Set the value of
+        <tp:member-ref>CandidateSelected</tp:member-ref>.
+      </tp:docstring>
+      <arg name="Candidate"
+        type="(usqa{sv})" tp:type="Candidate" direction="in">
+        <tp:docstring>
+          The candidate that has been selected.
+        </tp:docstring>
+      </arg>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+      </tp:possible-errors>
+    </method>
+
+    <property name="StreamState" tp:name-for-bindings="Stream_State"
+      type="u" tp:type="Media_Stream_State"
+      access="read">
+      <tp:docstring>
+        The stream state of the endpoint.
+      </tp:docstring>
+    </property>
+
+    <signal name="StreamStateChanged"
+      tp:name-for-bindings="Stream_State_Changed">
+      <tp:docstring>
+        Emitted when the <tp:member-ref>StreamState</tp:member-ref>
+        property changes.
+      </tp:docstring>
+      <arg name="state" type="u" tp:type="Media_Stream_State">
+        <tp:docstring>
+          The new <tp:member-ref>StreamState</tp:member-ref> value.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <method name="SetStreamState"
+      tp:name-for-bindings="Set_Stream_State">
+      <tp:docstring>
+        Change the <tp:member-ref>StreamState</tp:member-ref> of the
+        endpoint.
+      </tp:docstring>
+      <arg direction="in" name="State" type="u" tp:type="Media_Stream_State">
+        <tp:docstring>
+          The requested stream state.
+        </tp:docstring>
+      </arg>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable"/>
+      </tp:possible-errors>
+    </method>
+
+    <property name="Transport" tp:name-for-bindings="Transport"
+      type="u" tp:type="Stream_Transport_Type" access="read">
+      <tp:docstring>
+        The transport type for the stream endpoint.
+      </tp:docstring>
+    </property>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Stream_Interface_Media.xml b/spec/Call_Stream_Interface_Media.xml
new file mode 100644
index 0000000..5f2bbec
--- /dev/null
+++ b/spec/Call_Stream_Interface_Media.xml
@@ -0,0 +1,440 @@
+<?xml version="1.0" ?>
+<node name="/Call_Stream_Interface_Media"
+  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.Stream.Interface.Media.DRAFT"
+      tp:causes-havoc="experimental">
+    <tp:added version="0.19.0">(draft 1)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Call.Stream.DRAFT"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      [FIXME]
+
+      <h4>ICE restarts</h4>
+
+      <p>If the <tp:dbus-ref
+        namespace="ofdT.Call.Stream.Endpoint.DRAFT">RemoteCredentialsSet</tp:dbus-ref>
+        signal is fired during a call once it has been called before
+        whilst setting up the call for initial use, and the
+        credentials have changed, then there has been an ICE
+        restart. In such a case, the CM SHOULD also empty the remote
+        candidate list in the <tp:dbus-ref
+        namespace="ofdT.Call.Stream">Endpoint.DRAFT</tp:dbus-ref>.</p>
+
+      <p>If the CM does an ICE restart, then the
+        <tp:member-ref>PleaseRestartICE</tp:member-ref> signal is
+        emitted and the streaming implementation should then call
+        <tp:member-ref>SetCredentials</tp:member-ref> again.</p>
+
+      <p>For more information on ICE restarts see
+        <a href="http://tools.ietf.org/html/rfc5245#section-9.1.1.1">RFC 5245
+        section 9.1.1.1</a></p>
+    </tp:docstring>
+
+    <method name="SetCredentials" tp:name-for-bindings="Set_Credentials">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Used to set the username fragment and password for streams that have
+          global credentials.</p>
+      </tp:docstring>
+      <arg name="Username" type="s" direction="in">
+        <tp:docstring>
+          The username to use when authenticating on the stream.
+        </tp:docstring>
+      </arg>
+      <arg name="Password" type="s" direction="in">
+        <tp:docstring>
+          The password to use when authenticating on the stream.
+        </tp:docstring>
+      </arg>
+    </method>
+
+    <tp:mapping name="Candidate_Info">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Extra information about the candidate. Allowed and mandatory keys
+          depend on the transport protocol used. The following keys are commenly
+          used:</p>
+
+        <dl>
+          <dt>Type (u)</dt>
+          <dd>type of candidate (host, srflx, prflx, relay)</dd>
+
+          <dt>Foundation (s)</dt>
+          <dd>the foundation of this candiate</dd>
+
+          <dt>Protocol (u) </dt>
+          <dd>Underlying protocol of the candidate (udp, tcp) </dd>
+
+          <dt>Priority (u) </dt>
+          <dd>Priority of the candidate </dd>
+
+          <dt>BaseIP (u) </dt>
+          <dd>Base IP of this candidate </dd>
+
+          <dt>Username (s) </dt>
+          <dd>Username of this candidate
+            (only if credentials are per candidate)</dd>
+
+          <dt>Password (s) </dt>
+          <dd>Password of this candidate
+            (only if credentials are per candidate)</dd>
+
+          <dt>RawUDPFallback (b) </dt>
+          <dd>Indicate whether this candidate may be used to provide a UDP
+               fallback</dd>
+        </dl>
+      </tp:docstring>
+      <tp:member name="Key" type="s">
+        <tp:docstring>One of the well-known keys documented here, or an
+          implementation-specific key.</tp:docstring>
+      </tp:member>
+      <tp:member name="Value" type="v">
+        <tp:docstring>The value corresponding to that key.</tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <tp:struct name="Candidate" array-name="Candidate_List">
+      <tp:docstring>A Stream Candidate.</tp:docstring>
+      <tp:member name="Component" type="u">
+        <tp:docstring>The component number.</tp:docstring>
+      </tp:member>
+      <tp:member name="IP" type="s">
+        <tp:docstring>The IP address to use.</tp:docstring>
+      </tp:member>
+      <tp:member name="Port" type="q">
+        <tp:docstring>The port number to use.</tp:docstring>
+      </tp:member>
+      <tp:member name="Info" type="a{sv}" tp:type="Candidate_Info">
+        <tp:docstring>Additional information about the candidate.</tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <method name="AddCandidates" tp:name-for-bindings="Add_Candidates">
+      <tp:docstring>
+        Add candidates to the
+        <tp:member-ref>LocalCandidates</tp:member-ref> property and
+        signal them to the remote contact(s).
+      </tp:docstring>
+      <arg name="Candidates" direction="in"
+        type="a(usqa{sv})" tp:type="Candidate[]">
+        <tp:docstring>
+          The candidates to be added.
+        </tp:docstring>
+      </arg>
+    </method>
+
+    <method name="CandidatesPrepared"
+      tp:name-for-bindings="Candidates_Prepared">
+      <tp:docstring>
+        This indicates to the CM that the initial batch of candidates
+        has been added.
+      </tp:docstring>
+    </method>
+
+    <tp:enum type="u" name="Stream_Transport_Type">
+      <tp:changed version="0.21.2">WLM_8_5 was removed</tp:changed>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        A transport that can be used for streaming.
+      </tp:docstring>
+      <tp:enumvalue suffix="Unknown" value="0">
+        <tp:docstring>
+          The stream transport type is unknown or not applicable.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Raw_UDP" value="1">
+        <tp:docstring>
+          Raw UDP, with or without STUN. All streaming clients are assumed to
+          support this transport, so there is no handler capability token for
+          it in the <tp:dbus-ref namespace="ofdT.Channel.Type"
+          >Call.DRAFT</tp:dbus-ref> interface.
+          [This corresponds to "none" or "stun" in the old Media.StreamHandler
+          interface.]
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="ICE" value="2">
+        <tp:docstring>
+          Interactive Connectivity Establishment, as defined by RFC
+          5245. Note that this value covers ICE-UDP only.
+          [This corresponds to "ice-udp" in the old
+          Media.StreamHandler interface.]
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="GTalk_P2P" value="3">
+        <tp:docstring>
+          Google Talk peer-to-peer connectivity establishment, as implemented
+          by libjingle 0.3.
+          [This corresponds to "gtalk-p2p" in the old Media.StreamHandler
+          interface.]
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="WLM_2009" value="4">
+        <tp:docstring>
+          The transport used by Windows Live Messenger 2009 or later, which
+          resembles ICE draft 19.
+          [This corresponds to "wlm-2009" in the old Media.StreamHandler
+          interface.]
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="SHM" value="5">
+        <tp:added version="0.21.2"/>
+        <tp:docstring>
+          Shared memory transport, as implemented by the GStreamer
+          shmsrc and shmsink plugins.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <property name="Transport" tp:name-for-bindings="Transport"
+        type="u" tp:type="Stream_Transport_Type" access="read" tp:immutable="yes">
+      <tp:docstring>
+        The transport for this stream.
+      </tp:docstring>
+    </property>
+
+    <property name="LocalCandidates" tp:name-for-bindings="Local_Candidates"
+      type="a(usqa{sv})" tp:type="Candidate[]" access="read">
+      <tp:docstring>
+        [FIXME]. Change notification is via the
+        <tp:member-ref>LocalCandidatesAdded</tp:member-ref> signal.
+      </tp:docstring>
+    </property>
+
+    <signal name="LocalCandidatesAdded"
+      tp:name-for-bindings="Local_Candidates_Added">
+      <tp:docstring>
+        Emitted when local candidates are added to the
+        <tp:member-ref>LocalCandidates</tp:member-ref> property.
+      </tp:docstring>
+      <arg name="Candidates" type="a(usqa{sv})" tp:type="Candidate[]">
+        <tp:docstring>
+          Candidates that have been added.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <tp:struct name="Stream_Credentials">
+      <tp:docstring>A username and password pair.</tp:docstring>
+
+      <tp:member name="Username" type="s">
+        <tp:docstring>The username.</tp:docstring>
+      </tp:member>
+
+      <tp:member name="Password" type="s">
+        <tp:docstring>The password.</tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <property name="LocalCredentials" tp:name-for-bindings="Local_Credentials"
+      type="(ss)" tp:type="Stream_Credentials" access="read">
+      <tp:docstring>
+        [FIXME]. Change notification is via the
+        <tp:member-ref>LocalCredentialsChanged</tp:member-ref> signal.
+      </tp:docstring>
+    </property>
+
+    <signal name="LocalCredentialsChanged"
+      tp:name-for-bindings="Local_Credentials_Changed">
+      <tp:changed version="0.21.2">renamed from LocalCredentailsSet</tp:changed>
+      <tp:docstring>
+        Emitted when the value of
+        <tp:member-ref>LocalCredentials</tp:member-ref> changes.
+      </tp:docstring>
+      <arg name="Username" type="s" />
+      <arg name="Password" type="s" />
+    </signal>
+
+    <signal name="RelayInfoChanged"
+      tp:name-for-bindings="Relay_Info_Changed">
+      <tp:docstring>
+        Emitted when the value of
+        <tp:member-ref>RelayInfo</tp:member-ref> changes.
+      </tp:docstring>
+      <arg name="Relay_Info" type="aa{sv}" tp:type="String_Variant_Map[]" />
+    </signal>
+
+    <signal name="STUNServersChanged"
+      tp:name-for-bindings="STUN_Servers_Changed">
+      <tp:docstring>
+        Emitted when the value of
+        <tp:member-ref>STUNServers</tp:member-ref> changes.
+      </tp:docstring>
+      <arg name="Servers" type="a(sq)" tp:type="Socket_Address_IP[]" />
+    </signal>
+
+    <property name="STUNServers" tp:name-for-bindings="STUN_Servers"
+      type="a(sq)" tp:type="Socket_Address_IP[]" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The IP addresses of possible STUN servers to use for NAT
+          traversal, as dotted-quad IPv4 address literals or RFC2373
+          IPv6 address literals.  Change notification is via the
+          <tp:member-ref>STUNServersChanged</tp:member-ref>
+          signal. The IP addresses MUST NOT be given as DNS hostnames.</p>
+
+        <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="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>Transport</tp:member-ref> property: if
+              Transport is ICE, <code>tls</code> means
+              TLS over TCP as referenced by ICE draft 19, and if
+              Transport is GTalk_P2P, <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>Transport</tp:member-ref>
+          property. If Transport is ICE, this is a TURN server;
+          if Transport 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>Change notification is given via the
+          <tp:member-ref>RelayInfoChanged</tp:member-ref> signal.</p>
+      </tp:docstring>
+    </property>
+
+    <signal name="ServerInfoRetrieved"
+      tp:name-for-bindings="Server_Info_Retrieved">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Signals that the initial information about STUN and Relay servers
+          has been retrieved, i.e. the
+          <tp:member-ref>HasServerInfo</tp:member-ref> property is
+          now true.</p>
+      </tp:docstring>
+    </signal>
+
+    <property name="HasServerInfo" type="b"
+        tp:name-for-bindings="Has_Server_Info" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>True if all the initial information about STUN servers and Relay
+          servers has been retrieved. Change notification is via the
+          <tp:member-ref>ServerInfoRetrieved</tp:member-ref> signal.</p>
+
+        <tp:rationale>
+          Streaming implementations that can't cope with STUN and
+          relay servers being added later SHOULD wait for this
+          property to become true before proceeding.
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <signal name="EndpointsChanged"
+      tp:name-for-bindings="Endpoints_Changed">
+      <tp:docstring>
+        Emitted when the <tp:member-ref>Endpoints</tp:member-ref> property
+        changes.
+      </tp:docstring>
+      <arg name="Endpoints_Added" type="ao">
+        <tp:docstring>
+          Endpoints that were added.
+        </tp:docstring>
+      </arg>
+      <arg name="Endpoints_Removed" type="ao">
+        <tp:docstring>
+          Endpoints that no longer exist.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <property name="Endpoints" tp:name-for-bindings="Endpoints"
+      type="ao" access="read">
+      <tp:docstring>
+        <p>The list of <tp:dbus-ref namespace="ofdT.Call.Stream"
+          >Endpoint.DRAFT</tp:dbus-ref> objects that exist for this
+          stream.</p>
+
+        <p>Change notification is via the
+          <tp:member-ref>EndpointsChanged</tp:member-ref> signal.</p>
+      </tp:docstring>
+    </property>
+
+    <signal name="PleaseRestartICE"
+      tp:name-for-bindings="Please_Restart_ICE">
+      <tp:docstring>
+        Emitted when the CM does an ICE restart to notify the
+        streaming implementation that it should call
+        <tp:member-ref>SetCredentials</tp:member-ref> again.
+      </tp:docstring>
+    </signal>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Type_Call.xml b/spec/Channel_Type_Call.xml
new file mode 100644
index 0000000..eb1a663
--- /dev/null
+++ b/spec/Channel_Type_Call.xml
@@ -0,0 +1,1425 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Type_Call" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2009-2010 Collabora Limited</tp:copyright>
+  <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
+  <tp:license>
+    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.
+
+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.
+
+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.
+  </tp:license>
+  <interface name="org.freedesktop.Telepathy.Channel.Type.Call.DRAFT"
+      tp:causes-havoc="experimental">
+    <tp:added version="0.19.0">(draft 1)</tp:added>
+
+    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>A channel type for making audio and video calls. Call
+        channels supersede the old <tp:dbus-ref
+        namespace="ofdT.Channel.Type">StreamedMedia</tp:dbus-ref>
+        channel type. Call channels are much more flexible than its
+        predecessor and allow more than two participants.</p>
+
+      <p>Handlers are advised against executing all the media
+        signalling, codec and candidate negotiation themselves but
+        instead use a helper library such as <a
+        href="http://telepathy.freedesktop.org/doc/telepathy-farsight/">telepathy-farsight</a>
+        which when given a new Call channel will set up the
+        transports and codecs and create GStreamer pads which
+        can be added to the handler UI. This is useful as it means
+        the handler does not have to worry how exactly the
+        connection between the call participants is being made.</p>
+
+      <p>The <tp:dbus-ref
+        namespace="ofdT.Channel">TargetHandle</tp:dbus-ref> and
+        <tp:dbus-ref namespace="ofdT.Channel">TargetID</tp:dbus-ref>
+        properties in a Call channel refer to the contact that the
+        user initially called, or which contact initially called the
+        user. Even in a conference call, where there are multiple
+        contacts in the call, these properties refer to the
+        initial contact, who might have left the conference since
+        then. As a result, handlers should not rely on these
+        properties.</p>
+
+      <h4>Contents</h4>
+
+      <p><tp:dbus-ref
+        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> objects
+        represent the actual media that forms the Call (for example an
+        audio content and a video content). Calls always have one or
+        more Content objects associated with them.</p>
+
+      <p><tp:dbus-ref
+        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> objects have
+        one or more stream associated with them. More information on
+        these streams and how to maniuplate them can be found on the
+        <tp:dbus-ref namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>
+        interface page.</p>
+
+      <h4>Outgoing calls</h4>
+
+      <p>To make an audio-only call to a contact <tt>foo@example.com</tt>
+        handlers should call:</p>
+
+      <blockquote>
+        <pre>
+<tp:dbus-ref namespace="ofdT.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>({
+  ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref
+      namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
+  ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+  ...<tp:dbus-ref namespace="ofdT.Channel">TargetID</tp:dbus-ref>: 'foo@example.com',
+  ...<tp:member-ref>InitialAudio</tp:member-ref>: True,
+})</pre></blockquote>
+
+      <p>As always, <tp:dbus-ref
+        namespace="ofdT.Channel">TargetHandle</tp:dbus-ref> may be used
+        in place of
+        <tp:dbus-ref namespace="ofdT.Channel">TargetID</tp:dbus-ref>
+        if the contact's handle is already known. To make an audio
+        and video call, the handler should also specify
+        <tp:member-ref>InitialVideo</tp:member-ref> The
+        connection manager SHOULD return a channel whose immutable
+        properties contain the local user as the <tp:dbus-ref
+        namespace="ofdT.Channel">InitiatorHandle</tp:dbus-ref>, the
+        remote contact as the <tp:dbus-ref
+        namespace="ofdT.Channel">TargetHandle</tp:dbus-ref>,
+        <tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref> =
+        <code>True</code> (indicating the call is outgoing).</p>
+
+      <p>After a new Call channel is requested, the
+        <tp:member-ref>CallState</tp:member-ref> property will be
+        <tp:type>Call_State</tp:type>_Pending_Initiator. As the local
+        user is the initiator, the call must be accepted by the handler
+        by calling the <tp:member-ref>Accept</tp:member-ref> method.
+        At this point, <tp:member-ref>CallState</tp:member-ref> changes
+        to <tp:type>Call_State</tp:type>_Pending_Receiver which signifies
+        that the call is ringing, waiting for the remote contact to
+        accept the call. All changes to
+        <tp:member-ref>CallState</tp:member-ref> property are signalled
+        using the <tp:member-ref>CallStateChanged</tp:member-ref>
+        signal.</p>
+
+      <p>When the call is accepted by the remote contact, the
+        <tp:member-ref>CallStateChanged</tp:member-ref> signal fires
+        again to show that <tp:member-ref>CallState</tp:member-ref> =
+        <tp:type>Call_State</tp:type>_Accepted.</p>
+
+      <p>At this point <a
+        href="http://telepathy.freedesktop.org/doc/telepathy-farsight/">telepathy-farsight</a>
+        will signal that a pad is available for the handler to show
+        in the user interface.</p>
+
+      <h5>Missed calls</h5>
+
+      <p>If the remote contact does not accept the call in time, then
+        the call can be terminated by the server. Note that this only
+        happens in some protocols. Most XMPP clients, for example, do
+        not do this and rely on the call initiator terminating the call.
+        A missed call is shown in a Call channel by the
+        <tp:member-ref>CallState</tp:member-ref> property changing to
+        <tp:type>Call_State</tp:type>_Ended, and the
+        <tp:member-ref>CallStateReason</tp:member-ref> property changing
+        to (remote contact,
+        <tp:type>Call_State_Change_Reason</tp:type>_No_Answer, "").</p>
+
+      <h5>Rejected calls</h5>
+
+      <p>If the remote contact decides he or she does not feel like
+        talking to the local user, he or she can reject his or her
+        incoming call. This will be shown in the Call channel by
+        <tp:member-ref>CallState</tp:member-ref> changing to
+        <tp:type>Call_State</tp:type>_Ended and the
+        <tp:member-ref>CallStateReason</tp:member-ref> property
+        changing to (remote contact,
+        <tp:type>Call_State</tp:type>_Change_Reason_User_Requested,
+        "org.freedesktop.Telepathy.Error.Rejected").</p>
+
+      <h4>Incoming calls</h4>
+
+      <p>When an incoming call occurs, something like the following
+        <tp:dbus-ref
+        namespace="ofdT.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
+        signal will occur:</p>
+
+      <blockquote>
+        <pre>
+<tp:dbus-ref namespace="ofdT.Connection.Interface.Requests">NewChannels</tp:dbus-ref>([
+  /org/freedesktop/Telepathy/Connection/foo/bar/foo_40bar_2ecom/CallChannel,
+  {
+    ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref
+      namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
+    ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+    ...<tp:dbus-ref namespace="ofdT.Channel">TargetID</tp:dbus-ref>: 'foo@example.com',
+    ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandle</tp:dbus-ref>: 42,
+    ...<tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref>: False,
+    ...<tp:member-ref>InitialAudio</tp:member-ref>: True,
+    ...<tp:member-ref>InitialVideo</tp:member-ref>: True,
+    ...<tp:member-ref>InitialAudioName</tp:member-ref>: "audio",
+    ...<tp:member-ref>InitialVideoName</tp:member-ref>: "video",
+    ...<tp:member-ref>MutableContents</tp:member-ref>: True,
+  }])</pre></blockquote>
+
+      <p>The <tp:member-ref>InitialAudio</tp:member-ref> and
+        <tp:member-ref>InitialVideo</tp:member-ref> properties show that
+        the call has been started with two contents: one for audio
+        streaming and one for video streaming. The
+        <tp:member-ref>InitialAudioName</tp:member-ref> and
+        <tp:member-ref>InitialVideoName</tp:member-ref> properties also
+        show that the aforementioned audio and video contents have names
+        "audio" and "video".</p>
+
+      <p>Once the handler has notified the local user that there is an
+        incoming call waiting for acceptance, the handler should call
+        <tp:member-ref>SetRinging</tp:member-ref> to let the CM know.
+        The new channel should also be given to telepathy-farsight to
+        work out how the two participants will connect together.
+        telepathy-farsight will call the appropriate methods on the call's
+        <tp:dbus-ref namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>s
+        to negotiate codecs and transports.</p>
+
+      <p>To pick up the call, the handler should call
+        <tp:member-ref>Accept</tp:member-ref>. The
+        <tp:member-ref>CallState</tp:member-ref> property changes to
+        <tp:type>Call_State</tp:type>_Accepted and once media is
+        being transferred, telepathy-farsight will notify the
+        handler of a new pad to be shown to the local user in the
+        UI</p>
+
+      <p>To reject the call, the handler should call the
+        <tp:member-ref>Hangup</tp:member-ref> method. The
+        <tp:member-ref>CallState</tp:member-ref> property will change to
+        <tp:type>Call_State</tp:type>_Ended and the
+        <tp:member-ref>CallStateReason</tp:member-ref> property will
+        change to (self handle,
+        <tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
+        "org.freedesktop.Telepathy.Error.Rejected").</p>
+
+      <h4>Ongoing calls</h4>
+
+      <h5>Adding and removing contents</h5>
+
+      <p>When a call is open, new contents can be added as long as the
+        CM supports it. The
+        <tp:member-ref>MutableContents</tp:member-ref> property will let
+        the handler know whether further contents can be added or
+        existing contents removed. An example of this is starting a
+        voice call between a contact and then adding a video content.
+        To do this, the should call
+        <tp:member-ref>AddContent</tp:member-ref> like this:</p>
+
+      <blockquote>
+        <pre><tp:member-ref>AddContent</tp:member-ref>("video",
+           <tp:type>Media_Stream_Type</tp:type>_Video)</pre>
+      </blockquote>
+
+      <p>Assuming no errors, the new video content will be added to
+        the call. telepathy-farsight will pick up the new content and
+        perform the transport and codec negotiation automatically.
+        telpathy-farsight will signal when the video is ready to
+        show in the handler's user interface.</p>
+
+      <p>A similar method is used for removing contents from a call,
+        except that the <tp:dbus-ref
+        namespace="ofdT.Call.Content.DRAFT">Remove</tp:dbus-ref> method
+        is on the <tp:dbus-ref
+        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> object.</p>
+
+      <h5>Ending the call</h5>
+
+      <p>To end the call, the handler should call the
+        <tp:member-ref>Hangup</tp:member-ref> method. The
+        <tp:member-ref>CallState</tp:member-ref> property will change to
+        <tp:type>Call_State</tp:type>_Ended and
+        <tp:member-ref>CallStateReason</tp:member-ref> will change
+        to (self handle,
+        <tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
+        "org.freedesktop.Telepathy.Error.Cancelled").</p>
+
+      <p>If the other participant hangs up first then the
+        <tp:member-ref>CallState</tp:member-ref> property will change to
+        <tp:type>Call_State</tp:type>_Ended and
+        <tp:member-ref>CallStateReason</tp:member-ref> will change
+        to (remote contact,
+        <tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
+        "org.freedesktop.Telepathy.Error.Terminated").</p>
+
+      <h4>Multi-party calls</h4>
+
+      [TODO]
+
+      <h4>Call states</h4>
+
+      <p>There are many combinations of the
+        <tp:member-ref>CallState</tp:member-ref> and
+        <tp:member-ref>CallStateReason</tp:member-ref> properties which
+        mean different things. Here is a table to try to make these
+        meanings clearer:</p>
+
+      <table>
+        <tr>
+          <th rowspan="2"><tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref></th>
+          <th rowspan="2"><tp:member-ref>CallState</tp:member-ref></th>
+          <th colspan="3"><tp:member-ref>CallStateReason</tp:member-ref></th>
+          <th rowspan="2">Meaning</th>
+        </tr>
+        <tr>
+          <th>Actor</th>
+          <th>Reason</th>
+          <th>DBus_Reason</th>
+        </tr>
+        <!-- Pending_Initiator -->
+        <tr>
+          <td>True</td>
+          <td><tp:type>Call_State</tp:type>_Pending_Initiator</td>
+          <td>Self handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td>""</td>
+          <td>The outgoing call channel is waiting for the local user to call <tp:member-ref>Accept</tp:member-ref>.</td>
+        </tr>
+        <!-- Pending_Receiver -->
+        <tr>
+          <td>True</td>
+          <td><tp:type>Call_State</tp:type>_Pending_Receiver</td>
+          <td>Self handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td>""</td>
+          <td>The outgoing call is waiting for the remote contact to pick up the call.</td>
+        </tr>
+        <tr>
+          <td>False</td>
+          <td><tp:type>Call_State</tp:type>_Pending_Receiver</td>
+          <td>0</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_Unknown</td>
+          <td>""</td>
+          <td>The incoming call is waiting for the local user to call <tp:member-ref>Accept</tp:member-ref> on the call.</td>
+        </tr>
+        <!-- Accepted -->
+        <tr>
+          <td>True</td>
+          <td><tp:type>Call_State</tp:type>_Accepted</td>
+          <td>Remote contact handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td>""</td>
+          <td>The remote contact accepted the outgoing call.</td>
+        </tr>
+        <tr>
+          <td>False</td>
+          <td><tp:type>Call_State</tp:type>_Accepted</td>
+          <td>Self handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td>""</td>
+          <td>The local user accepted the incoming call.</td>
+        </tr>
+        <!-- Ended -->
+        <tr>
+          <td>True or False</td>
+          <td><tp:type>Call_State</tp:type>_Ended</td>
+          <td>Self handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td><tp:error-ref>Cancelled</tp:error-ref></td>
+          <td>The local user hung up the incoming or outgoing call.</td>
+        </tr>
+        <tr>
+          <td>True or False</td>
+          <td><tp:type>Call_State</tp:type>_Ended</td>
+          <td>Remote contact handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td><tp:error-ref>Terminated</tp:error-ref></td>
+          <td>The remote contact hung up the incoming or outgoing call.</td>
+        </tr>
+        <tr>
+          <td>True</td>
+          <td><tp:type>Call_State</tp:type>_Ended</td>
+          <td>Remote contact handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_No_Answer</td>
+          <td>""</td>
+          <td>The outgoing call was not picked up and the call ended.</td>
+        </tr>
+        <tr>
+          <td>False</td>
+          <td><tp:type>Call_State</tp:type>_Ended</td>
+          <td>Remote contact handle</td>
+          <td><tp:type>Call_State_Change_Reason</tp:type>_User_Requested</td>
+          <td><tp:error-ref>PickedUpElsewhere</tp:error-ref></td>
+          <td>The incoming call was ended because it was picked up elsewhere.</td>
+        </tr>
+      </table>
+
+      <h4>Requestable channel classes</h4>
+
+      <p>The <tp:dbus-ref
+        namespace="ofdT.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
+        for <tp:dbus-ref
+        namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channels
+        can be:</p>
+
+      <blockquote>
+        <pre>
+[( Fixed = { ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
+            ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+            ...<tp:member-ref>InitialVideo</tp:member-ref>: True
+          },
+  Allowed = [ ...<tp:member-ref>InitialVideoName</tp:member-ref>,
+              ...<tp:member-ref>InitialAudio</tp:member-ref>,
+              ...<tp:member-ref>InitialAudioName</tp:member-ref>
+            ]
+),
+( Fixed = { ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref>,
+            ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
+            ...<tp:member-ref>InitialAudio</tp:member-ref>: True
+          },
+  Allowed = [ ...<tp:member-ref>InitialAudioName</tp:member-ref>,
+              ...<tp:member-ref>InitialVideo</tp:member-ref>,
+              ...<tp:member-ref>InitialVideoName</tp:member-ref>
+            ]
+)]</pre></blockquote>
+
+      <p>Clients aren't allowed to make outgoing calls that have
+        neither initial audio nor initial video. Clearly, CMs
+        which don't support video should leave out the first class and
+        omit <tp:member-ref>InitialVideo</tp:member-ref> from the second
+        class, and vice versa for CMs without audio support.</p>
+
+      <p>Handlers should not close <tp:dbus-ref
+        namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channels
+        without first calling <tp:member-ref>Hangup</tp:member-ref> on
+        the channel. If a Call handler crashes, the <tp:dbus-ref
+        namespace="ofdT">ChannelDispatcher</tp:dbus-ref> will call
+        <tp:dbus-ref namespace="ofdT.Channel">Close</tp:dbus-ref> on the
+        channel which SHOULD also imply a call to
+        <tp:member-ref>Hangup</tp:member-ref>(<tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
+        "org.freedesktop.Telepathy.Error.Terminated", "") before
+        actually closing the channel.</p>
+
+    </tp:docstring>
+
+    <method name="SetRinging" tp:name-for-bindings="Set_Ringing">
+      <tp:changed version="0.21.2">renamed from Ringing</tp:changed>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Indicate that the local user has been alerted about the incoming
+          call.</p>
+
+        <p>This method is only useful if the
+          channel's <tp:dbus-ref namespace="ofdT.Channel">Requested</tp:dbus-ref>
+          property is False, and
+          the <tp:member-ref>CallState</tp:member-ref> is
+          <tp:type>Call_State</tp:type>_Pending_Receiver (an incoming
+          call waiting on the local user to pick up). While this is
+          the case, this method SHOULD change the
+          <tp:member-ref>CallFlags</tp:member-ref> to include
+          <tp:type>Call_Flags</tp:type>_Locally_Ringing, and notify the
+          remote contact that the local user has been alerted (if the
+          protocol implements this); repeated calls to this method
+          SHOULD succeed, but have no further effect.</p>
+
+        <p>In all other states, this method SHOULD fail with the error
+          NotAvailable.</p>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The call was <tp:dbus-ref namespace="ofdT.Channel"
+            >Requested</tp:dbus-ref>, so ringing does not make sense.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The call is no longer in state
+            <tp:type>Call_State</tp:type>_Pending_Receiver.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="Accept" tp:name-for-bindings="Accept">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>For incoming calls in state
+          <tp:type>Call_State</tp:type>_Pending_Receiver, accept the
+          incoming call; this changes the
+          <tp:member-ref>CallState</tp:member-ref> to
+          <tp:type>Call_State</tp:type>_Accepted.</p>
+
+        <p>For outgoing calls in state
+          <tp:type>Call_State</tp:type>_Pending_Initiator, actually
+          call the remote contact; this changes the
+          <tp:member-ref>CallState</tp:member-ref> to
+          <tp:type>Call_State</tp:type>_Pending_Receiver.</p>
+
+        <p>Otherwise, this method SHOULD fail with the error NotAvailable.</p>
+
+        <p>This method should be called exactly once per Call, by whatever
+          client (user interface) is handling the channel.</p>
+
+        <p>When this method is called, for each <tp:dbus-ref
+          namespace="ofdT.Call" >Content.DRAFT</tp:dbus-ref> whose
+          <tp:dbus-ref namespace="ofdT.Call.Content.DRAFT"
+          >Disposition</tp:dbus-ref> is
+          <tp:type>Call_Content_Disposition</tp:type>_Initial, any
+          streams where the <tp:dbus-ref
+          namespace="ofdT.Call.Stream.DRAFT">LocalSendingState</tp:dbus-ref>
+          is <tp:type>Sending_State</tp:type>_Pending_Send will be
+          moved to <tp:type>Sending_State</tp:type>_Sending as if
+          <tp:dbus-ref namespace="ofdT.Call.Stream.DRAFT"
+          >SetSending</tp:dbus-ref>(True) had been called.</p>
+      </tp:docstring>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The call is not in one of the states where this method makes sense.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="Hangup" tp:name-for-bindings="Hangup">
+      <tp:docstring>
+        Request that the call is ended. All contents will be removed
+        from the Call so that the
+        <tp:member-ref>Contents</tp:member-ref> property will be the
+        empty list.
+      </tp:docstring>
+
+      <arg direction="in" name="Reason"
+        type="u" tp:type="Call_State_Change_Reason">
+        <tp:docstring>
+          A generic hangup reason.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Detailed_Hangup_Reason"
+        type="s" tp:type="DBus_Error_Name">
+        <tp:docstring>
+          A more specific reason for the call hangup, if one is available, or
+          an empty string otherwise.
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Message" type="s">
+        <tp:docstring>
+          A human-readable message to be sent to the remote contact(s).
+
+          <tp:rationale>
+            XMPP Jingle allows calls to be terminated with a human-readable
+            message.
+          </tp:rationale>
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+          <tp:docstring>
+            The call has already been ended.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="AddContent" tp:name-for-bindings="Add_Content">
+      <tp:docstring>
+        Request that a new <tp:dbus-ref
+        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> of type
+        Content_Type is added to the Call. Handlers should check the
+        value of the <tp:member-ref>MutableContents</tp:member-ref>
+        property before trying to add another content as it might not
+        be allowed.
+      </tp:docstring>
+      <arg direction="in" name="Content_Name" type="s">
+        <tp:docstring>
+          <p>The suggested name of the content to add.</p>
+
+          <tp:rationale>
+            The content name property should be meaningful, so should
+            be given a name which is significant to the user. The name
+            could be a localized "audio", "video" or perhaps include
+            some string identifying the source, such as a webcam
+            identifier.
+          </tp:rationale>
+
+          <p>If there is already a content with the same name as this
+            property then a sensible suffix should be added. For example,
+            if this argument is "audio" but a content of the same name
+            already exists, a sensible suffix such as " (1)" is appended
+            to name the new content "audio (1)". A further content with the
+            name "audio" would then be named "audio (2)".</p>
+
+        </tp:docstring>
+      </arg>
+      <arg direction="in" name="Content_Type" type="u"
+          tp:type="Media_Stream_Type">
+        <tp:docstring>
+          The media stream type of the content to be added to the
+          call.
+        </tp:docstring>
+      </arg>
+      <arg direction="out" name="Content" type="o">
+        <tp:docstring>
+          Path to the newly-created <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy"
+            >Call.Content.DRAFT</tp:dbus-ref> object.
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The media stream type given is invalid.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+          <tp:docstring>
+            The media stream type requested is not implemented by the
+            CM.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotCapable">
+          <tp:docstring>
+            The content type requested cannot be added to this
+            call. Examples of why this might be the case include
+            because a second video stream cannot be added, or a
+            content cannot be added when the content set isn't
+            mutable.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <signal name="ContentAdded"
+            tp:name-for-bindings="Content_Added">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when a new <tp:dbus-ref namespace="ofdT.Call"
+          >Content.DRAFT</tp:dbus-ref> is added to the call.</p>
+      </tp:docstring>
+      <arg name="Content" type="o">
+        <tp:docstring>
+          Path to the newly-created <tp:dbus-ref namespace="ofdT.Call"
+          >Content.DRAFT</tp:dbus-ref> object.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <signal name="ContentRemoved" tp:name-for-bindings="Content_Removed">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when a <tp:dbus-ref namespace="ofdT.Call"
+          >Content.DRAFT</tp:dbus-ref> is removed from the call.</p>
+      </tp:docstring>
+      <arg name="Content" type="o">
+        <tp:docstring>
+          The <tp:dbus-ref namespace="ofdT.Call"
+          >Content.DRAFT</tp:dbus-ref> which was removed.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <property name="Contents" type="ao" access="read"
+      tp:name-for-bindings="Contents">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The list of <tp:dbus-ref
+          namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> objects that
+          are part of this call. Change notification is via the
+          <tp:member-ref>ContentAdded</tp:member-ref> and
+          <tp:member-ref>ContentRemoved</tp:member-ref> signals.
+        </p>
+      </tp:docstring>
+    </property>
+
+    <tp:enum type="u" name="Call_State">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The state of a call, as a whole.</p>
+
+        <p>The allowed transitions are:</p>
+
+        <ul>
+          <li>Pending_Initiator → Pending_Receiver (for outgoing calls,
+            when <tp:member-ref>Accept</tp:member-ref> is called)</li>
+          <li>Pending_Receiver → Accepted (for incoming calls, when
+            <tp:member-ref>Accept</tp:member-ref> is called; for outgoing
+            calls to a contact, when the remote contact accepts the call;
+            for joining a conference call, when the local user successfully
+            joins the conference)</li>
+          <li>Accepted → Pending_Receiver (when transferred to another
+            contact)</li>
+          <li>any state → Ended (when the call is terminated normally, or
+            when an error occurs)</li>
+        </ul>
+
+        <p>Clients MAY consider unknown values from this enum to be an
+          error - additional values will not be defined after the Call
+          specification is declared to be stable.</p>
+      </tp:docstring>
+
+      <tp:enumvalue suffix="Unknown" value = "0">
+        <tp:docstring>
+          The call state is not known. This call state MUST NOT appear as a
+          value of the <tp:member-ref>CallState</tp:member-ref> property, but
+          MAY be used by client code to represent calls whose state is as yet
+          unknown.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Pending_Initiator" value = "1">
+        <tp:docstring>
+          The initiator of the call hasn't accepted the call yet. This state
+          only makes sense for outgoing calls, where it means that the local
+          user has not yet sent any signalling messages to the remote user(s),
+          and will not do so until <tp:member-ref>Accept</tp:member-ref> is
+          called.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Pending_Receiver" value = "2">
+        <tp:docstring>
+          The receiver (the contact being called) hasn't accepted the call yet.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Accepted" value = "3">
+        <tp:docstring>
+          The contact being called has accepted the call.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Ended" value = "4">
+        <tp:docstring>
+          The call has ended, either via normal termination or an error.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <tp:flags name="Call_Flags" value-prefix="Call_Flag" type="u">
+      <tp:docstring>
+        A set of flags representing the status of the call as a whole,
+        providing more specific information than the
+        <tp:member-ref>CallState</tp:member-ref>. Many of these flags only make
+        sense in a particular state.
+      </tp:docstring>
+
+      <tp:flag suffix="Locally_Ringing" value="1">
+        <tp:docstring>
+          The local contact has been alerted about the call but has not
+          responded; if possible, the remote contact(s) have been informed of
+          this fact. This flag only makes sense on incoming calls in
+          state <tp:type>Call_State</tp:type>_Pending_Receiver. It SHOULD
+          be set when <tp:member-ref>SetRinging</tp:member-ref> is
+          called successfully, and unset when the state changes.
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Queued" value="2">
+        <tp:docstring>
+          The contact is temporarily unavailable, and the call has been placed
+          in a queue (e.g. 182 Queued in SIP, or call-waiting in telephony).
+          This flag only makes sense on outgoing 1-1 calls in
+          state <tp:type>Call_State</tp:type>_Pending_Receiver. It SHOULD be
+          set or unset according to informational messages from other
+          contacts.
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Locally_Held" value="4">
+        <tp:docstring>
+          The call has been put on hold by the local user, e.g. using
+          the <tp:dbus-ref namespace="ofdT.Channel.Interface"
+          >Hold</tp:dbus-ref> interface. This flag SHOULD only be set
+          if there is at least one Content, and all Contents are
+          locally held; it makes sense on calls in state
+          <tp:type>Call_State</tp:type>_Pending_Receiver
+          or <tp:type>Call_State</tp:type>_Accepted.
+
+          <tp:rationale>
+            Otherwise, in transient situations where some but not all contents
+            are on hold, UIs would falsely indicate that the call as a whole
+            is on hold, which could lead to the user saying something they'll
+            regret, while under the impression that the other contacts can't
+            hear them!
+          </tp:rationale>
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Forwarded" value="8">
+        <tp:docstring>
+          The initiator of the call originally called a contact other than the
+          current recipient of the call, but the call was then forwarded or
+          diverted. This flag only makes sense on outgoing calls, in state
+          <tp:type>Call_State</tp:type>_Pending_Receiver or
+          <tp:type>Call_State</tp:type>_Accepted. It SHOULD be set or unset
+          according to informational messages from other contacts.
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="In_Progress" value="16">
+        <tp:docstring>
+          Progress has been made in placing the outgoing call, but the
+          contact may not have been made aware of the call yet
+          (so the Ringing state is not appropriate). This corresponds to SIP's
+          status code 183 Session Progress, and could be used when the
+          outgoing call has reached a gateway, for instance.
+          This flag only makes sense on outgoing calls in state
+          <tp:type>Call_State</tp:type>_Pending_Receiver, and SHOULD be set
+          or unset according to informational messages from servers, gateways
+          and other infrastructure.
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Clearing" value="32">
+        <tp:docstring>
+          This flag only occurs when the CallState is Ended. The call with
+          this flag set has ended, but not all resources corresponding to the
+          call have been freed yet.
+
+          Depending on the protocol there might be some audible feedback while
+          the clearing flag is set.
+
+          <tp:rationale>
+            In calls following the ITU-T Q.931 standard there is a period of
+            time between the call ending and the underlying channel being
+            completely free for re-use.
+          </tp:rationale>
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Muted" value="64">
+        <tp:docstring>
+          The call has been muted by the local user, e.g. using the
+          <tp:dbus-ref namespace="ofdT.Call.Content.Interface"
+          >Mute.DRAFT</tp:dbus-ref> interface. This flag SHOULD only
+          be set if there is at least one Content, and all Contents
+          are locally muted; it makes sense on calls in state
+          <tp:type>Call_State</tp:type>_Pending_Receiver or
+          <tp:type>Call_State</tp:type>_Accepted.
+        </tp:docstring>
+      </tp:flag>
+    </tp:flags>
+
+    <property name="CallStateDetails"
+      tp:name-for-bindings="Call_State_Details" type="a{sv}" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A map used to provide optional extensible details for the
+          <tp:member-ref>CallState</tp:member-ref>,
+          <tp:member-ref>CallFlags</tp:member-ref> and/or
+          <tp:member-ref>CallStateReason</tp:member-ref>.</p>
+
+        <p>Well-known keys and their corresponding value types include:</p>
+
+        <dl>
+          <dt>hangup-message - s</dt>
+          <dd>An optional human-readable message sent when the call was ended,
+            corresponding to the Message argument to the
+            <tp:member-ref>Hangup</tp:member-ref> method. This is only
+            applicable when the call state is <tp:type>Call_State</tp:type>_Ended.
+            <tp:rationale>
+              XMPP Jingle can send such messages.
+            </tp:rationale>
+          </dd>
+
+          <dt>queue-message - s</dt>
+          <dd>An optional human-readable message sent when the local contact
+            is being held in a queue. This is only applicable when
+            <tp:type>Call_Flags</tp:type>_Queued is in the call flags.
+            <tp:rationale>
+              SIP 182 notifications can have human-readable messages attached.
+            </tp:rationale>
+          </dd>
+
+          <dt>debug-message - s</dt>
+          <dd>A message giving further details of any error indicated by the
+            <tp:member-ref>CallStateReason</tp:member-ref>. This will not
+            normally be localized or suitable for display to users, and is only
+            applicable when the call state is
+            <tp:type>Call_State</tp:type>_Ended.</dd>
+        </dl>
+      </tp:docstring>
+    </property>
+
+    <property name="CallState" type="u" access="read"
+      tp:name-for-bindings="Call_State" tp:type="Call_State">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The current high-level state of this call. The
+          <tp:member-ref>CallFlags</tp:member-ref> provide additional
+          information, and the <tp:member-ref>CallStateReason</tp:member-ref>
+          and <tp:member-ref>CallStateDetails</tp:member-ref> explain the
+          reason for the current values for those properties.</p>
+
+        <p>Note that when in a conference call, this property is
+          purely to show your state in joining the call. The receiver
+          (or remote contact) in this context is the conference server
+          itself. The property does not change when other call members'
+          states change.</p>
+
+        <p>Clients MAY consider unknown values in this property to be an
+          error.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="CallFlags" type="u" access="read"
+      tp:name-for-bindings="Call_Flags" tp:type="Call_Flags">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Flags representing the status of the call as a whole,
+          providing more specific information than the
+          <tp:member-ref>CallState</tp:member-ref>.</p>
+
+        <p>Clients are expected to ignore unknown flags in this property,
+          without error.</p>
+
+        <p>When an ongoing call is active and not on hold or has any
+          other problems, this property will be 0.</p>
+      </tp:docstring>
+    </property>
+
+    <tp:enum name="Call_State_Change_Reason" type="u">
+      <tp:docstring>
+        A simple representation of the reason for a change in the call's
+        state, which may be used by simple clients, or used as a fallback
+        when the DBus_Reason member of a <tp:type>Call_State_Reason</tp:type>
+        struct is not understood.
+      </tp:docstring>
+
+      <tp:enumvalue suffix="Unknown" value="0">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          We just don't know. Unknown values of this enum SHOULD also be
+          treated like this.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="User_Requested" value="1">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The change was requested by the contact indicated by the Actor
+            member of a <tp:type>Call_State_Reason</tp:type> struct.</p>
+
+          <p>If the Actor is the local user, the DBus_Reason SHOULD be the
+            empty string.</p>
+
+          <p>If the Actor is a remote user, the DBus_Reason SHOULD be the empty
+            string if the call was terminated normally, but MAY be a non-empty
+            error name to indicate error-like call termination reasons (call
+            rejected as busy, kicked from a conference by a moderator, etc.).</p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Forwarded" value="2">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The call was forwarded. If known, the handle of the contact
+            the call was forwarded to will be indicated by the Actor member
+            of a <tp:type>Call_State_Reason</tp:type> struct.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="No_Answer" value="3">
+        <tp:added version="0.21.2"/>
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The <tp:member-ref>CallState</tp:member-ref> changed from
+            <tp:type>Call_State</tp:type>_Pending_Receiver to
+            <tp:type>Call_State</tp:type>_Ended because the initiator
+            ended the call before the receiver accepted it. With an
+            incoming call this state change reason signifies a missed
+            call.</p>
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <tp:struct name="Call_State_Reason">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A description of the reason for a change to the
+          <tp:member-ref>CallState</tp:member-ref> and/or
+          <tp:member-ref>CallFlags</tp:member-ref>.</p>
+      </tp:docstring>
+
+      <tp:member type="u" tp:type="Contact_Handle" name="Actor">
+        <tp:docstring>
+          The contact responsible for the change, or 0 if no contact was
+          responsible.
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member type="u" tp:type="Call_State_Change_Reason" name="Reason">
+        <tp:docstring>
+          The reason, chosen from a limited set of possibilities defined by
+          the Telepathy specification. If
+          <tp:type>Call_State_Change_Reason</tp:type>_User_Requested then
+          the Actor member will dictate whether it was the local user or
+          a remote contact responsible.
+        </tp:docstring>
+      </tp:member>
+
+      <tp:member type="s" tp:type="DBus_Error_Name" name="DBus_Reason">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>A specific reason for the change, which may be a D-Bus error in
+            the Telepathy namespace, a D-Bus error in any other namespace
+            (for implementation-specific errors), or the empty string to
+            indicate that the state change was not an error.</p>
+
+          <p>This SHOULD be an empty string for changes to any state other
+            than Ended.</p>
+
+          <p>The errors Cancelled and Terminated SHOULD NOT be used here;
+            an empty string SHOULD be used instead.</p>
+
+          <tp:rationale>
+            <p>Those error names are used to indicate normal call
+              termination by the local user or another user, respectively,
+              in contexts where a D-Bus error name must appear.</p>
+          </tp:rationale>
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <property name="CallStateReason" tp:name-for-bindings="Call_State_Reason"
+      type="(uus)" access="read"  tp:type="Call_State_Reason">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The reason for the last change to the
+          <tp:member-ref>CallState</tp:member-ref> and/or
+          <tp:member-ref>CallFlags</tp:member-ref>. The
+          <tp:member-ref>CallStateDetails</tp:member-ref> MAY provide additional
+          information.</p>
+      </tp:docstring>
+    </property>
+
+    <signal name="CallStateChanged"
+            tp:name-for-bindings="Call_State_Changed">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when the state of the call as a whole changes.</p>
+
+        <p>This signal is emitted for any change in the properties
+          corresponding to its arguments, even if the other properties
+          referenced remain unchanged.</p>
+      </tp:docstring>
+
+      <arg name="Call_State" type="u" tp:type="Call_State">
+        <tp:docstring>
+          The new value of the <tp:member-ref>CallState</tp:member-ref>
+          property.
+        </tp:docstring>
+      </arg>
+
+      <arg name="Call_Flags" type="u" tp:type="Call_Flags">
+        <tp:docstring>
+          The new value of the <tp:member-ref>CallFlags</tp:member-ref>
+          property.
+        </tp:docstring>
+      </arg>
+
+      <arg name="Call_State_Reason" type="(uus)" tp:type="Call_State_Reason">
+        <tp:docstring>
+          The new value of the <tp:member-ref>CallStateReason</tp:member-ref>
+          property.
+        </tp:docstring>
+      </arg>
+
+      <arg name="Call_State_Details" type="a{sv}">
+        <tp:docstring>
+          The new value of the <tp:member-ref>CallStateDetails</tp:member-ref>
+          property.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <property name="HardwareStreaming" tp:name-for-bindings="Hardware_Streaming"
+        type="b" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If this property is True, all of the media streaming is done by some
+          mechanism outside the scope of Telepathy.</p>
+
+        <tp:rationale>
+          <p>A connection manager might be intended for a specialized hardware
+            device, which will take care of the audio streaming (e.g.
+            telepathy-yafono, which uses GSM hardware which does the actual
+            audio streaming for the call).</p>
+        </tp:rationale>
+
+        <p>If this is False, the handler is responsible for doing the actual
+          media streaming for at least some contents itself. Those contents
+          will have the <tp:dbus-ref namespace="ofdT.Call.Content.Interface"
+          >Media.DRAFT</tp:dbus-ref> interface, to communicate the necessary
+          information to a streaming implementation. Connection managers SHOULD
+          operate like this, if possible.</p>
+
+        <tp:rationale>
+          <p>Many connection managers (such as telepathy-gabble) only do the
+            call signalling, and expect the client to do the actual streaming
+            using something like
+            <a href="http://farsight.freedesktop.org/">Farsight</a>, to improve
+            latency and allow better UI integration.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <tp:flags type="u" name="Call_Member_Flags" value-prefix="Call_Member_Flag">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A set of flags representing the status of a remote contact in a
+          call.</p>
+
+        <p>It is protocol- and client-specific whether a particular contact
+          will ever have a particular flag set on them, and Telepathy clients
+          SHOULD NOT assume that a flag will ever be set.</p>
+
+        <tp:rationale>
+          <p>180 Ringing in SIP, and its equivalent in XMPP, are optional
+            informational messages, and implementations are not required
+            to send them. The same applies to the messages used to indicate
+            hold state.</p>
+        </tp:rationale>
+      </tp:docstring>
+
+      <tp:flag suffix="Ringing" value = "1">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The remote contact's client has told us that the contact has been
+            alerted about the call but has not responded.</p>
+
+          <tp:rationale>
+            <p>This is a flag per member, not a flag for the call as a whole,
+              because in Muji conference calls, you could invite someone and
+              have their state be "ringing" for a while.</p>
+          </tp:rationale>
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Held" value = "2">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The call member has put this call on hold.</p>
+
+          <tp:rationale>
+            <p>This is a flag per member, not a flag for the call as a whole,
+              because in conference calls, any member could put the conference
+              on hold.</p>
+          </tp:rationale>
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Conference_Host" value="4">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          This contact has merged this call into a conference. Note that GSM
+          provides a notification when the remote party merges a call into a
+          conference, but not when it is split out again; thus, this flag can
+          only indicate that the call has been part of a conference at some
+          point. If a GSM connection manager receives a notification that a
+          call has been merged into a conference a second time, it SHOULD
+          represent this by clearing and immediately re-setting this flag on
+          the remote contact.
+        </tp:docstring>
+      </tp:flag>
+    </tp:flags>
+
+    <tp:mapping name="Call_Member_Map" array-name="Call_Member_Map_List">
+      <tp:docstring>A mapping from handles to their current state in the call.
+        </tp:docstring>
+      <tp:member type="u" tp:type="Handle" name="key"/>
+      <tp:member type="u" tp:type="Call_Member_Flags" name="Flag"/>
+    </tp:mapping>
+
+    <signal name="CallMembersChanged"
+      tp:name-for-bindings="Call_Members_Changed">
+      <tp:docstring>
+        Emitted when the <tp:member-ref>CallMembers</tp:member-ref> property
+        changes in any way, either because contacts have been added to the
+        call, contacts have been removed from the call, or contacts' flags
+        have changed.
+      </tp:docstring>
+
+      <arg name="Flags_Changed" type="a{uu}" tp:type="Call_Member_Map">
+        <tp:docstring>
+          A map from members of the call to their new call member flags,
+          including at least the members who have been added to
+          <tp:member-ref>CallMembers</tp:member-ref>, and the members whose
+          flags have changed.
+        </tp:docstring>
+      </arg>
+      <arg name="Removed"  type="au" tp:type="Contact_Handle[]">
+        <tp:docstring>
+          A list of members who have left the call, i.e. keys to be removed
+          from <tp:member-ref>CallMembers</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <property name="CallMembers" tp:name-for-bindings="Call_Members"
+      type="a{uu}" access="read" tp:type="Call_Member_Map">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A mapping from the remote contacts that are part of this call to flags
+          describing their status. This mapping never has the local user's handle
+          as a key.</p>
+
+        <p>When the call ends, this property should be an empty list,
+          and notified with
+          <tp:member-ref>CallMembersChanged</tp:member-ref></p>
+
+        <p>If the Call implements
+          <tp:dbus-ref namespace="ofdT.Channel.Interface"
+          >Group</tp:dbus-ref> and the Group members are
+          channel-specific handles, then this call SHOULD also use
+          channel-specific handles.</p>
+
+        <p>Anonymous members are exposed as channel-specific handles
+          with no owner.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="InitialTransport" tp:name-for-bindings="Initial_Transport"
+      type="s" access="read" tp:requestable="yes" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If set on a requested channel, this indicates the transport that
+          should be used for this call. Where not applicable, this property
+          is defined to be the empty string, in particular, on CMs with
+          hardware streaming.</p>
+
+        <tp:rationale>
+          When implementing a voip gateway one wants the outgoing leg of the
+          gatewayed to have the same transport as the incoming leg. This
+          property allows the gateway to request a Call with the right
+          transport from the CM.
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="InitialAudio" tp:name-for-bindings="Initial_Audio"
+      type="b" access="read" tp:immutable="yes" tp:requestable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>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 <tp:dbus-ref
+          namespace="ofdT.Channel.Type.Call.DRAFT">AddContent</tp:dbus-ref>.</p>
+
+        <p>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.</p>
+
+        <p>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.</p>
+
+        <p>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
+          <tp:dbus-ref namespace="ofdT.Channel.Type.Call.DRAFT"
+          >Contents</tp:dbus-ref>).</p>
+
+        <p>The name of this new content can be decided by using the
+          <tp:member-ref>InitialAudioName</tp:member-ref> property.</p>
+
+        <p>Connection managers that support the <tp:dbus-ref
+          namespace="ofdT.Connection.Interface">ContactCapabilities</tp:dbus-ref>
+          interface SHOULD represent the capabilities of receiving audio
+          and/or video calls by including a channel class in
+          a contact's capabilities with ChannelType = Call
+          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.</p>
+
+        <tp:rationale>
+          <p>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.</p>
+        </tp:rationale>
+
+        <p>Clients that are willing to receive audio and/or video calls
+          SHOULD include the following among their channel classes if
+          calling <tp:dbus-ref
+          namespace="ofdT.Connection.Interface.ContactCapabilities">UpdateCapabilities</tp:dbus-ref>
+          (clients of a <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>
+          SHOULD instead arrange for the ChannelDispatcher to do this,
+          by including the filters in their <tp:dbus-ref
+          namespace="ofdT.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
+          properties):</p>
+
+        <ul>
+          <li>{ ChannelType = Call }</li>
+          <li>{ ChannelType = Call, InitialAudio = True }
+            if receiving calls with audio is supported</li>
+          <li>{ ChannelType = Call, InitialVideo = True }
+            if receiving calls with video is supported</li>
+        </ul>
+
+        <tp:rationale>
+          <p>Connection managers for protocols with capability discovery,
+            like XMPP, need this information to advertise the appropriate
+            capabilities for their protocol.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="InitialVideo" tp:name-for-bindings="Initial_Video"
+      type="b" access="read" tp:immutable="yes" tp:requestable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The same as <tp:member-ref>InitialAudio</tp:member-ref>, but for
+          a video stream. This property is immutable (cannot change).</p>
+
+        <p>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.</p>
+
+        <p>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.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="InitialAudioName" tp:name-for-bindings="Initial_Audio_Name"
+      type="s" access="read" tp:immutable="yes" tp:requestable="yes">
+      <tp:added version="0.21.2"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If <tp:member-ref>InitialAudio</tp:member-ref> is set to
+          True, then this property will name the intial audio content
+          with the value of this property.</p>
+
+        <tp:rationale>
+          <p>Content names are meant to be significant, but if no name
+            can be given to initial audio content, then its name cannot
+            be meaningful or even localized.</p>
+        </tp:rationale>
+
+        <p>If this property is empty or missing from the channel
+          request and InitialAudio is True, then the CM must come up
+          with a sensible for the content, such as "audio".</p>
+
+        <p>If the protocol has no concept of stream names then this
+          property will not show up in the allowed properties list of
+          the Requestable Channel Classes for call channels.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="InitialVideoName" tp:name-for-bindings="Initial_Video_Name"
+      type="s" access="read" tp:immutable="yes" tp:requestable="yes">
+      <tp:added version="0.21.2"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The same as
+          <tp:member-ref>InitialAudioName</tp:member-ref>, but for a
+          video stream created by setting
+          <tp:member-ref>InitialVideo</tp:member-ref> to True. This
+          property is immutable and so cannot change.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="MutableContents" tp:name-for-bindings="Mutable_Contents"
+      type="b" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If True, a stream of a different content type can be added
+        after the Channel has been requested </p>
+
+        <p>If this property is missing, clients SHOULD assume that it is False,
+          and thus that the channel's streams cannot be changed once the call
+          has started.</p>
+
+        <p>If this property isn't present in the "allowed" set in any of the
+          Call entries contact capabilities, then user interfaces MAY choose to
+          show a separate "call" option for each class of call.</p>
+
+          <tp:rationale>
+            <p>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.
+            </p>
+          </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <tp:hct name="audio">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>This client supports audio calls.</p>
+      </tp:docstring>
+    </tp:hct>
+
+    <tp:hct name="video">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>This client supports video calls.</p>
+      </tp:docstring>
+    </tp:hct>
+
+    <tp:hct name="gtalk-p2p">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The client can implement streaming for streams whose <tp:dbus-ref
+          namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
+          property is <tp:type>Stream_Transport_Type</tp:type>_GTalk_P2P.</p>
+      </tp:docstring>
+    </tp:hct>
+
+    <tp:hct name="ice">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The client can implement streaming for streams whose <tp:dbus-ref
+          namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
+          property is <tp:type>Stream_Transport_Type</tp:type>_ICE.</p>
+      </tp:docstring>
+    </tp:hct>
+
+    <tp:hct name="wlm-2009">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The client can implement streaming for streams whose <tp:dbus-ref
+          namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
+          property is <tp:type>Stream_Transport_Type</tp:type>_WLM_2009.</p>
+      </tp:docstring>
+    </tp:hct>
+
+    <tp:hct name="shm">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The client can implement streaming for streams whose <tp:dbus-ref
+          namespace="ofdT.Call.Stream.Interface.Media.DRAFT">Transport</tp:dbus-ref>
+          property is <tp:type>Stream_Transport_Type</tp:type>_SHM.</p>
+      </tp:docstring>
+    </tp:hct>
+
+    <tp:hct name="video/h264" is-family="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The client supports media streaming with H264 (etc.).</p>
+
+        <p>This handler capability token is a one of a family
+          of similar tokens: for any other audio or video codec whose MIME
+          type is audio/<em>subtype</em> or video/<em>subtype</em>, a handler
+          capability token of this form may exist (the subtype MUST appear
+          in lower case in this context). Clients MAY support more
+          codecs than they explicitly advertise support for; clients SHOULD
+          explicitly advertise support for their preferred codec(s), and
+          for codecs like H264 that are, in practice, significant in codec
+          negotiation.</p>
+
+        <tp:rationale>
+          <p>For instance, the XMPP capability used by the Google Video
+            Chat web client to determine whether a client is compatible
+            with it requires support for H264 video, so an XMPP
+            connection manager that supports this version of Jingle should
+            not advertise the Google Video Chat capability unless there
+            is at least one installed client that declares that it supports
+            <code>video/h264</code> on Call channels.</p>
+        </tp:rationale>
+
+        <p>For example, a client could advertise support for audio and video
+          calls using Speex, Theora and H264 by having five handler capability
+          tokens in its <tp:dbus-ref
+          namespace="ofdT.Client.Handler">Capabilities</tp:dbus-ref>
+          property:</p>
+
+        <ul>
+          <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/audio</code></li>
+          <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/audio/speex</code></li>
+          <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/video</code></li>
+          <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/video/theora</code></li>
+          <li><code>org.freedesktop.Telepathy.Channel.Type.Call.DRAFT/video/h264</code></li>
+        </ul>
+
+        <p>Clients MAY have media signalling abilities without explicitly
+          supporting any particular codec, and connection managers SHOULD
+          support this usage.</p>
+
+        <tp:rationale>
+          <p>This is necessary to support gatewaying between two Telepathy
+            connections, in which case the available codecs might not be
+            known to the gatewaying process.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </tp:hct>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Makefile.am b/spec/Makefile.am
new file mode 100644
index 0000000..f0d43af
--- /dev/null
+++ b/spec/Makefile.am
@@ -0,0 +1,9 @@
+EXTRA_DIST = \
+    Call_Content_Codec_Offer.xml \
+    Call_Content_Interface_Media.xml \
+    Call_Content_Interface_Mute.xml \
+    Call_Content.xml \
+    Call_Stream_Endpoint.xml \
+    Call_Stream_Interface_Media.xml \
+    Call_Stream.xml \
+    Channel_Type_Call.xml