Update to spec 0.25.1.

53 files changed, 4260 insertions, 1081 deletions

diff --git a/spec/Account.xml b/spec/Account.xml
index b706e279..675ea812 100644
--- a/spec/Account.xml
+++ b/spec/Account.xml
@@ -272,6 +272,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           <li><tt>lj-talk</tt> (for <a
             href="http://www.livejournal.com/chat/">LiveJournal's IM
             service</a>)</li>
+          <li><tt>windows-live</tt> (for <a
+            href="http://live.com">Windows Live Messenger IM service</a>)</li>
 
         </ul>
 
diff --git a/spec/Account_Interface_Avatar.xml b/spec/Account_Interface_Avatar.xml
index a8b78c8a..a6c51672 100644
--- a/spec/Account_Interface_Avatar.xml
+++ b/spec/Account_Interface_Avatar.xml
@@ -40,6 +40,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <tp:struct name="Avatar">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A struct containing avatar data marked with its MIME type.</p>
+
+        <p>May be set to an empty byte-array and an empty string, indicating
+          no avatar.</p>
       </tp:docstring>
       <tp:member type="ay" name="Avatar_Data"/>
       <tp:member type="s" name="MIME_Type"/>
diff --git a/spec/Account_Manager.xml b/spec/Account_Manager.xml
index cd82e7f5..52cd42a1 100644
--- a/spec/Account_Manager.xml
+++ b/spec/Account_Manager.xml
@@ -25,19 +25,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         details.</p>
 
       <p>The current account manager is defined to be the process that owns
-        the well-known bus name org.freedesktop.Telepathy.AccountManager on
+        the well-known bus name <tt>org.freedesktop.Telepathy.AccountManager</tt> on
         the session bus. This process must export an
-        /org/freedesktop/Telepathy/AccountManager object with the
+        <tt>/org/freedesktop/Telepathy/AccountManager</tt> object with the
         AccountManager interface.</p>
-
-      <p>Until a mechanism exists for making a reasonable automatic choice
-        of AccountManager implementation, implementations SHOULD NOT
-        register as an activatable service for the AccountManager's
-        well-known bus name. Instead, it is RECOMMENDED that some component
-        of the user's session will select and activate a particular
-        implementation, and that other Telepathy-enabled programs can
-        detect whether Telepathy is in use by checking whether the
-        AccountManager's well-known name is in use at runtime.</p>
     </tp:docstring>
     <tp:added version="0.17.2"/>
 
@@ -275,16 +266,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-            <p>The Connection_Manager is not installed or does not
-              implement the given Protocol, or one of the properties in the
-              Properties argument is unsupported.</p>
+            <p>The <var>Connection_Manager</var> is not installed or does not
+              implement the given <var>Protocol</var>.</p>
           </tp:docstring>
         </tp:error>
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
           <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-            <p>The Parameters provided omit a required parameter
-              or provide unsupported parameter, or the type of one
-              of the Parameters or Properties is inappropriate.</p>
+            <p>The <var>Parameters</var> provided were unacceptable: they might
+              omit a
+              <tp:value-ref type='Conn_Mgr_Param_Flags'>Required</tp:value-ref>
+              parameter, include an unsupported parameter, or have a value of
+              the wrong type.</p>
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
diff --git a/spec/Call_Content.xml b/spec/Call_Content.xml
index 270d99b0..ef08acc3 100644
--- a/spec/Call_Content.xml
+++ b/spec/Call_Content.xml
@@ -20,91 +20,43 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call.Content.DRAFT"
+  <interface name="org.freedesktop.Telepathy.Call1.Content"
       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
+      <p>This object represents one Content inside a <tp:dbus-ref
+      namespace="ofdT.Channel.Type">Call1</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.
+      namespace="ofdT.Call1">Stream</tp:dbus-ref> objects which
+      represent the actual transport to one or more remote contacts.</p>
+      <tp:rationale>
+        There are two cases where multiple streams may happen:
+        <ul>
+          <li>Calls with more than two participants, if the protocol does not
+          support multicast, and does not have mixer proxy.</li>
+          <li>With jingle, when calling a contact connected from multiple
+          resources, a stream is created for each resource. Once the remote
+          contact answered from one of its resources, all other streams get
+          removed.</li>
+        </ul>
+      </tp:rationale>
+      <p>For protocols that support muting all streams of a given content
+      separately, this object MAY also implement the <tp:dbus-ref
+      namespace="ofdT.Call1.Interface">Mute</tp:dbus-ref> interface</p>
     </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.
+        Remove the content from the call. This will cause
+        <tp:member-ref>Removed</tp:member-ref>((self_handle,
+        <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>, "", "")) to be
+        emitted.
       </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">
@@ -120,7 +72,7 @@
       <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>
+          namespace="ofdT.Channel.Type">Call1.ContentRemoved</tp:dbus-ref>
           signal.</p>
       </tp:docstring>
     </signal>
@@ -130,8 +82,9 @@
       <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>.
+          namespace="ofdT.Call1">Content.Interface.Media</tp:dbus-ref>,
+          <tp:dbus-ref namespace="ofdT.Channel">Interface.Hold</tp:dbus-ref> or
+          <tp:dbus-ref namespace="ofdT.Call1">Interface.Mute</tp:dbus-ref>.
           This SHOULD NOT include the Content interface itself, and cannot
           change once the content has been created.</p>
       </tp:docstring>
@@ -164,13 +117,13 @@
         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
+        namespace="ofdT.Channel.Type.Call1">Accept</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
+          The content has no specific disposition.
         </tp:docstring>
       </tp:enumvalue>
 
@@ -178,14 +131,14 @@
         <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>
+          namespace="ofdT.Channel.Type.Call1">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
+          namespace="ofdT.Call1.Stream">LocalSendingState</tp:dbus-ref>
+          set to <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> will be
+          moved to <tp:value-ref type="Sending_State">Sending</tp:value-ref> as if
           <tp:dbus-ref
-          namespace="ofdT.Call.Stream.DRAFT">SetSending</tp:dbus-ref>
+          namespace="ofdT.Call1.Stream">SetSending</tp:dbus-ref>
           (True) had been called.</p>
         </tp:docstring>
       </tp:enumvalue>
@@ -208,7 +161,7 @@
       <arg name="Streams" type="ao">
          <tp:docstring>
            The <tp:dbus-ref
-           namespace="ofdT.Call">Stream.DRAFT</tp:dbus-ref>s which were
+           namespace="ofdT.Call1">Stream</tp:dbus-ref>s which were
            added.
          </tp:docstring>
        </arg>
@@ -221,19 +174,24 @@
          <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>
+        <tp:docstring>
+          The <tp:dbus-ref
+          namespace="ofdT.Call1">Stream</tp:dbus-ref>s which were
+          removed.
+        </tp:docstring>
+      </arg>
+      <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason">
+        <tp:docstring>
+          Why the content was 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
+        <p>The list of <tp:dbus-ref namespace="ofdT.Call1"
+          >Stream</tp:dbus-ref> objects that exist in this
           content.</p>
 
         <tp:rationale>
diff --git a/spec/Call_Content_Interface_Audio_Control.xml b/spec/Call_Content_Interface_Audio_Control.xml
new file mode 100644
index 00000000..b13e02f5
--- /dev/null
+++ b/spec/Call_Content_Interface_Audio_Control.xml
@@ -0,0 +1,111 @@
+<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
+<node name="/Call_Content_Interface_Audio_Control"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2009-2011 Collabora Ltd.</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.Call1.Content.Interface.AudioControl"
+    tp:causes-havoc="experimental">
+    <tp:added version="0.25.1">(draft 1)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Call1.Content.Interface.Media"/>
+    <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal" value="true"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface allows the connection manager to be kept informed of,
+          and control, the input and output volumes of an audio stream.
+          While generally not needed, if the connection manager needs to
+          handle stream volumes directly (typically when using
+          <tp:value-ref>Call_Content_Packetization_Type_Raw</tp:value-ref>),
+          this interface may be necessary.</p>
+
+      <p>If this interface is present, the handler should call
+          <tp:member-ref>ReportInputVolume</tp:member-ref>
+          and <tp:member-ref>ReportOutputVolume</tp:member-ref> whenever the
+          input and output volume change, both when the user manually modifies
+          the volume and when the volumes are adjusted in response to
+          <tp:member-ref>RequestedInputVolume</tp:member-ref> and
+          <tp:member-ref>RequestedOutputVolume</tp:member-ref> changing.</p>
+
+      <p>The maximum volume as used in this interface represent the unamplified
+         hardware volume (0 dB). No software amplification should be used to
+         boost the signal to a higher level when this Interface is in use</p>
+    </tp:docstring>
+
+    <property name="RequestedInputVolume" tp:type="Audio_Control_Volume"
+      type="i" access="read" tp:name-for-bindings="Requested_Input_Volume">
+      <tp:docstring>
+        The input volume as requested by the Connection Manager.
+        Initially and on any changes the client should change its input volume
+        to match the requested volume.
+      </tp:docstring>
+    </property>
+
+    <method name="ReportInputVolume" tp:name-for-bindings="Report_Input_Volume">
+      <arg direction="in" name="Volume" tp:type="Audio_Control_Volume" type="i">
+        <tp:docstring>
+          Report the input volume level as set by the client.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        <p>Report to the CM that the Content input volume has been
+          changed by the client.</p>
+
+        <p>It is the client's responsibility to change the input volume used for
+           the content. However, the client MUST call this whenever it changes
+           input volume for the content.</p>
+      </tp:docstring>
+    </method>
+
+    <property name="RequestedOutputVolume" tp:type="Audio_Control_Volume"
+      type="i" access="read" tp:name-for-bindings="Requested_Output_Volume">
+      <tp:docstring>
+        The input volume as requested by the Connection Manager.
+        Initially and on any changes the client should change its input volume
+        to match the requested volume.
+      </tp:docstring>
+    </property>
+
+    <method name="ReportOutputVolume"
+        tp:name-for-bindings="Report_Output_Volume">
+      <arg direction="in" name="Volume" tp:type="Audio_Control_Volume" type="i">
+        <tp:docstring>
+          Report the output volume level as set by the client.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        <p>Report to the CM that the content output volume has been
+          changed by the client.</p>
+
+        <p>It is the client's responsibility to change the output volume used
+           for the content. However, the client MUST call this whenever it
+           changes output volume for the content.</p>
+      </tp:docstring>
+    </method>
+
+  <tp:simple-type name="Audio_Control_Volume" type="i">
+    <tp:docstring>
+      <p>A volume value either reported to or requested by the Connection
+         Manager. This value should either be -1 for an unknown value or in the
+         range of 0-255, with 0 being the minimal volume and 255 being the
+         highest unamplified volume the input or output is capable of (known
+         as 0 dB)
+      </p>
+    </tp:docstring>
+  </tp:simple-type>
+  </interface>
+</node>
diff --git a/spec/Call_Content_Interface_Media.xml b/spec/Call_Content_Interface_Media.xml
index 038ce8c7..ca5ed36b 100644
--- a/spec/Call_Content_Interface_Media.xml
+++ b/spec/Call_Content_Interface_Media.xml
@@ -20,99 +20,116 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call.Content.Interface.Media.DRAFT"
+  <interface
+      name="org.freedesktop.Telepathy.Call1.Content.Interface.Media"
       tp:causes-havoc="experimental">
-    <tp:added version="0.19.0">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call.Content.DRAFT"/>
+    <tp:added version="0.23.4">(draft 2)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Call1.Content"/>
 
     <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
+        namespace="ofdT.Call1">Content</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>
+      <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
+        namespace="ofdT.Channel.Type">Call1</tp:dbus-ref> channel
+        appears (whether it was requested or not) a <tp:dbus-ref
+        namespace="ofdT.Call1.Content">MediaDescription</tp:dbus-ref>
+        object will either be waiting in the
+        <tp:member-ref>MediaDescriptionOffer</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>
+        <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> signal.</p>
+
+      <p>If nothing is known about the remote side's Media capabilities
+        (e.g. outgoing SIP/XMPP call), this <tp:dbus-ref namespace="ofdT.Call1.Content"
+        >MediaDescription</tp:dbus-ref> will pop up with {<tp:dbus-ref
+        namespace="ofdT.Call1.Content.MediaDescription"
+          >HasRemoteInformation</tp:dbus-ref> = false, <tp:dbus-ref
+        namespace="ofdT.Call1.Content.MediaDescription"
+          >FurtherNegotiationRequired</tp:dbus-ref> = true}, and the local
+        user's streaming implementation SHOULD call 
+        <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+        >Accept</tp:dbus-ref>,
+        with a description of all supported codecs and other features.
+        The CM will then send this information to the remote side (and
+        <tp:member-ref>LocalMediaDescriptionChanged</tp:member-ref> will fire
+        with details of the description passed into <tp:dbus-ref
+          namespace="ofdT.Call1.Content.MediaDescription"
+          >Accept</tp:dbus-ref> for debugging purposes).
+      </p>
+      <p>When the remote codecs and other content information are available
+        (e.g. Remote user replies to initial offer, or sends a new offer of
+        their own, a new <tp:dbus-ref namespace="ofdT.Call1.Content"
+         >MediaDescription</tp:dbus-ref> will appear, with {<tp:dbus-ref
+         namespace="ofdT.Call1.Content.MediaDescription"
+         >HasRemoteInformation</tp:dbus-ref> = true, <tp:dbus-ref
+        namespace="ofdT.Call1.Content.MediaDescription"
+          >FurtherNegotiationRequired</tp:dbus-ref> = false},
+        and the <tp:dbus-ref
+        namespace="ofdT.Call1.Content.MediaDescription"
+          >Codecs</tp:dbus-ref>
+        property on the description offer set to the codecs which are
+        supported by the remote contact. The local user's streaming
+        implementation SHOULD then call Accept, with a description
+        that is compatible with the one one in the offer. After the codec
+        set is accepted, both
+         <tp:member-ref>LocalMediaDescriptionChanged</tp:member-ref> and
+         <tp:member-ref>RemoteMediaDescriptionsChanged</tp:member-ref>
+        will fire to signal their respective changes, to aid with debugging.
+        Note that if <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+        >Accept</tp:dbus-ref> is called, with <tp:dbus-ref
+        namespace="ofdT.Call1.Content.MediaDescription"
+          >FurtherNegotiationRequired</tp:dbus-ref> set to false,
+        the CM should be able to rely on the fact that the
+        description passed into Accept is compatible with the one in the
+        offer, and the description passed into Accept will not be signalled to
+        the remote side.
+      </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>To update the codecs in the local (and optionally remote) media
+        descriptions mid-call, the
+        <tp:member-ref>UpdateLocalMediaDescription</tp:member-ref> method
+        should be called with details of the new codec list. If this is
+        accepted, then
+        <tp:member-ref>LocalMediaDescriptionChanged</tp:member-ref>
+        will be emitted with the new codec set.
+      </p>
+      <p> If parameters requiring negotiation are changed, then the
+        <tp:dbus-ref
+        namespace="ofdT.Call1.Content.MediaDescription"
+          >FurtherNegotiationRequired</tp:dbus-ref> property should be set to
+        TRUE, and the new media description should
+        only be used once they come in a new MediaDescriptionOffer
+      </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>
+        namespace="ofdT.Call1.Content">MediaDescription</tp:dbus-ref>
         object will appear through
-        <tp:member-ref>NewCodecOffer</tp:member-ref> which should be
+        <tp:member-ref>NewMediaDescriptionOffer</tp:member-ref> which should be
         acted on as documented above.</p>
 
+      <h4>Protocols without negotiation</h4>
+
+      <p>For protocols where the codecs are not negotiable, the initial content's <tp:dbus-ref
+        namespace="ofdT.Call1.Content">MediaDescription</tp:dbus-ref>
+        object will appear with <tp:dbus-ref
+        namespace="ofdT.Call1.Content.MediaDescription"
+          >HasRemoteInformation</tp:dbus-ref>,
+        set to true and the known supported codec values in <tp:dbus-ref
+        namespace="ofdT.Call1.Content.MediaDescription"
+          >Codecs</tp:dbus-ref>.
+      </p>
     </tp:docstring>
 
     <tp:struct name="Codec" array-name="Codec_List">
@@ -140,6 +157,23 @@
           Number of channels of the codec if applicable, otherwise 0.
         </tp:docstring>
       </tp:member>
+      <tp:member name="Updated" type="b">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          This should be set to true in calls to <tp:dbus-ref
+              namespace="ofdT.Call1.Content.MediaDescription"
+          >Accept</tp:dbus-ref> and
+          <tp:member-ref>UpdateLocalMediaDescription</tp:member-ref> if this
+          codec has changed in a way that needs to be signalled over the
+          network. If it is set to false, the CM is allowed ignore any
+          differences between the current parameters and the previous ones
+          <tp:rationale>
+            This mechanism may be used to save bandwidth and avoid the CM
+            having to calculate diffs against previous versions of this
+            struct, which can lead to false-positives (e.g. redundant ptime
+            updates).
+          </tp:rationale>
+        </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.
@@ -156,174 +190,279 @@
           A contact handle.
         </tp:docstring>
       </tp:member>
-      <tp:member name="Codecs" type="a(usuua{ss})" tp:type="Codec[]">
+      <tp:member name="Codecs" type="a(usuuba{ss})" tp:type="Codec[]">
         <tp:docstring>
           The codecs that the contact supports.
         </tp:docstring>
       </tp:member>
     </tp:mapping>
 
-    <tp:struct name="Codec_Offering">
+    <tp:mapping name="Contact_Media_Description_Properties_Map">
+      <tp:member name="Remote_Contact" type="u" tp:type="Handle">
+        <tp:docstring>
+          The remote contact this description refers to or 0. This matches the
+          <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+            >RemoteContact</tp:dbus-ref> property on
+          <tp:dbus-ref namespace="ofdT.Call1.Content"
+                    >MediaDescription</tp:dbus-ref>
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Media_Description_Properties" type="a{sv}"
+          tp:type="Media_Description_Properties">
+        <tp:docstring>
+          The properties of the description
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <tp:struct name="Media_Description_Offer">
       <tp:docstring>
-        A codec offer and its corresponding remote contact codec map.
+        The remote description offer and its information
       </tp:docstring>
-      <tp:member name="Codec_Offer" type="o">
+      <tp:member name="Media_Description" 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>
+          The object path to the <tp:dbus-ref namespace="ofdT.Call1.Content"
+          >MediaDescription</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.
+          The contact handle that this description 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:member name="Properties" type="a{sv}"
+           tp:type="Media_Description_Properties">
+        <tp:docstring>
+          The immutable properties of all interfaces of the codec description.
+
+          <tp:rationale>
+          Having all the codec description properties here saves a D-Bus
+          round-trip - it shouldn't be necessary to get the properties from the
+          MediaDescription object, in practice.
+          </tp:rationale>
         </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>
+    <method name="UpdateLocalMediaDescription"
+            tp:name-for-bindings="Update_Local_Media_Description">
+      <tp:docstring>
+        Update the local codec mapping and other interfaces of the
+        MediaDescription. This method should only be
+        used during an existing call to update the local media description.
+        This may trigger a re-negotiation which may result in new
+        new MediaDescriptionOffers if the "FurtherNegotiationRequired"
+        property is TRUE.
+        Otherwise, only parameters which strictly describe the media being sent
+        can be changed.
       </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[]">
+      <arg name="Remote_Contact" type="u" tp:type="Handle" direction="in">
         <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.
+          The remote contact that this description should be negotiated with
+          (or 0 to mean "negotiate this with everyone"). Note that encoding
+          the same video multiple times is often needlessly expensive, so
+          differences in MediaDescriptions negotiated with different parties
+          in the call should be limited to payloading parameters if possible.
         </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[]">
+      <arg name="MediaDescription" direction="in" type="a{sv}"
+           tp:type="Media_Description_Properties">
         <tp:docstring>
-          The codecs now supported by the local user.
+          The updated media description that the local side wants to use.
         </tp:docstring>
       </arg>
       <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
           <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.
+            The protocol does not support changing the codecs mid-call.
           </tp:docstring>
         </tp:error>
-      </tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The description given is invalid in some way.
+          </tp:docstring>
+        </tp:error>
+     </tp:possible-errors>
     </method>
 
-    <property name="ContactCodecMap" tp:name-for-bindings="Contact_Codec_Map"
-      type="a{ua(usuua{ss})}" tp:type="Contact_Codec_Map" access="read">
+    <property name="RemoteMediaDescriptions"
+        tp:name-for-bindings="Remote_Media_Descriptions"
+        type="a{ua{sv}}"
+        tp:type="Contact_Media_Description_Properties_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>
+        <p>A map from contact handles to descriptions supported by that
+          contact.</p>
+
+        <p>Keys of this map will appear in at most one <tp:dbus-ref
+          namespace="ofdT.Call1.Stream">RemoteMembers</tp:dbus-ref>.
+          See <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+          >RemoteContact</tp:dbus-ref> for more details on how to map between
+          MediaDescriptions and Streams.</p>
       </tp:docstring>
     </property>
 
-    <signal name="NewCodecOffer" tp:name-for-bindings="New_Codec_Offer">
+    <property name="LocalMediaDescriptions"
+        tp:name-for-bindings="Local_Media_Descriptions"
+        type="a{ua{sv}}"
+        tp:type="Contact_Media_Description_Properties_Map" access="read">
+      <tp:docstring>
+        <p>A map from contact handles to the descriptions the local side
+           responsed with.</p> </tp:docstring>
+    </property>
+
+    <signal name="NewMediaDescriptionOffer"
+        tp:name-for-bindings="New_Media_Description_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"
+        <p>Emitted when a new <tp:dbus-ref namespace="ofdT.Call1.Content"
+          >MediaDescription</tp:dbus-ref> appears. The streaming
+          >implementation MUST respond by calling the
+          <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
           >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>
+          namespace="ofdT.Call1.Content.MediaDescription"
+          >Reject</tp:dbus-ref> method on the description object appeared.</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:member-ref>MediaDescriptionOffer</tp:member-ref> property has
+          changed to
+            <code>(Description, Contact, MediaDescriptionProperties)</code>.</p>
+
+        <p>When the MediaDescriptionOffer has been dealt with then
+          <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+            >MediaDescriptionOfferDone</tp:dbus-ref> must be emitted
+          before <tp:dbus-ref
+            namespace="ofdT.Call1.Content.Interface.Media"
+              >NewMediaDescriptionOffer</tp:dbus-ref> is emitted again.
+        </p>
+
       </tp:docstring>
+      <arg name="Media_Description" type="o">
+        <tp:docstring>
+          The object path of the new media description. This replaces any
+          previous media description.
+        </tp:docstring>
+      </arg>
       <arg name="Contact" type="u">
         <tp:docstring>
-          The contact the codec offer belongs to.
+          The remote contact the media description belongs to.
         </tp:docstring>
       </arg>
-      <arg name="Offer" type="o">
+      <arg name="Properties" type="a{sv}"
+           tp:type="Media_Description_Properties">
+        <tp:docstring>
+          The immutable properties of the remote media description.
+
+          <tp:rationale>
+          Having all the MediaDescription properties here saves a D-Bus
+          round-trip - it shouldn't be necessary to get the properties from the
+          MediaDescription object, in practice.
+          </tp:rationale>
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <signal name="MediaDescriptionOfferDone"
+        tp:name-for-bindings="Media_Description_Offer_Done">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when a <tp:dbus-ref namespace="ofdT.Call1.Content"
+          >MediaDescription</tp:dbus-ref> has been handled. </p>
+        <p>Emission of this signal indicates that the
+          <tp:member-ref>MediaDescriptionOffer</tp:member-ref> property has
+          changed to
+            <code>("/", 0, {})</code>.</p>
+      </tp:docstring>
+    </signal>
+
+
+    <signal name="LocalMediaDescriptionChanged"
+      tp:name-for-bindings="Local_Media_Description_Changed">
+
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Change notification for
+            <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+              >LocalMediaDescriptions</tp:dbus-ref>
+        </p>
+      </tp:docstring>
+
+      <arg name="Remote_Contact" type="u" tp:type="Handle">
         <tp:docstring>
-          The object path of the new codec offer. This replaces any previous
-          codec offer.
+          The remote contact that this description was negotiated with
+          (or 0 to mean "negotiated with everyone").
         </tp:docstring>
       </arg>
-      <arg name="Codecs" type="a(usuua{ss})" tp:type="Codec[]">
+
+      <arg name="Updated_Media_Description" type="a{sv}"
+        tp:type="Media_Description_Properties">
         <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>
+          <p>The local content description that was updated</p>
+        </tp:docstring>
+      </arg>
+    </signal>
 
-        <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>
+    <signal name="RemoteMediaDescriptionsChanged"
+      tp:name-for-bindings="Remote_Media_Descriptions_Changed">
+
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Change notification for
+            <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+              >RemoteMediaDescriptions</tp:dbus-ref>
+        </p>
+      </tp:docstring>
+
+      <arg name="Updated_Media_Descriptions" type="a{ua{sv}}"
+          tp:type="Contact_Media_Description_Properties_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The remote content descriptions that were updated</p>
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <signal name="MediaDescriptionsRemoved"
+      tp:name-for-bindings="Media_Descriptions_Removed">
+
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Removal notification for
+            <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+              >RemoteMediaDescriptions</tp:dbus-ref>
+            and
+            <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+              >LocalMediaDescriptions</tp:dbus-ref>
+        </p>
+      </tp:docstring>
+
+      <arg name="Removed_Media_Descriptions" type="au"
+          tp:type="Contact_Handle[]">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The local and remote content descriptions that are no longer part
+             of this content</p>
         </tp:docstring>
       </arg>
     </signal>
 
-    <property name="CodecOffer" tp:name-for-bindings="Codec_Offer"
-      type="(oua(usuua{ss}))" tp:type="Codec_Offering" access="read">
+    <property name="MediaDescriptionOffer"
+        tp:name-for-bindings="Media_Description_Offer"
+      type="(oua{sv})" tp:type="Media_Description_Offer" 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.
+          <tp:dbus-ref namespace="ofdT.Call1.Content"
+           >MediaDescription</tp:dbus-ref> object, its
+            <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+            >RemoteContact</tp:dbus-ref> and
+            a mapping of the MediaDescriptions properties.
             If the object path is "/" then there isn't an outstanding
-            codec offer, and the mapping MUST be empty.</p>
+            content description, 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>
+          Having all <tp:dbus-ref
+          namespace="ofdT.Call1.Content">MediaDescription</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.
+          necessary to get these properties from the Content MediaDescription
+          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:member-ref>NewMediaDescriptionOffer</tp:member-ref> and
+          <tp:member-ref>MediaDescriptionOfferDone</tp:member-ref> signals.
+         </p>
       </tp:docstring>
     </property>
 
@@ -362,6 +501,81 @@
         <p>The packetization method in use for this content.</p>
       </tp:docstring>
     </property>
+
+    <signal name="DTMFChangeRequested"
+      tp:name-for-bindings="DTMF_Change_Requested">
+      <tp:docstring>
+        Used by the CM to relay instructions from <tp:dbus-ref
+        namespace="ofdT">Channel.Interface.DTMF</tp:dbus-ref> to the streaming
+        implementation. If any contact in this call supports the
+        telephone-event codec in their MediaDescription, this event should be
+        sent as outlined in RFC 4733. Otherwise, it should be sent as an
+        audible tone.
+      </tp:docstring>
+      <arg name="Event" type="y" tp:type="DTMF_Event">
+        <tp:docstring>
+          The event to send (or stop sending).
+        </tp:docstring>
+      </arg>
+      <arg name="State" type="u" tp:type="Sending_State">
+        <tp:docstring>
+          Either <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> or
+          <tp:value-ref type="Sending_State">Pending_Stop_Sending</tp:value-ref>.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <method name="AcknowledgeDTMFChange"
+      tp:name-for-bindings="Acknowledge_DTMF_Change">
+      <tp:docstring>
+        Called by the streaming implementation in response to
+        <tp:member-ref>DTMFChangeRequested</tp:member-ref> to confirm that it
+        has started or stopped sending the event in question.
+      </tp:docstring>
+      <arg name="Event" type="y" tp:type="DTMF_Event" direction="in">
+        <tp:docstring>
+          The event referred to in the corresponding
+          <tp:member-ref>DTMFChangeRequested</tp:member-ref> signal.
+        </tp:docstring>
+      </arg>
+      <arg name="State" type="u" tp:type="Sending_State" direction="in">
+        <tp:docstring>
+          Either <tp:value-ref type="Sending_State">Sending</tp:value-ref> or
+          <tp:value-ref type="Sending_State">None</tp:value-ref>.
+        </tp:docstring>
+      </arg>
+    </method>
+
+    <property name="CurrentDTMFEvent"
+      tp:name-for-bindings="Current_DTMF_Event" type="y" tp:type="DTMF_Event"
+      access="read">
+      <tp:docstring>
+        The currently requested DTMF event (for state-recoverability of
+        <tp:member-ref>DTMFChangeRequested</tp:member-ref>). Should be ignored
+        if <tp:member-ref>CurrentDTMFState</tp:member-ref> is None.
+      </tp:docstring>
+    </property>
+
+    <property name="CurrentDTMFState"
+      tp:name-for-bindings="Current_DTMF_State" type="u" tp:type="Sending_State"
+      access="read">
+      <tp:docstring>
+        The current DTMF state (for state-recoverability of
+        <tp:member-ref>DTMFChangeRequested</tp:member-ref>).
+      </tp:docstring>
+    </property>
+
+    <method name="Fail" tp:name-for-bindings="Fail">
+      <tp:docstring>
+        Signal an unrecoverable error for this content, and remove it.
+      </tp:docstring>
+      <arg direction="in" name="Reason" type="(uuss)"
+        tp:type="Call_State_Reason">
+        <tp:docstring>
+          A reason struct describing the error.
+        </tp:docstring>
+      </arg>
+    </method>
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Content_Interface_Video_Control.xml b/spec/Call_Content_Interface_Video_Control.xml
index b066de42..086d4758 100644
--- a/spec/Call_Content_Interface_Video_Control.xml
+++ b/spec/Call_Content_Interface_Video_Control.xml
@@ -1,8 +1,7 @@
 <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
 <node name="/Call_Content_Interface_Video_Control"
   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:copyright>Copyright © 2011 Collabora Ltd.</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
@@ -20,10 +19,10 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call.Content.Interface.VideoControl.DRAFT"
+  <interface name="org.freedesktop.Telepathy.Call1.Content.Interface.VideoControl"
     tp:causes-havoc="experimental">
     <tp:added version="0.21.10">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call.Content.Interface.Media.DRAFT"/>
+    <tp:requires interface="org.freedesktop.Telepathy.Call1.Content.Interface.Media"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface that allows the connection manager to control the video
diff --git a/spec/Call_Content_Media_Description.xml b/spec/Call_Content_Media_Description.xml
new file mode 100644
index 00000000..7c494a41
--- /dev/null
+++ b/spec/Call_Content_Media_Description.xml
@@ -0,0 +1,236 @@
+<?xml version="1.0" ?>
+<node name="/Call_Content_Media_Description"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright © 2009-2010 Collabora Ltd.</tp:copyright>
+  <tp:copyright>Copyright © 2009-2010 Nokia Corporation</tp:copyright>
+  <tp:license xmlns="http://www.w3.org/1999/xhtml">
+    <p>This library is free software; you can redistribute it and/or
+      modify it under the terms of the GNU Lesser General Public
+      License as published by the Free Software Foundation; either
+      version 2.1 of the License, or (at your option) any later version.</p>
+
+    <p>This library is distributed in the hope that it will be useful,
+      but WITHOUT ANY WARRANTY; without even the implied warranty of
+      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+      Lesser General Public License for more details.</p>
+
+    <p>You should have received a copy of the GNU Lesser General Public
+      License along with this library; if not, write to the Free Software
+      Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+      02110-1301, USA.</p>
+  </tp:license>
+
+  <interface name="org.freedesktop.Telepathy.Call1.Content.MediaDescription"
+      tp:causes-havoc="experimental">
+    <tp:added version="0.23.4">(draft 1)</tp:added>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      This object represents a remote Description Offer to which the local
+      streaming implementation should reply with its local Description.
+
+      This is intended as a temporary transactional object for use with <tp:dbus-ref
+          namespace="ofdT.Call1">Content.Interface.Media</tp:dbus-ref>.
+      There will always be 0 or 1 MediaDescription object per Content.
+      In most cases, this object will stay alive until you call either
+      <tp:member-ref>Accept</tp:member-ref> or
+      <tp:member-ref>Reject</tp:member-ref>, and then disappear.
+      There are some cases (e.g. an endpoint being removed from the call)
+      where a MediaDescription object will disappear before you have had a
+      chance to either Accept or Reject it.
+    </tp:docstring>
+
+    <method name="Accept" tp:name-for-bindings="Accept">
+      <arg name="Local_Media_Description" direction="in"
+        type="a{sv}" tp:type="Media_Description_Properties">
+        <tp:docstring>
+          The local description to send to the remote contacts and
+          to use in the <tp:dbus-ref
+          namespace="ofdT.Call1">Content</tp:dbus-ref>.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        Accepts the updated Description and update the corresponding
+        local description. If FurtherNegotiationRequired is True,
+        calling this method will generally cause a network round-trip
+        and a new MediaDescription to be offered (hopefully with
+        FurtherNegotiationRequired set to False).
+      </tp:docstring>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The description given is invalid in some way.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="Reject" tp:name-for-bindings="Reject">
+      <tp:docstring>
+        Reject the proposed update to the remote description.
+      </tp:docstring>
+      <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason"
+        direction="out">
+        <tp:docstring>
+          A structured reason for the rejection.
+        </tp:docstring>
+      </arg>
+    </method>
+
+    <property name="Interfaces" tp:name-for-bindings="Interfaces"
+      type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Extra interfaces provided by this media description. This SHOULD
+          NOT include the Description interface itself.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="FurtherNegotiationRequired"
+      tp:name-for-bindings="Further_Negotiation_Required" type="b"
+      access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml" >
+        <p> If this is set to True by the CM in a MediaDescriptionOffer, it
+          means "This is an offer under the SDP Offer/Answer model. Whatever
+          you accept this offer with is what I will send to the other side in
+          my answer."
+
+          If this is set to False by the CM then it means "This is an Answer
+          under the SDP Offer/Answer model, and if it remains False in the
+          Accept(), no further codec negotiation needs to happen."
+
+          If this is set to True by the streaming implementation (e.g. in an
+          Accept or UpdateLocalMediaDescription call) then a new SDP
+          Offer/Answer round-trip will be initiated.
+        </p>
+      </tp:docstring>
+    </property>
+
+    <property name="HasRemoteInformation"
+      tp:name-for-bindings="Has_Remote_Information" type="b"
+      access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml" >
+        <p> True if this offer contains information from the remote side:
+            If False then the Accept response solely depends on the
+            capabilities and preferences of the local side.
+
+            In most protocols this property will be False for the initial
+            DescriptionOffer on an outgoing call.
+        </p>
+      </tp:docstring>
+    </property>
+
+    <property name="Codecs"
+      tp:name-for-bindings="Codecs"
+      type="a(usuuba{ss})" tp:type="Codec[]" access="read"
+      tp:immutable="yes">
+      <tp:docstring>
+        A list of codecs the remote contact supports. When used with
+        <tp:member-ref>Accept</tp:member-ref>, it means the locally supported
+        codecs.
+      </tp:docstring>
+    </property>
+
+    <property name="RemoteContact" tp:name-for-bindings="Remote_Contact"
+      type="u" tp:type="Contact_Handle" access="read" tp:immutable="yes">
+      <tp:docstring>
+        The contact handle that this description applies to.
+
+        This property can be used as an opaque identifier, and searched for in
+        <tp:dbus-ref namespace="ofdT.Call1.Stream"
+        >RemoteMembers</tp:dbus-ref> for each Stream in this Content, to
+        determine which Stream this MediaDescription applies to. If multiple
+        MediaDescriptions apply to the same Stream, the
+        <tp:member-ref>SSRCs</tp:member-ref> property should be used to
+        separate media before decoding.
+
+        If this property is 0, this MediaDescription applies to all streams,
+        so the above matching method is unneccesary (e.g. in conference calls
+        with a mixer, media from all participants is mixed into one stream).
+
+        When calling Accept or UpdateLocalMediaDescription, this should always
+        be set to 0, or omitted, because it is assumed that you send the same
+        MediaDescription to everyone (Encoding a stream separately for each
+        contact in a call is inefficient, and should be avoided).
+      </tp:docstring>
+    </property>
+
+    <tp:mapping name="Contact_SSRCs_Map">
+      <tp:member name="Contact" type="u" tp:type="Handle">
+        <tp:docstring>
+          The remote contact these SSRCs belong to or 0.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="SSRCs" type="au">
+        <tp:docstring>
+          The list of Synchronisation Sources.
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <property name="SSRCs" tp:name-for-bindings="SSRCs"
+      type="a{uau}" tp:type="Contact_SSRCs_Map" access="read" tp:immutable="yes">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A map from Handle to list of Synchronisation Sources, as defined by
+        RFC 3550.</p>
+
+        <p>Some protocols require the negotiation of SSRC identifiers for RTP
+        streams. If this is the case, then MediaDescription offers will appear
+        with this property set. The streaming implementation should then call
+        <tp:member-ref>Accept</tp:member-ref> with a map from 0 to a
+        list containing a single SSRC (which does not collide with these,
+        or any previously seen SSRCs). If a new MediaDescription offer
+        appears with an SSRC the same as one in <tp:dbus-ref
+        namespace="ofdT.Call1.Content.Interface.Media"
+        >LocalMediaDescriptions</tp:dbus-ref>, then the streaming
+        implementation should pick a new SSRC to resolve the collision.</p>
+
+        <p>It is expected that this list will normally be at most one element long,
+        but it is kept as a list for extensibility. The concatenation of all
+        SSRCs associated with a Stream should contain no duplicate entries. If
+        there are collisions, then it is the responsibility of the protocol
+        implementation to resolve them and generate new offers.</p>
+
+        <p>If this property is omitted, then the streaming implementation can
+        assume that there is only one MediaDescription per Stream.</p>
+
+        <p>If there is a single multicast Call Stream with multiple
+        Remote Members, and all members are forced to use the same
+        MediaDescription, this map can be used by the streaming implementation
+        to determine which video sources belong to which contacts (e.g. in
+        order to put a name under each face in the call)</p>
+      </tp:docstring>
+    </property>
+
+    <tp:mapping name="Media_Description_Properties">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>
+          A mapping containing all properties that define the information from a
+          <tp:dbus-ref
+            namespace="ofdT.Call1.Content"
+            >MediaDescription</tp:dbus-ref> and its interfaces.
+        </p>
+
+        <p>
+          If <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+            >HasRemoteInformation</tp:dbus-ref> is True, then this mapping
+          will always contains at least
+          <tp:dbus-ref namespace="ofdT.Call1.Content.MediaDescription"
+            >Codecs</tp:dbus-ref>
+        </p>
+      </tp:docstring>
+
+      <tp:member name="Media_Description_Property"
+        type="s" tp:type="DBus_Qualified_Member">
+        <tp:docstring>
+          A D-Bus interface name, followed by a dot and a D-Bus property name.
+        </tp:docstring>
+      </tp:member>
+      <tp:member name="Media_Description_Property_Value" type="v">
+        <tp:docstring>
+          The value of the property
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Content_Media_Description_Interface_RTCP_Extended_Reports.xml b/spec/Call_Content_Media_Description_Interface_RTCP_Extended_Reports.xml
new file mode 100644
index 00000000..f973306c
--- /dev/null
+++ b/spec/Call_Content_Media_Description_Interface_RTCP_Extended_Reports.xml
@@ -0,0 +1,145 @@
+<?xml version="1.0" ?>
+<node name="/Call_Content_Media_Description_Interface_RTCP_Extended_Reports" 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.Call1.Content.MediaDescription.Interface.RTCPExtendedReports"
+    tp:causes-havoc="experimental">
+    <tp:added version="0.23.4">(draft version, not API-stable)</tp:added>
+    <tp:requires
+    interface="org.freedesktop.Telepathy.Call1.Content.MediaDescription"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This codec offer interface provides a method of signalling for
+        RTCP extended reports, documented by <em>RTP Control Protocol
+        Extended Reports (RTCP XR)</em> (RFC 3611). CMs should ignore
+        all RTCP Extended Report parameters that are not listed
+        in this spec at the time of implementation. More parameters can be
+        added to the spec as required.</p>
+
+      <p>For more details on what RTCP extended reports can do and how
+        to use them, one should refer to
+        <a href="http://www.faqs.org/rfcs/rfc3611.html">RFC 3611</a>.</p>
+
+    </tp:docstring>
+
+    <property access="read" type="u" name="LossRLEMaxSize" tp:name-for-bindings="Loss_RLE_Max_Size">
+      <tp:docstring>
+        If non-zero, enable Loss Run Length Encoded Report Blocks. The value
+        of this integer represents the max-size of report blocks, as specified
+        in RFC 3611 section 5.1. MAXUINT32 is used to indicate that there is
+        no limit.
+      </tp:docstring>
+    </property>
+    <property access="read" type="u" name="DuplicateRLEMaxSize" tp:name-for-bindings="Duplicate_RLE_Max_Size">
+      <tp:docstring>
+        If non-zero, enable Duplicate Run-Length-Encoded Report Blocks. The
+        value of this integer represents the max-size of report blocks, as
+        specified in RFC 3611 section 5.1. MAXUINT32 is used to indicate that
+        there is no limit.
+      </tp:docstring>
+    </property>
+    <property access="read" type="u" name="PacketReceiptTimesMaxSize" tp:name-for-bindings="Packet_Receipt_Times_Max_Size">
+      <tp:docstring>
+        If non-zero, enable Packet Receipt Times Report Blocks. The
+        value of this integer represents the max-size of report blocks, as
+        specified in RFC 3611 section 5.1. MAXUINT32 is used to indicate that
+        there is no limit.
+      </tp:docstring>
+    </property>
+    <property access="read" type="u" name="DLRRMaxSize" tp:name-for-bindings="DLRR_Max_Size">
+      <tp:docstring>
+        If non-zero, enable Receiver Reference Time and Delay since Last
+        Receiver Report Blocks (for estimating Round Trip Times between
+        non-senders and other parties in the call. The value of this integer
+        represents the max-size of report blocks, as specified in RFC 3611
+        section 5.1. MAXUINT32 is used to indicate that there is no limit.
+      </tp:docstring>
+    </property>
+    <property access="read" type="u" tp:type="RCPT_XR_RTT_Mode"
+      name="RTTMode" tp:name-for-bindings="RTT_Mode">
+      <tp:docstring>
+        Who is allowed to send Delay since Last Receiver Reports.
+      </tp:docstring>
+    </property>
+
+    <property access="read" type="u" tp:type="RTCP_XR_Statistics_Flags"
+      name="StatisticsFlags" tp:name-for-bindings="Statistics_Flags">
+      <tp:docstring>
+        Which fields SHOULD be included in the statistics summary
+        report blocks that are sent, and whether to send VoIP Metrics Report
+        Blocks. There can be zero or more flags
+        set.
+      </tp:docstring>
+    </property>
+
+    <property access="read" type="b" name="EnableMetrics" tp:name-for-bindings="Enable_Metrics">
+      <tp:docstring>
+        Whether to enable VoIP Metrics Report Blocks. These blocks are of a
+        fixed size.
+      </tp:docstring>
+    </property>
+
+    <tp:flags name="RTCP_XR_Statistics_Flags" type="u">
+      <tp:flag suffix="Loss" value="1">
+        <tp:docstring>
+          Loss report flag, as defined in RFC3611 section 4.6.
+        </tp:docstring>
+      </tp:flag>
+      <tp:flag suffix="Duplicate" value="2">
+        <tp:docstring>
+          Duplicate report flag, as defined in RFC3611 section 4.6.
+        </tp:docstring>
+      </tp:flag>
+      <tp:flag suffix="Jitter" value="4">
+        <tp:docstring>
+          Jitter flag, as defined in RFC3611 section 4.6.
+        </tp:docstring>
+      </tp:flag>
+      <tp:flag suffix="TTL" value="8">
+        <tp:docstring>
+          First bit of TTL or Hop Limit flag, as defined in RFC3611 section
+          4.6.
+        </tp:docstring>
+      </tp:flag>
+      <tp:flag suffix="HL" value="16">
+        <tp:docstring>
+          Second bit of TTL or Hop Limit flag, as defined in RFC3611 section
+          4.6.
+        </tp:docstring>
+      </tp:flag>
+    </tp:flags>
+
+    <tp:enum name="RCPT_XR_RTT_Mode" type="u">
+      <tp:enumvalue suffix="All" value="0">
+        <tp:docstring>
+          Both RTP data senders and data receivers MAY send DLRR
+          blocks.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Sender" value="1">
+        <tp:docstring>
+          Only active RTP senders MAY send DLRR blocks, i.e., non RTP
+          senders SHALL NOT send DLRR blocks.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Content_Media_Description_Interface_RTCP_Feedback.xml b/spec/Call_Content_Media_Description_Interface_RTCP_Feedback.xml
new file mode 100644
index 00000000..f586fe4c
--- /dev/null
+++ b/spec/Call_Content_Media_Description_Interface_RTCP_Feedback.xml
@@ -0,0 +1,61 @@
+<?xml version="1.0" ?>
+<node name="/Call_Content_Media_Description_Interface_RTCP_Feedback" 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.Call1.Content.MediaDescription.Interface.RTCPFeedback"
+    tp:causes-havoc="experimental">
+    <tp:added version="0.23.4">(draft version, not API-stable)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Call1.Content.MediaDescription"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This codec offer interface provides a method of signalling
+        support for RTCP feedback, documented by <em>Extended RTP
+        Profile for Real-time Transport Control Protocol (RTCP)-Based
+        Feedback (RTP/AVPF)</em> (RFC 4585).</p>
+
+      <p>The codec identifiers used in the description of the Feedback Messages
+      sent in the <tp:dbus-ref
+        namespace="ofdT.Call1.Content.MediaDescription">Accept</tp:dbus-ref>'s
+      should match those used for the RemoteCodecs in the same Accept call.
+      </p>
+
+      <p>For more details on what RTCP Feedback can do and how to use
+        it, one should refer to
+        <a href="http://www.faqs.org/rfcs/rfc4585.html">RFC 4585</a>.</p>
+
+    </tp:docstring>
+
+    <property name="FeedbackMessages" type="a{u(ua(sss))}"
+      tp:type="RTCP_Feedback_Message_Map"
+      access="read" tp:name-for-bindings="Feedback_Messages">
+      <tp:docstring>
+        A map of remote feedback codec properties that are supported.
+      </tp:docstring>
+    </property>
+
+    <property name="DoesAVPF" type="b"
+      access="read" tp:name-for-bindings="Does_AVPF">
+      <tp:docstring>
+        True if the remote contact supports Audio-Visual Profile
+        Feedback (AVPF), otherwise False.
+      </tp:docstring>
+    </property>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Content_Media_Description_Interface_RTP_Header_Extensions.xml b/spec/Call_Content_Media_Description_Interface_RTP_Header_Extensions.xml
new file mode 100644
index 00000000..a35615ad
--- /dev/null
+++ b/spec/Call_Content_Media_Description_Interface_RTP_Header_Extensions.xml
@@ -0,0 +1,73 @@
+<?xml version="1.0" ?>
+<node name="/Call_Content_Media_Description_Interface_RTP_Header_Extensions" 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.Call1.Content.MediaDescription.Interface.RTPHeaderExtensions"
+    tp:causes-havoc="experimental">
+    <tp:added version="0.23.4">(draft version, not API-stable)</tp:added>
+    <tp:requires interface="org.freedesktop.Telepathy.Call1.Content.MediaDescription"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This media description interface provides a method of signalling
+        support for RTP Header Extensions, documented by
+        <em>A General Mechanism for RTP Header Extensions (RFC 5285)</em>.</p>
+
+      <p>For more details on the General Mechanism for RTP Header Extensions
+         and how to use them, one should refer to
+        <a href="http://www.faqs.org/rfcs/rfc5285.html">RFC 5285</a>.</p>
+
+    </tp:docstring>
+
+    <tp:struct name="RTP_Header_Extension"
+      array-name="RTP_Header_Extensions_List">
+      <tp:docstring>
+        A struct defining a RTP Header extension.
+      </tp:docstring>
+      <tp:member type="u" name="ID">
+        <tp:docstring>
+          Identifier to be negotiated.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="u" tp:type="Media_Stream_Direction"  name="Direction">
+        <tp:docstring>
+          Direction in which the Header Extension is negotiated.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="s" name="URI">
+        <tp:docstring>
+          URI defining the extension.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="s" name="Parameters">
+        <tp:docstring>
+          Feedback parameters as a string. Format is defined in the relevant RFC.
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <property name="HeaderExtensions" type="a(uuss)"
+      tp:type="RTP_Header_Extension[]"
+      access="read" tp:name-for-bindings="Header_Extensions">
+      <tp:docstring>
+        A list of remote header extensions which are supported.
+      </tp:docstring>
+    </property>
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Call_Interface_Mute.xml b/spec/Call_Interface_Mute.xml
new file mode 100644
index 00000000..1202383f
--- /dev/null
+++ b/spec/Call_Interface_Mute.xml
@@ -0,0 +1,146 @@
+<?xml version="1.0" ?>
+<node name="/Call_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.Call1.Interface.Mute" tp:causes-havoc="experimental">
+    <tp:added version="0.19.6">(draft version, not API-stable)</tp:added>
+    <tp:xor-requires>
+      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call1"/>
+      <tp:requires interface="org.freedesktop.Telepathy.Call1.Content"/>
+      <tp:requires interface="org.freedesktop.Telepathy.Call1.Stream"/>
+    </tp:xor-requires>
+
+    <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>It should always be possible to mute an entire call. It is sometimes
+        also possible to mute individual Contents (e.g. to prevent background
+        noise from disturbing other participants, but remain visible on
+        webcam) or to mute individual streams (e.g. to "whisper" to other call
+        participants)</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>
+
+    <tp:enum name="Local_Mute_State" type="u">
+      <tp:docstring>
+        The mute state of (at least part of) the call. See
+        <tp:member-ref>LocalMuteState</tp:member-ref> for more details.
+      </tp:docstring>
+
+      <tp:enumvalue value="0" suffix="Unmuted">
+        <tp:docstring>
+          All streams are unmuted (the call is active). New channels SHOULD
+          have this mute state.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue value="1" suffix="Muted">
+        <tp:docstring>
+          All streams are Muted.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue value="2" suffix="Pending_Mute">
+        <tp:docstring>
+          The connection manager is attempting to move to state Muted, but
+          has not yet completed that operation. It is unspecified whether
+          any, all or none of the streams making up the channel are muted.
+          Examining the Mute state of Call Contents (if applicable) may
+          provide more useful information.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue value="3" suffix="Pending_Unmute">
+        <tp:docstring>
+          The connection manager is attempting to move to state Unmuted, but
+          has not yet completed that operation. It is unspecified whether
+          any, all or none of the streams making up the channel are muted.
+          Examining the Mute state of Call Contents or Streams may
+          provide more useful information.
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue value="4" suffix="Partially_Muted">
+        <tp:docstring>
+          Some of the constituent Streams are Muted. This state only makes
+          sense on Call Channels or Contents.
+          Examining the Mute state of Call Contents or Streams should
+          provide more useful information.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <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>RequestMuted</tp:member-ref>, or as an indication that another
+        client has (un)muted the content.
+      </tp:docstring>
+      <arg name="MuteState" type="u" tp:type="Local_Mute_State">
+        <tp:docstring>
+          The new mute state.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <property name="LocalMuteState" type="u" tp:type="Local_Mute_State"
+      access="read" tp:name-for-bindings="Local_Mute_State">
+      <tp:docstring>
+        The current mute state of this part of the call. New
+        <tp:dbus-ref namespace="ofdT.Call1">Content</tp:dbus-ref>s should
+        inherit the value of this property from the parent
+        <tp:dbus-ref namespace="ofdT.Channel.Type">Call1</tp:dbus-ref>.
+        Similarly, <tp:dbus-ref namespace="ofdT.Call1">Stream</tp:dbus-ref>s
+        should inherit it from the parent <tp:dbus-ref
+        namespace="ofdT.Call1">Content</tp:dbus-ref>.
+      </tp:docstring>
+    </property>
+
+    <method name="RequestMuted" tp:name-for-bindings="Request_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 wishes to mute the Content or Call.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        <p>Inform the CM that the Call, Content or Stream should be muted or
+          unmuted.</p>
+
+        <p>The CM will tell the streaming implementation to Mute Streams as
+          required, and emit <tp:member-ref>MuteStateChanged</tp:member-ref>
+          when done.</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
index 1d7b2814..b8b347d4 100644
--- a/spec/Call_Stream.xml
+++ b/spec/Call_Stream.xml
@@ -20,13 +20,19 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call.Stream.DRAFT"
+  <interface name="org.freedesktop.Telepathy.Call1.Stream"
       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>.
+      <p>One stream inside a <tp:dbus-ref
+      namespace="ofdT.Call1">Content</tp:dbus-ref>.  A stream is
+      a single flow of packets to and from a single remote endpoint.
+      If your call connects to multiple people, you could have
+      multiple streams.</p>
+      <p>For protocols that support muting streams separately, this object MAY
+      also implement the <tp:dbus-ref
+      namespace="ofdT.Call1.Interface">Mute</tp:dbus-ref> interface</p>
     </tp:docstring>
 
     <method name="SetSending" tp:name-for-bindings="Set_Sending">
@@ -39,18 +45,24 @@
         <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
+            change to <tp:value-ref type="Sending_State">Sending</tp:value-ref>, 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
+            change to <tp:value-ref type="Sending_State">None</tp:value-ref>, if it isn't
             already.</p>
         </tp:docstring>
       </arg>
 
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented" />
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYet">
+          <tp:docstring>If the call has not been accepted yet, calling
+            SetSending(True) is an error. See
+            <tp:member-ref>LocalSendingState</tp:member-ref> for details.
+          </tp:docstring>
+        </tp:error>
       </tp:possible-errors>
     </method>
 
@@ -109,6 +121,11 @@
           and the members whose states changed.
         </tp:docstring>
       </arg>
+      <arg name="Identifiers" type="a{us}" tp:type="Handle_Identifier_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The identifiers of the contacts in the <var>Updates</var> map.
+        </tp:docstring>
+      </arg>
       <arg name="Removed" type="au" tp:type="Contact_Handle[]">
         <tp:docstring>
           The channel-specific handles that were removed from the keys
@@ -116,6 +133,11 @@
           property, as a result of the contact leaving this stream
         </tp:docstring>
       </arg>
+      <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason">
+        <tp:docstring>
+          A structured reason for the change.
+        </tp:docstring>
+      </arg>
     </signal>
 
     <signal name="LocalSendingStateChanged"
@@ -130,6 +152,12 @@
           <tp:member-ref>LocalSendingState</tp:member-ref>.
         </tp:docstring>
       </arg>
+
+      <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason">
+        <tp:docstring>
+          A structured reason for the change.
+        </tp:docstring>
+      </arg>
     </signal>
 
     <tp:enum name="Sending_State" type="u">
@@ -184,7 +212,7 @@
       <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>.
+            namespace="ofdT.Call1">Stream.Interface.Media</tp:dbus-ref>.
           This SHOULD NOT include the Stream interface itself, and cannot
           change once the stream has been created.</p>
       </tp:docstring>
@@ -194,18 +222,38 @@
         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>
+        <p>A map from remote contacts to their sending state.</p>
+
+        <p>Media sent to this stream will be sent to all members listed here.
+          All members listed here will also appear in <tp:dbus-ref
+          namespace="ofdT.Channel.Type.Call1">CallMembers</tp:dbus-ref>,
+          and each CallMembers member will be listed in at most one Stream per
+          Content. Therefore, to hide things from a member of the
+          call, UIs only need to mute one Stream per Content.</p>
+
+        <p>Contacts' handles in this map indicate whether they are
+          sending media to this stream. Sending_State_Pending_Send indicates
+          contacts who are not sending but have been asked to do so. The
+          local user's sending state is shown in <tp:member-ref
+          >LocalSendingState</tp:member-ref>.</p>
+
+        <p>This mapping is also used by the streaming implementation to map
+          from <tp:dbus-ref namespace="ofdT.Call1.Content"
+          >MediaDescription</tp:dbus-ref>s to Streams. In this use-case,
+          all of the senders in this stream will be represented in
+          <tp:dbus-ref namespace="ofdT.Call1.Content.Interface.Media"
+          >RemoteMediaDescriptions</tp:dbus-ref>. This use-case should not
+          affect anything that does not handle media streaming.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="RemoteMemberIdentifiers" type="a{us}" tp:type="Handle_Identifier_Map"
+      access="read" tp:name-for-bindings="Remote_Member_Identifiers">
+      <tp:docstring>
+        The string identifiers for handles mentioned in
+        <tp:member-ref>RemoteMembers</tp:member-ref>, to
+        give clients the minimal information necessary to create contacts
+        without waiting for round-trips.
       </tp:docstring>
     </property>
 
@@ -228,20 +276,20 @@
           special-cased.
         </tp:rationale>
 
-        <p>A value of <tp:type>Sending_State</tp:type>_Pending_Send for
+        <p>A value of <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> 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>
+          local user start sending media (which can be done by calling either
+          <tp:member-ref>SetSending</tp:member-ref> or <tp:dbus-ref
+          namespace="ofdT.Channel.Type.Call1">Accept</tp:dbus-ref>).</p>
+
+        <p>When <tp:dbus-ref
+          namespace="ofdT.Channel.Type.Call1">Accept</tp:dbus-ref> is
+          called, all streams with a local sending state of
+          <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> and the associated
+          <tp:dbus-ref namespace="ofdT.Call1.Content"
+          >Disposition</tp:dbus-ref> set to
+          <tp:value-ref type="Call_Content_Disposition">Initial</tp:value-ref> are
+          automatically set to sending.</p>
       </tp:docstring>
     </property>
 
diff --git a/spec/Call_Stream_Endpoint.xml b/spec/Call_Stream_Endpoint.xml
index cf1783d1..2aa7e52f 100644
--- a/spec/Call_Stream_Endpoint.xml
+++ b/spec/Call_Stream_Endpoint.xml
@@ -20,7 +20,7 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call.Stream.Endpoint.DRAFT"
+  <interface name="org.freedesktop.Telepathy.Call1.Stream.Endpoint"
     tp:causes-havoc="experimental">
     <tp:added version="0.19.0">(draft 1)</tp:added>
 
@@ -92,39 +92,99 @@
       </arg>
     </signal>
 
-    <signal name="CandidateSelected"
-      tp:name-for-bindings="Candidate_Selected">
+    <tp:struct name="Candidate_Pair" array-name="Candidate_Pair_List">
+      <tp:docstring>A Pair of candidates.</tp:docstring>
+      <tp:member name="Local" type="(usua{sv})" tp:type="Candidate">
+        <tp:docstring>The local candidate.</tp:docstring>
+      </tp:member>
+      <tp:member name="Remote" type="(usua{sv})" tp:type="Candidate">
+        <tp:docstring>The remote candidate.</tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <signal name="CandidatePairSelected"
+      tp:name-for-bindings="Candidate_Pair_Selected">
       <tp:docstring>
-        Emitted when a candidate is selected for use in the stream.
+        Emitted when a candidate is selected for use in the stream by the
+        controlling side of an ICE session.
+        The controlled side should call
+        <tp:member-ref>AcceptSelectedCandidatePair</tp:member-ref> or
+        <tp:member-ref>RejectSelectedCandidatePair</tp:member-ref> when
+        connectivity checks have either succeeded or failed for this candidate
+        pair. See also: <tp:member-ref>SelectedCandidatePairs</tp:member-ref>.
       </tp:docstring>
-      <arg name="Candidate"
+      <arg name="Local_Candidate"
+        type="(usua{sv})" tp:type="Candidate">
+        <tp:docstring>
+          The local candidate that has been selected.
+        </tp:docstring>
+      </arg>
+      <arg name="Remote_Candidate"
         type="(usua{sv})" tp:type="Candidate">
         <tp:docstring>
-          The candidate that has been selected.
+          The remote candidate that has been selected.
         </tp:docstring>
       </arg>
     </signal>
 
-    <property name="SelectedCandidate"
-      tp:name-for-bindings="Selected_Candidate"
-      type="(usua{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.
+    <property name="SelectedCandidatePairs"
+      tp:name-for-bindings="Selected_Candidate_Pairs"
+      type="a((usua{sv})(usua{sv}))" tp:type="Candidate_Pair[]"
+      access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The candidates that have been selected for use to stream packets
+        to the remote contact for each component of the stream.
+        Change notification is given via the
+        the <tp:member-ref>CandidatePairSelected</tp:member-ref> signal.</p>
+
+        <p>Note to client implementors (from <a
+        href="http://tools.ietf.org/html/rfc5245#section-9.2.2.3">RFC 5245
+        section 9.2.2.3</a>):</p>
+
+        <blockquote>
+          <p>If at least one of the pairs is In-Progress, the agent SHOULD wait
+          for those checks to complete, and as each completes, redo the
+          processing in this section until there are no losing pairs.</p>
+        </blockquote>
+
+        <p>Also note that some or all of the local candidates in this list may
+        represent a peer-reflexive candidate that do not appear in
+        <tp:dbus-ref namespace="ofdT.Call1.Stream.Interface.Media"
+        >LocalCandidates</tp:dbus-ref>.</p>
+
+        <p>See <a href='http://tools.ietf.org/html/rfc5245#appendix-B.6'>RFC
+        5245 Appendix B.6.</a> for more details about why this is.</p>
       </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>.
+    <method name="SetSelectedCandidatePair"
+      tp:name-for-bindings="Set_Selected_Candidate_Pair">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Update the entry in
+        <tp:member-ref>SelectedCandidatePairs</tp:member-ref>
+        for a particular component, and signal it to the remote side.</p>
+
+        <p>This method should only be called by the controlling side of an
+        ICE session. See <tp:member-ref>CandidatePairSelected</tp:member-ref>
+        for details.</p>
+
+        <tp:rationale>
+          <p>In the SDP offer/answer model, this signalling will take place as
+          generating an updated offer.
+          Note that updates may be queued up until information about all
+          components of all streams is gathered.</p>
+        </tp:rationale>
       </tp:docstring>
-      <arg name="Candidate"
+      <arg name="Local_Candidate"
+        type="(usua{sv})" tp:type="Candidate" direction="in">
+        <tp:docstring>
+          The local candidate that has been selected.
+        </tp:docstring>
+      </arg>
+      <arg name="Remote_Candidate"
         type="(usua{sv})" tp:type="Candidate" direction="in">
         <tp:docstring>
-          The candidate that has been selected.
+          The remote candidate that has been selected.
         </tp:docstring>
       </arg>
       <tp:possible-errors>
@@ -132,36 +192,95 @@
       </tp:possible-errors>
     </method>
 
-    <property name="StreamState" tp:name-for-bindings="Stream_State"
-      type="u" tp:type="Media_Stream_State"
+    <tp:enum name="Stream_Endpoint_State" type="u">
+      <tp:docstring>
+        Represents the state of ICE negotiation for a single component of a
+        stream to an endpoint.
+      </tp:docstring>
+      <tp:enumvalue suffix="Connecting" value="0">
+        <tp:docstring>
+          Candidate gathering and connectivity checks are in progress.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Provisionally_Connected" value="1">
+        <tp:docstring>
+          The streaming implementation has found at least one working
+          candidate pair. It is possible to send media at this point, but the
+          controlling side has yet to negotiate the final candidates for use
+          in this call.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Fully_Connected" value="2">
+        <tp:docstring>
+          This component of the stream is connected, and an updated offer has
+          been sent and accepted (finalising the candidates to be used for the
+          call). This should be set by the CM in response to
+          <tp:member-ref>AcceptSelectedCandidatePair</tp:member-ref>.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Exhausted_Candidates" value="3">
+        <tp:docstring>
+          The streaming implementation has tried connecting to all of the
+          available candidates and none of them have connected. This is
+          distinct from Failed, because the CM might be able to provide more
+          candidates later (more likely in XMPP than SIP).
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Failed" value="4">
+        <tp:docstring>
+          The CM and streaming implementation are in agreement that it is
+          impossible to connect to this endpoint. This value should only be
+          set by the CM.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <tp:mapping name="Component_State_Map">
+      <tp:member name="Component" type="u" tp:type="Stream_Component"/>
+      <tp:member name="State" type="u" tp:type="Stream_Endpoint_State"/>
+    </tp:mapping>
+
+    <property name="EndpointState" tp:name-for-bindings="Endpoint_State"
+      type="a{uu}" tp:type="Component_State_Map"
       access="read">
       <tp:docstring>
-        The stream state of the endpoint.
+        The state of ICE negotiation with this Endpoint for each component of
+        the stream.
       </tp:docstring>
     </property>
 
-    <signal name="StreamStateChanged"
-      tp:name-for-bindings="Stream_State_Changed">
+    <signal name="EndpointStateChanged"
+      tp:name-for-bindings="Endpoint_State_Changed">
       <tp:docstring>
-        Emitted when the <tp:member-ref>StreamState</tp:member-ref>
+        Emitted when the <tp:member-ref>EndpointState</tp:member-ref>
         property changes.
       </tp:docstring>
-      <arg name="state" type="u" tp:type="Media_Stream_State">
+      <arg name="Component" type="u" tp:type="Stream_Component">
+        <tp:docstring>
+          The component whose state has changed.
+        </tp:docstring>
+      </arg>
+      <arg name="State" type="u" tp:type="Stream_Endpoint_State">
         <tp:docstring>
-          The new <tp:member-ref>StreamState</tp:member-ref> value.
+          The new state of this component.
         </tp:docstring>
       </arg>
     </signal>
 
-    <method name="SetStreamState"
-      tp:name-for-bindings="Set_Stream_State">
+    <method name="SetEndpointState"
+      tp:name-for-bindings="Set_Endpoint_State">
       <tp:docstring>
-        Change the <tp:member-ref>StreamState</tp:member-ref> of the
+        Change the <tp:member-ref>EndpointState</tp:member-ref> of the
         endpoint.
       </tp:docstring>
-      <arg direction="in" name="State" type="u" tp:type="Media_Stream_State">
+      <arg direction="in" name="Component" type="u" tp:type="Stream_Component">
+        <tp:docstring>
+          The component whose state needs updating.
+        </tp:docstring>
+      </arg>
+      <arg direction="in" name="State" type="u" tp:type="Stream_Endpoint_State">
         <tp:docstring>
-          The requested stream state.
+          The new state of this component.
         </tp:docstring>
       </arg>
       <tp:possible-errors>
@@ -170,6 +289,54 @@
       </tp:possible-errors>
     </method>
 
+    <method name="AcceptSelectedCandidatePair"
+      tp:name-for-bindings="Accept_Selected_Candidate_Pair">
+      <tp:docstring>
+        Called in response to
+        <tp:member-ref>CandidatePairSelected</tp:member-ref> if/when this
+        candidate pair is known to have passed its connectivity checks.
+      </tp:docstring>
+      <arg name="Local_Candidate"
+        type="(usua{sv})" tp:type="Candidate" direction="in">
+        <tp:docstring>
+          The local candidate that has been selected.
+        </tp:docstring>
+      </arg>
+      <arg name="Remote_Candidate"
+        type="(usua{sv})" tp:type="Candidate" direction="in">
+        <tp:docstring>
+          The remote candidate that has been selected.
+        </tp:docstring>
+      </arg>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument"/>
+      </tp:possible-errors>
+    </method>
+
+    <method name="RejectSelectedCandidatePair"
+      tp:name-for-bindings="Reject_Selected_Candidate_Pair">
+      <tp:docstring>
+        Called in response to
+        <tp:member-ref>CandidatePairSelected</tp:member-ref> if/when this
+        candidate pair is known to have failed its connectivity checks.
+      </tp:docstring>
+      <arg name="Local_Candidate"
+        type="(usua{sv})" tp:type="Candidate" direction="in">
+        <tp:docstring>
+          The local candidate that has been selected.
+        </tp:docstring>
+      </arg>
+      <arg name="Remote_Candidate"
+        type="(usua{sv})" tp:type="Candidate" direction="in">
+        <tp:docstring>
+          The remote 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="Transport" tp:name-for-bindings="Transport"
       type="u" tp:type="Stream_Transport_Type" access="read">
       <tp:docstring>
@@ -177,6 +344,57 @@
       </tp:docstring>
     </property>
 
+    <property name="Controlling" tp:name-for-bindings="Controlling"
+      type="b" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>
+        The local side is taking the controlling role (as defined by ICE RFC
+        5245). Change notification is given via the
+        <tp:member-ref>ControllingChanged</tp:member-ref> signal.</p>
+
+        <tp:rationale>In ICE, the Caller is normally in controlling mode (and
+        the Callee in controlled-mode), except if the Caller is doing ICE-Lite,
+        in which case it's reversed. The Controlling side is responsible for
+        selecting nominated pairs, and generating updated offers upon
+        conclusion of ICE.</tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <method name="SetControlling"
+      tp:name-for-bindings="Set_Controlling">
+      <tp:docstring>
+        Set whether the local side is taking the Controlling role. Note that
+        if there are multiple endpoints (e.g. SIP call forking) it may be the
+        case that all endpoints need to have the same controlling/controlled
+        orientation.
+      </tp:docstring>
+      <arg name="Controlling" type="b" direction="in">
+        <tp:docstring>
+          The new value of <tp:member-ref>Controlling</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+    </method>
+
+    <signal name="ControllingChanged"
+      tp:name-for-bindings="Controlling_Changed">
+      <tp:docstring>
+        The value of <tp:member-ref>Controlling</tp:member-ref> has changed.
+      </tp:docstring>
+      <arg name="Controlling" type="b">
+        <tp:docstring>
+          The new value of <tp:member-ref>Controlling</tp:member-ref>.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <property name="IsICELite" tp:name-for-bindings="Is_ICE_Lite"
+      type="b" access="read">
+      <tp:docstring>
+        The Remote side is an ICE Lite endpoint. (The local side is assumed to
+        always be an ICE Full implementation.)
+      </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
index 54476f0f..450d5ea4 100644
--- a/spec/Call_Stream_Interface_Media.xml
+++ b/spec/Call_Stream_Interface_Media.xml
@@ -20,35 +20,210 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Call.Stream.Interface.Media.DRAFT"
+  <interface name="org.freedesktop.Telepathy.Call1.Stream.Interface.Media"
       tp:causes-havoc="experimental">
     <tp:added version="0.19.0">(draft 1)</tp:added>
-    <tp:requires interface="org.freedesktop.Telepathy.Call.Stream.DRAFT"/>
+    <tp:requires interface="org.freedesktop.Telepathy.Call1.Stream"/>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      [FIXME]
+      <p>This interface deals with how to connect a stream to an
+      endpoint.  It contains all that is required to describe the
+      local endpoint, to succesfully establish a connection. While a
+      call is established, one may try to connect to multiple remote
+      endpoints at the same time. This is called forking in the SIP
+      jargon.  Informations related to the connections are on the
+      <tp:dbus-ref
+      namespace="ofdT.Call1.Stream">Endpoint</tp:dbus-ref>
+      objects. Once the call is established, there MUST be a single
+      endpoint left.</p>
 
       <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>If the CM wants to do an ICE restart, then the
+        <tp:member-ref>ICERestartPending</tp:member-ref> property is set,
+        and the <tp:member-ref>ICERestartRequested</tp:member-ref> signal is
+        emitted. The streaming implementation should then call
+        <tp:member-ref>SetCredentials</tp:member-ref> again. This will trigger
+        the actual ICE restart, and cause
+        <tp:member-ref>LocalCandidates</tp:member-ref> to be cleared.</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>
 
+    <tp:enum type="u" name="Stream_Flow_State">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        The type of <tp:member-ref>SendingState</tp:member-ref>
+        and <tp:member-ref>ReceivingState</tp:member-ref>.
+      </tp:docstring>
+      <tp:enumvalue suffix="Stopped" value="0">
+        <tp:docstring>
+          No data is flowing (or expected to be flowing) at this time.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Pending_Start" value="1">
+        <tp:docstring>
+          The streaming implementation has been told to start or receiving,
+          but has not yet indicated that it is doing so.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Pending_Stop" value="2">
+        <tp:docstring>
+          The streaming implementation has been told to stop sending or
+          receiving data, but it has not yet indicated that it has done so.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Started" value="3">
+        <tp:docstring>
+          The streaming implementation is successfully sending or receiving
+          data, and everything is going swimmingly.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Pending_Pause" value="4">
+        <tp:docstring>
+          The streaming implementation has been told to pause sending or
+          displaying data, but it has not yet indicated that it has done so.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Paused" value="5">
+        <tp:docstring>
+          The streaming implementation has successfully paused either sending or
+          displaying data, and the local user's privacy or peace-and-quiet is
+          protected.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+    <property name="SendingState" tp:name-for-bindings="Sending_State"
+        type="u" tp:type="Stream_Flow_State" access="read">
+      <tp:docstring>
+        Indicates whether the streaming implementation is/should be sending
+        media for this stream. The streaming implementation should be able to
+        rely on reading this value and listening to
+        <tp:member-ref>SendingStateChanged</tp:member-ref> to
+        determine whether it should be sending media or not. It should not
+        need to listen to the Mute/Hold interfaces on the Call/Content.
+        Feedback on success should be given via
+        <tp:member-ref>CompleteSendingStateChange</tp:member-ref>. Failures
+        should be reported via <tp:member-ref>ReportSendingFailure</tp:member-ref>.
+      </tp:docstring>
+    </property>
+
+    <signal name="SendingStateChanged"
+        tp:name-for-bindings="Sending_State_Changed">
+      <tp:docstring>
+        Change notification for <tp:member-ref>SendingState</tp:member-ref>.
+        Note that this information is duplicated onto the Stream interface, so
+        that UIs can ignore the Media interface, and streaming implementations
+        can ignore everything but the media interface.
+      </tp:docstring>
+      <arg name="State" type="u" tp:type="Stream_Flow_State">
+        <tp:docstring>
+          The new value of SendingState.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <method name="CompleteSendingStateChange"
+        tp:name-for-bindings="Complete_Sending_State_Change">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Called in response to
+          <tp:member-ref>SendingStateChanged</tp:member-ref>(Pending_*, *) to
+          indicate that the media state has successfully progressed from
+          Pending_{Start, Stop, Pause} to the corresponding non-pending
+          state.</p>
+      </tp:docstring>
+      <arg name="State" type="u" tp:type="Stream_Flow_State" direction="in">
+        <tp:docstring>
+          The new (non-pending) value of SendingState.
+        </tp:docstring>
+      </arg>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The state change made no sense, and was ignored by the CM. The
+            most likely cause for this is a race-condition between the CM
+            emitting a new state change and the streaming implementation
+            responding to the previous state change.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="ReportSendingFailure"
+        tp:name-for-bindings="Report_Sending_Failure">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        Can be called at any point to indicate a failure in the outgoing
+        portion of the stream.
+      </tp:docstring>
+      <arg name="Reason" type="u" tp:type="Call_State_Change_Reason"
+        direction="in"/>
+      <arg name="Error" type="s" tp:type="DBus_Error_Name" direction="in"/>
+      <arg name="Message" type="s" direction="in"/>
+    </method>
+
+    <property name="ReceivingState" tp:name-for-bindings="Receiving_State"
+        type="u" tp:type="Stream_Flow_State" access="read">
+      <tp:docstring>
+        The counterpart of <tp:member-ref>SendingState</tp:member-ref>.
+        Indicates whether the streaming implementation is/should be expecting
+        to receive media for this stream. The CM should only tell the
+        streaming implementation to stop receiving if it has been told to put
+        the stream on hold, or the stream has been removed from the call.
+      </tp:docstring>
+    </property>
+
+    <signal name="ReceivingStateChanged"
+        tp:name-for-bindings="Receiving_State_Changed">
+      <tp:docstring>
+        Change notification for <tp:member-ref>ReceivingState</tp:member-ref>.
+      </tp:docstring>
+      <arg name="State" type="u" tp:type="Stream_Flow_State">
+        <tp:docstring>
+          The new value of ReceivingState.
+        </tp:docstring>
+      </arg>
+    </signal>
+
+    <method name="CompleteReceivingStateChange"
+        tp:name-for-bindings="Complete_Receiving_State_Change">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Called in response to
+          <tp:member-ref>ReceivingStateChanged</tp:member-ref>(Pending_*, *) to
+          indicate that the media state has successfully progressed from
+          Pending_{Start, Stop, Pause} to the corresponding non-pending
+          state.</p>
+      </tp:docstring>
+      <arg name="State" type="u" tp:type="Stream_Flow_State" direction="in">
+        <tp:docstring>
+          The new (non-pending) value of ReceivingState.
+        </tp:docstring>
+      </arg>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The state change made no sense, and was ignored by the CM. The
+            most likely cause for this is a race-condition between the CM
+            emitting a new state change and the streaming implementation
+            responding to the previous state change.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="ReportReceivingFailure"
+        tp:name-for-bindings="Report_Receiving_Failure">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        Can be called at any point to indicate a failure in the outgoing
+        portion of the stream.
+      </tp:docstring>
+      <arg name="Reason" type="u" tp:type="Call_State_Change_Reason"
+        direction="in"/>
+      <arg name="Error" type="s" tp:type="DBus_Error_Name" direction="in"/>
+      <arg name="Message" type="s" direction="in"/>
+    </method>
+
     <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
@@ -66,6 +241,57 @@
       </arg>
     </method>
 
+    <tp:enum type="u" name="Call_Stream_Candidate_Type">
+      <tp:docstring>
+        The network topology that an IP candidate represents. This can
+        sometimes be used to infer what kind of performance characteristics
+        (latency, bandwith, etc) can be expected of connections made to this
+        candidate.
+      </tp:docstring>
+      <tp:enumvalue suffix="None" value="0">
+        <tp:docstring>
+          This is not an IP candidate. This is a reserved value, and should
+          not be seen on the bus.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Host" value="1">
+        <tp:docstring>
+          This candidate represents a direct connection to the host, as its
+          address is taken directly the host's IP stack.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Server_Reflexive" value="2">
+        <tp:docstring>
+          This candidate probably represents a connection to the host through
+          a NAT device, as its address was discovered by sending a binding
+          request to a STUN server or similar.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Peer_Reflexive" value="3">
+        <tp:docstring>
+          This candidate probably represents a good route between the host and
+          its peer, as its address was discovered by sending a STUN binding
+          request to one of the candidates advertised by the peer.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Relay" value="4">
+        <tp:docstring>
+          This candidate represents the address of a relay server (usually
+          somewhere on the public internet). This candidate is the most likely
+          to work, but all media will go via a relay server, so latency is
+          likely to be higher than other types of candidate.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Multicast" value="5">
+        <tp:docstring>
+          This candidate represents a Multicast group. This value should only
+          appear if the Stream's <tp:member-ref>Transport</tp:member-ref> is
+          set to Multicast.
+        </tp:docstring>
+      </tp:enumvalue>
+    </tp:enum>
+
+
     <tp:mapping name="Candidate_Info">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Extra information about the candidate. Allowed and mandatory keys
@@ -73,32 +299,48 @@
           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><code>type</code> - u</dt>
+          <dd>The type of candidate
+            (<tp:type>Call_Stream_Candidate_Type</tp:type>)</dd>
+
+          <dt><code>foundation</code> - s</dt>
+          <dd>The foundation of this candidate</dd>
+
+          <dt><code>protocol</code> - u</dt>
+          <dd>Underlying protocol of the candidate
+            (<tp:type>Media_Stream_Base_Proto</tp:type>) </dd>
+
+          <dt><code>priority</code> - u</dt>
+          <dd>Priority of the candidate (should be a number between 0 and
+            65535). Most ICE implementations will prefer the highest priority
+            candidate pair that manages to connect. For backwards
+            compatibility with non-ICE SIP clients, the lowest priority
+            candidate may be sent as a raw UDP fallback candidate.
+            It is recommended that a relay candidate is used as the lowest
+            priority candidate if possible. If both IPv4 and IPv6 raw udp
+            fallback candidates are available, they should be set to the
+            same priority and advertised to the CM at the same time. The CM
+            will decide which to advertise to the remote end.</dd>
+
+          <dt><code>base-ip</code> - s</dt>
+          <dd>The underlying Host address where media sent to this
+            (non-host-type) candidate will eventually arrive.</dd>
+
+          <dt><code>base-port</code> - u</dt>
+          <dd>The underlying Host port where media sent to this
+            (non-host-type) candidate will eventually arrive.</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>
+          <dt><code>username</code> - s</dt>
           <dd>Username of this candidate
             (only if credentials are per candidate)</dd>
 
-          <dt>Password (s) </dt>
+          <dt><code>password</code> - 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>
+          <dt><code>ttl</code> - u</dt>
+          <dd>The TTL mandated for RTP/RTCP packets sent to a multicast group
+            (only valid for Multicast Streams)</dd>
         </dl>
       </tp:docstring>
       <tp:member name="Key" type="s">
@@ -156,7 +398,9 @@
       <tp:docstring>
         Add candidates to the
         <tp:member-ref>LocalCandidates</tp:member-ref> property and
-        signal them to the remote contact(s).
+        signal them to the remote contact(s). Note that connection managers
+        MAY delay the sending of candidates until
+        <tp:member-ref>FinishInitialCandidates</tp:member-ref> is called.
       </tp:docstring>
       <arg name="Candidates" direction="in"
         type="a(usua{sv})" tp:type="Candidate[]">
@@ -166,11 +410,15 @@
       </arg>
     </method>
 
-    <method name="CandidatesPrepared"
-      tp:name-for-bindings="Candidates_Prepared">
+    <method name="FinishInitialCandidates"
+      tp:name-for-bindings="Finish_Initial_Candidates">
       <tp:docstring>
         This indicates to the CM that the initial batch of candidates
-        has been added.
+        has been added, and should now be processed/sent to the remote side.
+        <tp:rationale>
+          Protocols supporting Raw UDP SHOULD wait for FinishInitialCandidates,
+          and then set the lowest priority candidate as the Raw UDP candidate.
+        </tp:rationale>
       </tp:docstring>
     </method>
 
@@ -190,7 +438,7 @@
           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.
+          >Call1</tp:dbus-ref> interface.
           [This corresponds to "none" or "stun" in the old Media.StreamHandler
           interface.]
         </tp:docstring>
@@ -277,8 +525,14 @@
     <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
+        The local credentials are sent to the remote site over the
+        signalling protocol. They are used in ICE to make sure that
+        the connectivity checks come from the right peer. Change
+        notification is via the
         <tp:member-ref>LocalCredentialsChanged</tp:member-ref> signal.
+
+        This property will be a pair of empty strings if ICE has not yet been
+        started.
       </tp:docstring>
     </property>
 
@@ -287,7 +541,10 @@
       <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:member-ref>LocalCredentials</tp:member-ref> changes to a non-empty
+        value. This should only happen when the streaming implementation calls
+        <tp:member-ref>SetCredentials</tp:member-ref>, so this signal is
+        mostly useful for debugging.
       </tp:docstring>
       <arg name="Username" type="s" />
       <arg name="Password" type="s" />
@@ -333,7 +590,7 @@
       <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>
+          determined from the protocol. Well-known map keys are:</p>
 
         <dl>
           <dt><code>ip</code> - s</dt>
@@ -366,6 +623,22 @@
           <dd>The UDP or TCP port of the relay server as an ASCII unsigned
             integer</dd>
 
+          <dt><code>unique-id</code> - s</dt>
+          <dd>A string identifying the relay server. If two RelayInfo entries
+            have the same unique-id, but different <code>type</code>s, there
+            is usually little point in connecting to both. Use
+            <code>priority</code> to determine which version to prefer in this
+            case. Can also be used by the streaming implementation to avoid
+            connecting to the same relay multiple times if relaying is
+            required for both audio and video.</dd>
+
+          <dt><code>priority</code> - u</dt>
+          <dd>A number determining which version of a server to prefer (if
+            multiple are present with the same <code>unique-id</code>,
+            the one with the highest priority should be used, or the streaming
+            implementation should use the one whose <code>type</code> has the
+            most desirable properties)</dd>
+
           <dt><code>username</code> - s</dt>
           <dd>The username to use</dd>
 
@@ -451,8 +724,8 @@
     <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
+        <p>The list of <tp:dbus-ref namespace="ofdT.Call1.Stream"
+          >Endpoint</tp:dbus-ref> objects that exist for this
           stream.</p>
 
         <p>Change notification is via the
@@ -460,14 +733,38 @@
       </tp:docstring>
     </property>
 
-    <signal name="PleaseRestartICE"
-      tp:name-for-bindings="Please_Restart_ICE">
+    <signal name="ICERestartRequested"
+      tp:name-for-bindings="ICE_Restart_Requested">
       <tp:docstring>
-        Emitted when the CM does an ICE restart to notify the
-        streaming implementation that it should call
+        Emitted when the remote side requests an ICE restart (e.g. third party
+        call control, when the remote endpoint changes). The streaming
+        implementation should call
         <tp:member-ref>SetCredentials</tp:member-ref> again.
       </tp:docstring>
     </signal>
+
+    <property name="ICERestartPending"
+      tp:name-for-bindings="ICE_Restart_Pending" access="read" type="b">
+      <tp:docstring>
+        State recovery for <tp:member-ref>ICERestartRequested</tp:member-ref>.
+        Set when the signal is emitted, and unset when
+        <tp:member-ref>SetCredentials</tp:member-ref> is called.
+        Useful for debugging.
+      </tp:docstring>
+    </property>
+
+    <method name="Fail" tp:name-for-bindings="Fail">
+      <tp:docstring>
+        Signal an unrecoverable error for this stream, and remove it. If all
+        streams are removed from a content, then it will also be removed.
+      </tp:docstring>
+      <arg direction="in" name="Reason" type="(uuss)"
+        tp:type="Call_State_Reason">
+        <tp:docstring>
+          A structured reason for stream removal.
+        </tp:docstring>
+      </arg>
+    </method>
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Dispatcher.xml b/spec/Channel_Dispatcher.xml
index 2dd000b4..771d0608 100644
--- a/spec/Channel_Dispatcher.xml
+++ b/spec/Channel_Dispatcher.xml
@@ -168,10 +168,10 @@
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
           <tp:docstring>
-            The Preferred_Handler is syntactically invalid or does
+            The <var>Preferred_Handler</var> is syntactically invalid or does
             not start with <code>org.freedesktop.Telepathy.Client.</code>,
-            the Account does not exist, or one of the Requested_Properties
-            is invalid
+            the <var>Account</var> does not exist, or one of the
+            <var>Requested_Properties</var> is invalid
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -240,10 +240,10 @@
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
           <tp:docstring>
-            The Preferred_Handler is syntactically invalid or does
+            The <var>Preferred_Handler</var> is syntactically invalid or does
             not start with <code>org.freedesktop.Telepathy.Client.</code>,
-            the Account does not exist, or one of the Requested_Properties
-            is invalid
+            the <var>Account</var> does not exist, or one of the
+            <var>Requested_Properties</var> is invalid
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -418,10 +418,10 @@
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
           <tp:docstring>
-            The Preferred_Handler is syntactically invalid or does
+            The <var>Preferred_Handler</var> is syntactically invalid or does
             not start with <code>org.freedesktop.Telepathy.Client.</code>,
-            the Account does not exist, or one of the Requested_Properties
-            is invalid
+            the <var>Account</var> does not exist, or one of the
+            <var>Requested_Properties</var> is invalid
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -559,16 +559,195 @@
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
           <tp:docstring>
-            The Preferred_Handler is syntactically invalid or does
+            The <var>Preferred_Handler</var> is syntactically invalid or does
             not start with <code>org.freedesktop.Telepathy.Client.</code>,
-            the Account does not exist, or one of the Requested_Properties
-            is invalid
+            the <var>Account</var> does not exist, or one of the
+            <var>Requested_Properties</var> is invalid
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
 
     </method>
 
+    <method name="DelegateChannels"
+            tp:name-for-bindings="Delegate_Channels">
+      <tp:added version="0.23.1">
+        Implemented since telepathy-mission-control 5.7.12.
+      </tp:added>
+      <tp:changed version="0.23.2">This method now returns
+        <var>Delegated</var> and <var>Not_Delegated</var> instead of nothing.
+        <tp:dbus-ref namespace="ofdT.Client.Handler">HandleChannels</tp:dbus-ref>
+        is now called once per <var>Channel</var> in <var>Channels</var>.
+      </tp:changed>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Called by a
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+          to redispatch a bunch of channels it is currently handling.</p>
+
+        <p>For each <var>Channel</var> in <var>Channels</var>, if another
+          <tp:dbus-ref namespace="ofdT.Client">Handler</tp:dbus-ref>
+          can be found,
+          <tp:dbus-ref namespace="ofdT.Client.Handler">HandleChannels</tp:dbus-ref>
+          will be called on it until a
+          <tp:dbus-ref namespace="ofdT.Client">Handler</tp:dbus-ref>
+          accepts it.</p>
+
+        <p>This method returns once all the <var>Channels</var> have either
+          been accepted or rejected by Handlers.</p>
+
+        <p>If this method fails, the original
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+          is still handling the channels.</p>
+
+      </tp:docstring>
+
+      <arg direction="in" name="Channels" type="ao">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The list of channels to redispatch. The caller has to be the current
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client">Handler</tp:dbus-ref>
+            of all of these channels
+          </p>
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="User_Action_Time" type="x"
+        tp:type="User_Action_Timestamp">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The time at which user action occurred, or 0 if this channels
+            delegation is for some reason not involving user action.</p>
+
+          <p>This parameter is used in the same way as the corresponding
+            parameter to
+            <tp:member-ref>CreateChannelWithHints</tp:member-ref>.</p>
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="Preferred_Handler" type="s"
+        tp:type="DBus_Well_Known_Name">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>Either the well-known bus name (starting with
+            <code>org.freedesktop.Telepathy.Client.</code>)
+            of the preferred new handler for these
+            channels, or an empty string to indicate that any handler would be
+            acceptable. The behaviour and rationale are the same as for the
+            corresponding parameter to
+            <tp:member-ref>CreateChannelWithHints</tp:member-ref>.</p>
+
+        </tp:docstring>
+      </arg>
+
+      <arg direction="out" name="Delegated" type="ao">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The list of channels which have been delegated; the caller is no
+          longer handling these channels.</p>
+
+          <p>The client should remove these channels from its
+          <tp:dbus-ref namespace="ofdT.Client.Handler">HandledChannels</tp:dbus-ref>
+          property.</p>
+        </tp:docstring>
+      </arg>
+
+      <arg direction="out" name="Not_Delegated" type="a{o(ss)}"
+       tp:type="Not_Delegated_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The list of channels which have NOT been delegated; the caller is still
+          handling these channels.</p>
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The Preferred_Handler is syntactically invalid or does
+            not start with <code>org.freedesktop.Telepathy.Client.</code>.
+          </tp:docstring>
+        </tp:error>
+
+        <tp:error name="org.freedesktop.Telepathy.Error.NotYours">
+          <tp:docstring>
+            At least one <var>Channel</var> in <var>Channels</var> is not
+            currently handled by the caller. No <var>Channel</var> has been
+            delegated.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+
+    </method>
+
+    <tp:mapping name="Not_Delegated_Map">
+      <tp:docstring>
+        A mapping associating not delegated channel with an error.
+      </tp:docstring>
+
+      <tp:member type="o" name="Channel">
+        <tp:docstring>
+          The path of the channel
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="(ss)" name="Error" tp:type="Not_Delegated_Error">
+        <tp:docstring>
+          An error describing why the channel has not be delegated
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <tp:struct name="Not_Delegated_Error">
+      <tp:member type="s" name="Error_Name" tp:type="DBus_Error_Name">
+        <tp:docstring>
+          the name of a D-Bus error describing what went wrong.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="s" name="Error_Message">
+        <tp:docstring>
+          a human-readable informative error message.
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <method name="PresentChannel"
+            tp:name-for-bindings="Present_Channel">
+      <tp:added version="0.23.1">
+        Implemented since telepathy-mission-control 5.7.12.
+      </tp:added>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Equivalent of calling
+        <tp:dbus-ref namespace="org.freedesktop.Telepathy.ChannelDispatcher">EnsureChannel</tp:dbus-ref>
+        with a <var>Requested_Properties</var> which would result in ensuring
+        <var>Channel</var>.</p>
+
+         <p>If <var>Channel</var> is handled, its handler will be asked to present it the user
+         (e.g. bring it into the foreground).</p>
+      </tp:docstring>
+
+      <arg direction="in" name="Channel" type="o">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The channel to present.</p>
+        </tp:docstring>
+      </arg>
+
+      <arg direction="in" name="User_Action_Time" type="x"
+        tp:type="User_Action_Timestamp">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The time at which user action occurred, or 0 if this channel
+            request is for some reason not involving user action.</p>
+
+          <p>This parameter is used in the same way as the corresponding
+            parameter to
+            <tp:member-ref>EnsureChannelWithHints</tp:member-ref>.</p>
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            The Account does not exist, the Channel does not exist or it
+            does not belong to the Account.
+          </tp:docstring>
+        </tp:error>
+
+      </tp:possible-errors>
+    </method>
+
     <property name="SupportsRequestHints"
               tp:name-for-bindings="Supports_Request_Hints"
               type="b" access="read">
diff --git a/spec/Channel_Interface_DTMF.xml b/spec/Channel_Interface_DTMF.xml
index d74ea6fa..bb579a11 100644
--- a/spec/Channel_Interface_DTMF.xml
+++ b/spec/Channel_Interface_DTMF.xml
@@ -21,12 +21,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   <interface name="org.freedesktop.Telepathy.Channel.Interface.DTMF">
     <tp:xor-requires>
       <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
-      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call.DRAFT"/>
+      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call1"/>
     </tp:xor-requires>
     <tp:changed version="0.19.6">The <tp:type>Stream_ID</tp:type>s in this
       interface should now be ignored by CMs. This is primarily to allow this
       interface to be used with <tp:dbus-ref
-      namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref>
+      namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref>
       channels.</tp:changed>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
diff --git a/spec/Channel_Interface_File_Transfer_Metadata.xml b/spec/Channel_Interface_File_Transfer_Metadata.xml
new file mode 100644
index 00000000..4d2d728d
--- /dev/null
+++ b/spec/Channel_Interface_File_Transfer_Metadata.xml
@@ -0,0 +1,98 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_File_Transfer_Metadata"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+  <tp:copyright>Copyright (C) 2011 Collabora Ltd.</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.Channel.Interface.FileTransfer.Metadata">
+    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.FileTransfer"/>
+    <tp:added version="0.25.0"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>This interface exists to provide a mechanism to include
+        arbitrary additional information in file transfers. For
+        example, one might want to send a document and include the
+        number of times the character P appeared in the file, so would
+        add <tt>NumberOfPs=42</tt> to the
+        <tp:member-ref>Metadata</tp:member-ref> property.</p>
+
+      <p><tp:member-ref>ServiceName</tp:member-ref> living in its own
+        property makes it easier for specific applications to send
+        files to each other, bypassing the standard handler. For
+        example, the Banshee Telepathy plugin handler could match on
+        <tp:member-ref>ServiceName</tp:member-ref> so the Empathy file
+        transfer is not used instead.</p>
+   </tp:docstring>
+
+    <property name="ServiceName" tp:name-for-bindings="Service_Name"
+      type="s" access="readwrite" tp:immutable="sì"
+      tp:requestable="naturalmente">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A string representing the service name that will be used
+          over the file transfer channel. This property is equivalent
+          to the <tp:dbus-ref
+            namespace="ofdT">Channel.Type.DBusTube.ServiceName</tp:dbus-ref>
+          and <tp:dbus-ref
+            namespace="ofdT">Channel.Type.StreamTube.Service</tp:dbus-ref>
+          properties. If no service name is given then this property
+          will be the empty string.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="Metadata" tp:name-for-bindings="Metadata"
+      type="a{sas}" tp:type="Metadata" access="readwrite"
+      tp:immutable="sì" tp:requestable="naturalmente">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Additional information about the file transfer set by the
+          channel initiator. If no additional information is given then
+          this property will be empty.</p>
+      </tp:docstring>
+    </property>
+
+    <tp:mapping name="Metadata" type="a{sas}">
+      <tp:docstring>
+        A mapping from string key to a list of strings, used in the
+        <tp:member-ref>Metadata</tp:member-ref> property. To emulate a
+        simple string → string hash table one should have exactly one
+        member in the value string list.
+
+        <tp:rationale>
+          This property is an a{sas} primarily because this maps
+          easily to <a
+          href="http://xmpp.org/extensions/xep-0004.html">XEP-0004
+          Data Forms</a>, and allows more structured metadata than
+          a{ss} would. (For instance, a list of RDF triples could be
+          expressed as one long array of strings, or as three-element
+          values for a series of dummy key names, rather than as one
+          big string blob.)
+
+          While it might be convenient for applications to allow keys
+          of arbitrary types, the added convenience would be
+          outweighed by having to define the XMPP representation
+        </tp:rationale>
+      </tp:docstring>
+
+      <tp:member name="Key" type="s"/>
+      <tp:member name="Values" type="as"/>
+    </tp:mapping>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_Group.xml b/spec/Channel_Interface_Group.xml
index 92de9c5c..890e84eb 100644
--- a/spec/Channel_Interface_Group.xml
+++ b/spec/Channel_Interface_Group.xml
@@ -334,6 +334,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
       <tp:added version="0.17.6">This signal should not be relied on
         unless Channel_Group_Flag_Properties is present.</tp:added>
+      <tp:deprecated version="0.23.4">Clients should listen to
+        <tp:member-ref>HandleOwnersChangedDetailed</tp:member-ref> instead to
+        get the new identifiers as well.
+        </tp:deprecated>
 
       <arg name="Added" type="a{uu}" tp:type="Handle_Owner_Map">
         <tp:docstring>
@@ -352,6 +356,44 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
     </signal>
 
+    <signal name="HandleOwnersChangedDetailed"
+      tp:name-for-bindings="Handle_Owners_Changed_Detailed">
+      <tp:docstring>
+        <p>Emitted whenever the <tp:member-ref>HandleOwners</tp:member-ref>
+        property changes.</p>
+
+        <p>Clients can assume this signal is emitted by the Connection Manager
+        if the <tp:member-ref>MemberIdentifiers</tp:member-ref> property exists
+        </p>
+      </tp:docstring>
+      <tp:added version="0.23.4"/>
+
+      <arg name="Added" type="a{uu}" tp:type="Handle_Owner_Map">
+        <tp:docstring>
+          A map from channel-specific handles to their owners, in which the
+          keys include all the handles that were added to the keys of the
+          HandleOwners property, and all the handles in that property whose
+          owner has 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
+          HandleOwners property, as a result of the contact leaving this group
+          in a previous <tp:member-ref>MembersChanged</tp:member-ref> signal
+        </tp:docstring>
+      </arg>
+      <arg name="Identifiers" type="a{us}" tp:type="Handle_Identifier_Map">
+        <tp:docstring>
+          The string identifiers for handles mentioned in this signal, to
+          give clients the minimal information necessary to create contacts
+          without waiting for round-trips. Connection managers MUST include at
+          least the identifiers for all handles in the Added map, and MAY
+          include those from Removed array.
+        </tp:docstring>
+      </arg>
+    </signal>
+
     <method name="GetHandleOwners" tp:name-for-bindings="Get_Handle_Owners">
       <arg direction="in" name="Handles" type="au" tp:type="Contact_Handle[]">
         <tp:docstring>
@@ -519,6 +561,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
       <tp:added version="0.17.6">This signal should not be relied on
         unless Channel_Group_Flag_Properties is present.</tp:added>
+      <tp:deprecated version="0.23.4">Clients should listen to
+        <tp:member-ref>SelfContactChanged</tp:member-ref> instead to get the new
+        identifier as well.
+        </tp:deprecated>
 
       <arg type="u" tp:type="Contact_Handle" name="Self_Handle">
         <tp:docstring>
@@ -527,6 +573,29 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </arg>
     </signal>
 
+    <signal name="SelfContactChanged" tp:name-for-bindings="Self_Contact_Changed">
+      <tp:docstring>
+        <p>Emitted whenever the <tp:member-ref>SelfHandle</tp:member-ref> property
+        changes.</p>
+
+        <p>Clients can assume this signal is emitted by the Connection Manager
+        if the <tp:member-ref>MemberIdentifiers</tp:member-ref> property exists.
+        </p>
+      </tp:docstring>
+      <tp:added version="0.23.4"/>
+
+      <arg type="u" tp:type="Contact_Handle" name="Self_Handle">
+        <tp:docstring>
+          The new value of the SelfHandle property.
+        </tp:docstring>
+      </arg>
+      <arg type="s" name="Self_ID">
+        <tp:docstring>
+          The new value of the SelfHandle property's identifier.
+        </tp:docstring>
+      </arg>
+    </signal>
+
     <property name="SelfHandle" type="u" tp:type="Contact_Handle"
       access="read" tp:name-for-bindings="Self_Handle">
       <tp:docstring>
@@ -545,6 +614,23 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         Channel_Group_Flag_Properties is not present.</tp:added>
     </property>
 
+    <property name="MemberIdentifiers" type="a{us}" tp:type="Handle_Identifier_Map"
+      access="read" tp:name-for-bindings="Member_Identifiers">
+      <tp:docstring>
+        The string identifiers for handles mentioned in this channel, to
+        give clients the minimal information necessary to create contacts
+        without waiting for round-trips. Connection managers MUST include at
+        least the identifiers for
+        <tp:member-ref>SelfHandle</tp:member-ref>,
+        <tp:member-ref>Members</tp:member-ref>,
+        <tp:member-ref>LocalPendingMembers</tp:member-ref> (and their actors if
+        any),
+        <tp:member-ref>RemotePendingMembers</tp:member-ref> and
+        <tp:member-ref>HandleOwners</tp:member-ref>.
+      </tp:docstring>
+      <tp:added version="0.23.4"/>
+    </property>
+
     <method name="GetSelfHandle" tp:name-for-bindings="Get_Self_Handle">
       <arg direction="out" type="u" tp:type="Contact_Handle"
         name="Self_Handle"/>
diff --git a/spec/Channel_Interface_Hold.xml b/spec/Channel_Interface_Hold.xml
index ef5a08f1..69d295d9 100644
--- a/spec/Channel_Interface_Hold.xml
+++ b/spec/Channel_Interface_Hold.xml
@@ -22,7 +22,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   <interface name="org.freedesktop.Telepathy.Channel.Interface.Hold">
     <tp:xor-requires>
       <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
-      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call.DRAFT"/>
+      <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.Call1"/>
+      <tp:requires interface="org.freedesktop.Telepathy.Call1.Content"/>
     </tp:xor-requires>
     <tp:changed version="0.17.4">first API-stable version</tp:changed>
 
@@ -31,7 +32,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         This only makes sense for channels where
         you are streaming media to or from the members. (To see whether the
         other participant has put you on hold, see <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Channel.Interface">CallState</tp:dbus-ref>.)</p>
+          namespace="org.freedesktop.Telepathy.Channel.Interface"
+        >CallState</tp:dbus-ref>.)</p>
 
       <p>If you place a channel on hold, this indicates that you do not wish
         to be sent media streams by any of its members and will be ignoring
@@ -40,6 +42,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         an actively used channel (e.g. in a GSM or PBX call, it will be
         necessary to place an active call on hold before you can start
         another call).</p>
+
+      <p>This can also be used for putting a single Content on hold, if the
+        protocol supports it (This interface is in the Channel namespace for
+        historical reasons).</p>
     </tp:docstring>
 
     <method name="GetHoldState" tp:name-for-bindings="Get_Hold_State">
@@ -107,14 +113,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           The connection manager is attempting to move to state Held, but
           has not yet completed that operation. It is unspecified whether
           any, all or none of the streams making up the channel are on hold.
+          Examining the Hold state of Call Contents (if applicable) may
+          provide more useful information.
         </tp:docstring>
       </tp:enumvalue>
 
       <tp:enumvalue value="3" suffix="Pending_Unhold">
         <tp:docstring>
-          The connection manager is attempting to move to state Held, but
+          The connection manager is attempting to move to state Unheld, but
           has not yet completed that operation. It is unspecified whether
           any, all or none of the streams making up the channel are on hold.
+          Examining the Hold state of Call Contents (if applicable) may
+          provide more useful information.
         </tp:docstring>
       </tp:enumvalue>
     </tp:enum>
diff --git a/spec/Channel_Interface_Media_Signalling.xml b/spec/Channel_Interface_Media_Signalling.xml
index 242c9528..58a222c1 100644
--- a/spec/Channel_Interface_Media_Signalling.xml
+++ b/spec/Channel_Interface_Media_Signalling.xml
@@ -21,6 +21,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   <interface name="org.freedesktop.Telepathy.Channel.Interface.MediaSignalling">
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
     <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>
+    <tp:changed version="0.24.0">The old-style Telepathy properties,
+      deprecated since March 2009, have been removed.</tp:changed>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for signalling a channel containing synchronised media
@@ -104,54 +106,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:docstring>
     </signal>
 
-    <tp:property name="nat-traversal" type="s">
-      <tp:deprecated version="0.17.22">Use the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Media.StreamHandler">NATTraversal</tp:dbus-ref>
-        property on the Media.StreamHandler, if available; use this
-        as a fallback.</tp:deprecated>
-      <tp:docstring>
-        A string indicating the NAT traversal techniques employed by the
-        streams within this channel if they do not have a <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Media.StreamHandler">NATTraversal</tp:dbus-ref>
-        property. The possible values are the same as for the NATTraversal
-        property on the streams.
-      </tp:docstring>
-    </tp:property>
-
-    <tp:property name="stun-server" type="s">
-      <tp:deprecated version="0.17.22">Use the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Media.StreamHandler">STUNServers</tp:dbus-ref>
-        property on the Media.StreamHandler, if available; use this
-        as a fallback.</tp:deprecated>
-      <tp:docstring>
-        The IP address or hostname of the STUN server to use for NAT traversal
-        if the individual streams do not specify one.
-      </tp:docstring>
-    </tp:property>
-
-    <tp:property name="stun-port" type="q">
-      <tp:deprecated version="0.17.22">Use the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Media.StreamHandler">STUNServers</tp:dbus-ref>
-        property on the Media.StreamHandler, if available; use this
-        as a fallback.</tp:deprecated>
-      <tp:docstring>
-      The UDP port number to use on the provided STUN server.
-      </tp:docstring>
-    </tp:property>
-
-    <tp:property name="gtalk-p2p-relay-token" type="s">
-      <tp:deprecated version="0.17.22">XMPP connection managers
-        supporting the Google Talk relay server SHOULD make the necessary
-        HTTP requests to find a username and password, and use those
-        to populate the <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Media.StreamHandler">RelayInfo</tp:dbus-ref>
-        property on the Media.StreamHandler.</tp:deprecated>
-      <tp:docstring>
-      The authentication token for use with the Google Talk peer-to-peer relay
-      server.
-      </tp:docstring>
-    </tp:property>
-
     <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
diff --git a/spec/Channel_Interface_Messages.xml b/spec/Channel_Interface_Messages.xml
index 62e83846..a88576dc 100644
--- a/spec/Channel_Interface_Messages.xml
+++ b/spec/Channel_Interface_Messages.xml
@@ -599,15 +599,66 @@ USA.</p>
 
             <dt>supersedes (s – <tp:type>Protocol_Message_Token</tp:type>)</dt>
             <dd>If present, this message supersedes a previous message,
-              identified by its <tt>protocol-token</tt> or
-              <tt>message-token</tt> header. The user interface MAY, for
-              example, choose to replace the superseded message with this
-              message, or grey out the superseded message.
+              identified by its <tt>message-token</tt> header. The user
+              interface MAY, for example, choose to replace the superseded
+              message with this message, or grey out the superseded message.
 
               <tp:rationale>Skype, for example, allows the user to amend
                 messages they have already sent (to correct typos,
                 etc.).</tp:rationale>
-              </dd>
+
+              Connection Managers SHOULD represent repeatedly edited messages
+              in the following form:
+              <pre>
+                message {token = a};
+                message {token = b, supersedes = a};
+                message {token = c, supersedes = a};
+              </pre>
+
+              <tp:rationale>The alternative form is:
+                <pre>
+                  message {token = a};
+                  message {token = b, supersedes = a};
+                  message {token = c, supersedes = b};
+                </pre>
+                but it is more difficult to implement in UIs/loggers, and it
+                breaks irrecoverably if message b is lost. If a CM is forced
+                to use this form, it should be tested extensively for
+                interoperability with existing clients.
+                </tp:rationale>
+
+              Clients should deal gracefully if the original message gets
+              lost, but one or more corrections to it get through:
+              <pre>
+                message {token = x} gets lost;
+                message {token = y, supersedes = x};
+                message {token = z, supersedes = x};
+              </pre>
+
+              <tp:rationale>This is the form that CMs will use to mean "I know
+                that this message was edited, but I don't know what it
+                originally said." It is often in the interests of the
+                remote side for message x to be lost (e.g. to hide
+                embarassing mistakes or sensitive information) so it might not
+                be possible to retrieve it (even on protocols with reliable
+                message-delivery guarantees).</tp:rationale></dd>
+
+            <dt>original-message-sent (x - <tp:type>Unix_Timestamp64</tp:type>)</dt>
+            <dd>The <tt>message-sent</tt> header of the message that this
+              one supersedes.
+              This key should only be present if <tt>supersedes</tt> is also
+              present. It MAY be used as a hint to help clients locate the
+              original message in its logs. If present, comparing the tuple
+              (original-message-sent, supersedes) with (message-sent,
+              message-token) SHOULD be enough to uniquely
+              identify the original message.</dd>
+
+            <dt>original-message-received (x - <tp:type>Unix_Timestamp64</tp:type>)</dt>
+            <dd>The <tt>message-received</tt> header of the message that this
+              one supersedes.
+              This key should only be present if <tt>supersedes</tt> is also
+              present. It MAY be used as a hint in a similar way to
+              <tt>original-message-sent</tt>.</dd>
 
             <dt>pending-message-id (u - <tp:type>Message_ID</tp:type>)</dt>
             <dd>The incoming message ID. This MUST NOT be present on outgoing
@@ -996,7 +1047,7 @@ USA.</p>
           recipient. If a delivery failure is detected later, this is
           signalled by receiving a message whose <code>message-type</code>
           header maps to
-          <tp:type>Channel_Text_Message_Type</tp:type>_Delivery_Report.
+          <tp:value-ref type="Channel_Text_Message_Type">Delivery_Report</tp:value-ref>.
           Similarly, if delivery is detected to have been successful
           (which is not possible in all protocols), a successful delivery
           report will be signalled.</p>
diff --git a/spec/Channel_Interface_Password.xml b/spec/Channel_Interface_Password.xml
index 4e201ddf..8f08627e 100644
--- a/spec/Channel_Interface_Password.xml
+++ b/spec/Channel_Interface_Password.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0" ?>
 <node name="/Channel_Interface_Password" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
   <tp:copyright>
-Copyright © 2005-2009 Collabora Limited
+Copyright © 2005-2011 Collabora Limited
 Copyright © 2005-2009 Nokia Corporation
 Copyright © 2006 INdT
   </tp:copyright>
@@ -29,6 +29,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           called now for the user to join the channel
         </tp:docstring>
       </tp:flag>
+      <tp:flag suffix="Hint" value="4">
+        <tp:added version="0.25.0"/>
+        <tp:docstring>
+          The <tp:dbus-ref namespace="ofdT.Channel.Interface">RoomConfig1.PasswordHint</tp:dbus-ref>
+          contains a hint for the password.
+        </tp:docstring>
+      </tp:flag>
     </tp:flags>
     <method name="GetPasswordFlags" tp:name-for-bindings="Get_Password_Flags">
       <arg direction="out" type="u" tp:type="Channel_Password_Flags"
@@ -90,14 +97,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     </method>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Interface for channels that may have a password set that users need
-    to provide before being able to join, or may be able to view or change
-    once they have joined the channel.</p>
+        to provide before being able to join. The
+        <tp:member-ref>GetPasswordFlags</tp:member-ref> method and the
+        associated <tp:member-ref>PasswordFlagsChanged</tp:member-ref>
+        signal indicate whether the user must now provide a password to join
+        the channel.</p>
 
-    <p>The <tp:member-ref>GetPasswordFlags</tp:member-ref> method and the
-    associated <tp:member-ref>PasswordFlagsChanged</tp:member-ref>
-    signal indicate whether the channel has a password, whether the user
-    must now provide it to join, and whether it can be viewed or changed
-    by the user.</p>
+      <p>Once the user has joined the channel, the current
+        password-protectedness of the room can be checked (and possibly
+        modified) using the <tp:dbus-ref
+        namespace='ofdT.Channel.Interface'>RoomConfig1</tp:dbus-ref>
+        interface, if implemented.</p>
     </tp:docstring>
   </interface>
 </node>
diff --git a/spec/Channel_Interface_Picture.xml b/spec/Channel_Interface_Picture.xml
new file mode 100644
index 00000000..fb2fcf3d
--- /dev/null
+++ b/spec/Channel_Interface_Picture.xml
@@ -0,0 +1,198 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_Picture"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+
+  <tp:copyright>Copyright © 2011 Collabora Ltd.</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.Channel.Interface.Picture1"
+             tp:causes-havoc="draft">
+    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:added version="0.25.0"/>
+    <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal"
+                value="true"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>An interface channels can implement to support a picture. Most
+        of the time this will be implemented by channels implementing
+        the <tp:dbus-ref
+        namespace="ofdT.Channel.Interface">Room2</tp:dbus-ref>
+        interface. Note that this interface is not restricted to
+        Text channels, and can also be used on Call channels.</p>
+
+      <tp:rationale>
+        This is a separate interface from
+        <tp:dbus-ref namespace="ofdT.Channel.Interface">RoomConfig1</tp:dbus-ref>
+        because (a) it's possible some protocol might support pictures for
+        1:1 chats; and (b) it avoids downloading an unwanted picture in a
+        GetAll request.
+      </tp:rationale>
+    </tp:docstring>
+
+    <method name="SetPicture" tp:name-for-bindings="Set_Picture">
+      <arg direction="in" type="ay" name="Picture">
+        <tp:docstring>The new picture.</tp:docstring>
+      </arg>
+      <arg direction="in" type="s" name="MIME_Type">
+        <tp:docstring>The MIME type.</tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Set the room's picture. Clients SHOULD look at the picture
+          flags before calling this method as the user might not have
+          permission to set the picture.</p>
+
+        <p>A successful return of this method indicates a successful
+          change in picture, but clients should still listen for changes
+          to the <tp:member-ref>Picture</tp:member-ref> property for
+          further changes by other users or the server.</p>
+      </tp:docstring>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            Picture is somehow invalid: e.g. unsupported MIME type,
+            too big, etc.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+      </tp:possible-errors>
+    </method>
+
+    <property name="Picture" tp:name-for-bindings="Picture"
+              type="(ays)" tp:type="Avatar" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The picture representing this channel.</p>
+
+        <p>This property may change during the lifetime of the channel and
+          MUST not be included in a channel request.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="Actor" tp:name-for-bindings="Actor"
+              type="s" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The normalized contact ID representing who last modified
+          the picture, or the empty string if it is not known.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="ActorHandle" tp:name-for-bindings="Actor_Handle"
+              type="u" tp:type="Contact_Handle" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The handle corresponding to <tp:member-ref>Actor</tp:member-ref>,
+        or 0 if the <tp:member-ref>Actor</tp:member-ref> is unknown.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="Timestamp" tp:name-for-bindings="Timestamp"
+              type="x" tp:type="Unix_Timestamp64" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A unix timestamp indicating when the picture was last
+         modified, or <code>INT_MAX64</code> if unknown.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="CanSet" tp:name-for-bindings="Can_Set"
+              type="b" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>TRUE if the <tp:member-ref>Picture</tp:member-ref> property
+          can be set by the user by calling
+          <tp:member-ref>SetPicture</tp:member-ref>, otherwise
+          FALSE.</p>
+
+        <p>If implementations are unsure of what this value should be
+          it SHOULD still be set to what it believes the value
+          is. As a result, clients should be aware that
+          <tp:member-ref>SetPicture</tp:member-ref> can still fail
+          even with this property set to TRUE.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="SupportedMIMETypes"
+      tp:name-for-bindings="Supported_MIME_Types"
+      type="as" access="read" tp:immutable="yes">
+      <tp:docstring>
+        An array of supported MIME types (e.g. "image/jpeg").
+        Clients MAY assume that the first type in this array is preferred.
+      </tp:docstring>
+    </property>
+
+    <property name="MinimumHeight"
+      tp:name-for-bindings="Minimum_Height"
+      type="u" access="read" tp:immutable="yes">
+      <tp:docstring>
+        The minimum height in pixels of the picture, which MAY be 0.
+      </tp:docstring>
+    </property>
+
+    <property name="MinimumWidth"
+      tp:name-for-bindings="Minimum_Width"
+      type="u" access="read" tp:immutable="yes">
+      <tp:docstring>
+        The minimum width in pixels of the picture, which MAY be 0.
+      </tp:docstring>
+    </property>
+
+    <property name="RecommendedHeight"
+      tp:name-for-bindings="Recommended_Height"
+      type="u" access="read" tp:immutable="yes">
+      <tp:docstring>
+        The recommended height in pixels of the picture, or 0 if
+        there is no preferred height.
+      </tp:docstring>
+    </property>
+
+    <property name="RecommendedWidth"
+      tp:name-for-bindings="Recommended_Width"
+      type="u" access="read" tp:immutable="yes">
+      <tp:docstring>
+        The recommended width in pixels of the picture, or 0 if
+        there is no preferred width.
+      </tp:docstring>
+    </property>
+
+    <property name="MaximumHeight"
+      tp:name-for-bindings="Maximum_Height"
+      type="u" access="read" tp:immutable="yes">
+      <tp:docstring>
+        The maximum height in pixels of the picture, or 0 if
+        there is no limit.
+      </tp:docstring>
+    </property>
+
+    <property name="MaximumWidth"
+      tp:name-for-bindings="Maximum_Width"
+      type="u" access="read" tp:immutable="yes">
+      <tp:docstring>
+        The maximum width in pixels of the picture, or 0 if
+        there is no limit.
+      </tp:docstring>
+    </property>
+
+    <property name="MaximumBytes"
+      tp:name-for-bindings="Maximum_Bytes"
+      type="u" access="read" tp:immutable="yes">
+      <tp:docstring>
+        The maximum size in bytes of the picture, or 0 if
+        there is no limit.
+      </tp:docstring>
+    </property>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_Room.xml b/spec/Channel_Interface_Room.xml
index ffdf4a96..92423b67 100644
--- a/spec/Channel_Interface_Room.xml
+++ b/spec/Channel_Interface_Room.xml
@@ -21,10 +21,9 @@
       02110-1301, USA.</p>
   </tp:license>
 
-  <interface name="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
-    tp:causes-havoc="experimental">
+  <interface name="org.freedesktop.Telepathy.Channel.Interface.Room2">
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
-    <tp:added version="0.19.11">(draft 1)</tp:added>
+    <tp:added version="0.24.0">(version 2)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Different IM protocols use a variety of ways to name chat rooms. The
@@ -40,7 +39,9 @@
           href="http://xmpp.org/extensions/xep-0045.html#createroom-unique"><acronym
           title="XMPP Extension Protocol">XEP</acronym>-0045 §10.1.4
         <q>Requesting a Unique Room Name</q></a> defines a protocol for
-        requesting a unique, opaque room name on the server.</p>
+        requesting a unique, opaque room name on the server. Note that
+        this interface is not restricted to Text channels, and can
+        also be used on Call channels.</p>
 
       <p>This interface intends to support and differentiate these mechanisms
         more clearly than the <tp:dbus-ref
@@ -61,7 +62,7 @@
           <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
           = <code>"#telepathy"</code>,
-          <tp:member-ref>RoomID</tp:member-ref> = <code>"#telepathy"</code>,
+          <tp:member-ref>RoomName</tp:member-ref> = <code>"#telepathy"</code>,
           <tp:member-ref>Server</tp:member-ref> = <code>""</code>, indicating
           that the room has a human-readable identifier, and is not confined to
           a particular server on the network.
@@ -82,7 +83,7 @@
           <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
           = <code>"0xdeadbeef"</code>,
-          <tp:member-ref>RoomID</tp:member-ref> = <code>""</code>,
+          <tp:member-ref>RoomName</tp:member-ref> = <code>""</code>,
           <tp:member-ref>Server</tp:member-ref> = <code>""</code>, indicating
           that the room has an identifier but no human-readable name.
         </li>
@@ -91,7 +92,7 @@
           <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
           = <code>None</code>,
-          <tp:member-ref>RoomID</tp:member-ref> = <code>""</code>,
+          <tp:member-ref>RoomName</tp:member-ref> = <code>""</code>,
           <tp:member-ref>Server</tp:member-ref> = <code>""</code>, indicating
           that the room has neither an identifier (so it cannot be re-joined
           later) nor a human-readable name.
@@ -105,7 +106,7 @@
           <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
           = <code>"jdev@conference.jabber.org"</code>,
-          <tp:member-ref>RoomID</tp:member-ref> = <code>"jdev"</code>,
+          <tp:member-ref>RoomName</tp:member-ref> = <code>"jdev"</code>,
           <tp:member-ref>Server</tp:member-ref> = <code>"conference.jabber.org"</code>.
         </li>
 
@@ -116,7 +117,7 @@
           <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
           = <code>"private-chat-11111x1x-11xx-111x-1111-111x1xx11x11@groupchat.google.com"</code>,
-          <tp:member-ref>RoomID</tp:member-ref> = <code>""</code>,
+          <tp:member-ref>RoomName</tp:member-ref> = <code>""</code>,
           <tp:member-ref>Server</tp:member-ref> =
           <code>"groupchat.google.com"</code>, indicating that the room has a
           persistent identifier, no human-readable name, and is hosted by a
@@ -131,7 +132,7 @@
           <tp:dbus-ref
           namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
           = <code>"lrcgsnthzvwm@conference.jabber.org"</code>,
-          <tp:member-ref>RoomID</tp:member-ref> = <code>""</code>,
+          <tp:member-ref>RoomName</tp:member-ref> = <code>""</code>,
           <tp:member-ref>Server</tp:member-ref> =
           <code>"conference.jabber.org"</code>, indicating that the room has a
           persistent identifier, no human-readable name, and is hosted by a
@@ -165,7 +166,7 @@
         >TargetHandle</tp:dbus-ref>.</p>
 
       <p>If, like IRC, the room identifiers are also human-readable, the
-        RCCs should also include RoomID in <var>Allowed_Properties</var>:</p>
+        RCCs should also include RoomName in <var>Allowed_Properties</var>:</p>
 
       <blockquote>
         <pre>
@@ -179,7 +180,7 @@
               >TargetID</tp:dbus-ref>,
               ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
               >TargetHandle</tp:dbus-ref>,
-              ...<tp:member-ref>RoomID</tp:member-ref>
+              ...<tp:member-ref>RoomName</tp:member-ref>
             ]
 ),
 
@@ -187,14 +188,14 @@
             >ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
                                         >Text</tp:dbus-ref>
           },
-  Allowed = [ ...<tp:member-ref>RoomID</tp:member-ref>,
+  Allowed = [ ...<tp:member-ref>RoomName</tp:member-ref>,
             ]
 )</pre></blockquote>
 
-      <p>Requests may specify the RoomID in place of
+      <p>Requests may specify the RoomName in place of
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref> or
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
-        . Note how <tp:member-ref>RoomID</tp:member-ref> appears
+        . Note how <tp:member-ref>RoomName</tp:member-ref> appears
         in <var>Allowed_Properties</var> of a different RCC because
         when <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
         >TargetHandleType</tp:dbus-ref> is omitted (or is None), both
@@ -202,7 +203,7 @@
         >TargetHandle</tp:dbus-ref> and
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
         >TargetID</tp:dbus-ref> must also be omitted.
-        <tp:member-ref>RoomID</tp:member-ref> is allowed in conjuction
+        <tp:member-ref>RoomName</tp:member-ref> is allowed in conjuction
         with
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref> or
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
@@ -221,7 +222,7 @@
         fallback conference server is specified on jabber connections in
         gabble.</p>
 
-      <p>If the protocol supports unnamed rooms, <tp:member-ref>RoomID</tp:member-ref>
+      <p>If the protocol supports unnamed rooms, <tp:member-ref>RoomName</tp:member-ref>
         should be fixed to the empty string, and
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
         should be None:</p>
@@ -233,7 +234,7 @@
                                         >Text</tp:dbus-ref>,
             ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel"
             >TargetHandleType</tp:dbus-ref>: None,
-            ...<tp:member-ref>RoomID</tp:member-ref>: "",
+            ...<tp:member-ref>RoomName</tp:member-ref>: "",
           },
   Allowed = [ ]
 )</pre></blockquote>
@@ -242,7 +243,7 @@
 
       <p>When explicitly joining a room, the CM cannot know whether the room
         ID is unique or not. As a result, if this is the case, adding an
-        empty string <tp:member-ref>RoomID</tp:member-ref> into the channel
+        empty string <tp:member-ref>RoomName</tp:member-ref> into the channel
         request will ensure the CM knows. For example:</p>
 
       <blockquote>
@@ -250,16 +251,16 @@
 { ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>,
   ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>: Room,
   ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>: "qwerasdfzxcv@conference.jabber.org",
-  ...<tp:member-ref>RoomID</tp:member-ref>: ""
+  ...<tp:member-ref>RoomName</tp:member-ref>: ""
 }</pre></blockquote>
 
-      <p>If <tp:member-ref>RoomID</tp:member-ref> features in
+      <p>If <tp:member-ref>RoomName</tp:member-ref> features in
         <var>Allowed_Properties</var> then the only value allowed in conjunction
         with <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
         or <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandle</tp:dbus-ref>
         is the empty string. Requests with conflicting
         <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>
-        and <tp:member-ref>RoomID</tp:member-ref> properties
+        and <tp:member-ref>RoomName</tp:member-ref> properties
         will fail with InvalidArgument.</p>
 
       <p>To create a XEP-0045 §10.1.4 uniquely-named room channel
@@ -269,7 +270,7 @@
       <blockquote>
         <pre>
 { ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>,
-  ...<tp:member-ref>RoomID</tp:member-ref>: ""
+  ...<tp:member-ref>RoomName</tp:member-ref>: ""
   ...<tp:member-ref>Server</tp:member-ref>: "conference.jabber.org"
 }</pre>
       </blockquote>
@@ -282,20 +283,20 @@
 { ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">Text</tp:dbus-ref>,
   ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>: Room,
   ...<tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>: "kajsdhkajshdfjkshdfjkhs@conference.jabber.org",
-  ...<tp:member-ref>RoomID</tp:member-ref>: ""
+  ...<tp:member-ref>RoomName</tp:member-ref>: ""
   ...<tp:member-ref>Server</tp:member-ref>: "conference.jabber.org"
 }</pre>
       </blockquote>
 
       <p>The CM will have received the unique room name (kajsdhkajshdfjkshdfjkhs)
         and then created a room with such a name on the said server. The empty
-        <tp:member-ref>RoomID</tp:member-ref> property shows that the room name
+        <tp:member-ref>RoomName</tp:member-ref> property shows that the room name
         is not human-readable.</p>
 
     </tp:docstring>
 
-    <property name="RoomID" tp:name-for-bindings="Room_ID" type="s"
-              access="read">
+    <property name="RoomName" tp:name-for-bindings="Room_Name" type="s"
+              access="read" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The human-readable identifier of a chat room. Note that if
           non-empty, this property (and perhaps also
@@ -303,7 +304,10 @@
           a channel request to join the room. XMPP MUCs have a room name
           concept which is more like a topic, except more
           persistent. This D-Bus property is <strong>not</strong> this
-          XMPP room name, but the bit before the @ in the room jid.</p>
+          XMPP room name, but the bit before the @ in the room jid; see
+          <tp:dbus-ref
+          namespace='ofdT.Channel.Interface'>RoomConfig1.Title</tp:dbus-ref>
+          for that concept.</p>
 
         <p>This property cannot change during the lifetime of the channel. It
           should appear in the <var>Allowed_Properties</var> of a
@@ -314,7 +318,7 @@
     </property>
 
     <property name="Server" tp:name-for-bindings="Server" type="s"
-              access="read">
+              access="read" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>For protocols with a concept of chatrooms on multiple servers with
           different DNS names (like XMPP), the DNS name of the server hosting
@@ -329,42 +333,33 @@
       </tp:docstring>
     </property>
 
-    <tp:struct name="Room_Subject">
-      <tp:docstring>
-        A struct representing the subject of a room channel.
-      </tp:docstring>
-      <tp:member type="s" name="Subject">
-        <tp:docstring>
-           A human-readable description of the current subject of
-           conversation in the channel, similar to /topic in IRC.
-        </tp:docstring>
-      </tp:member>
-      <tp:member type="s" name="Actor">
-        <tp:docstring>
-           A normalized contact ID representing who last modified the
-           subject, or the empty string if it is not known.
-        </tp:docstring>
-      </tp:member>
-      <tp:member type="x" tp:type="Unix_Timestamp64" name="Timestamp">
-        <tp:docstring>
-           A unix timestamp indicating when the subject was last modified.
-        </tp:docstring>
-      </tp:member>
-    </tp:struct>
-
-    <property name="Subject" tp:name-for-bindings="Subject"
-              type="(ssx)" tp:type="Room_Subject" access="read">
+    <property name="Creator" tp:name-for-bindings="Creator"
+              type="s" access="read" tp:immutable="yes">
+      <tp:added version="0.25.0"/>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The subject on the room such as the topic in an IRC channel,
-          or the room name in XMPP MUCs. In protocols which do not support
-          subjects (like MSN), this property should be ("", "", 0).</p>
+        The normalized contact ID representing who created the room; or
+        the empty string if unknown.
+      </tp:docstring>
+    </property>
 
-        <tp:rationale>This property replaces the subject, subject-contact, and
-          subject-timestamp Telepathy properties of Text channels, as Telepathy
-          properties are soon to be deprecated completely.</tp:rationale>
+    <property name="CreatorHandle" tp:name-for-bindings="Creator_Handle"
+              type="u" tp:type="Contact_Handle" access="read"
+              tp:immutable="yes">
+      <tp:added version="0.25.0"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        The handle corresponding to <tp:member-ref>Creator</tp:member-ref>;
+        or 0 if <tp:member-ref>Creator</tp:member-ref> is unknown.
+      </tp:docstring>
+    </property>
 
-        <p>This property may change during the lifetime of the channel and
-          MUST not be included in a channel request.</p>
+    <property name="CreationTimestamp"
+              tp:name-for-bindings="Creation_Timestamp"
+              type="x" tp:type="Unix_Timestamp64" access="read"
+              tp:immutable="yes">
+      <tp:added version="0.25.0"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        A unix timestamp indicating when the room was created; or
+        <code>INT_MAX64</code> if unknown.
       </tp:docstring>
     </property>
 
diff --git a/spec/Channel_Interface_Room_Config.xml b/spec/Channel_Interface_Room_Config.xml
new file mode 100644
index 00000000..18bb06f0
--- /dev/null
+++ b/spec/Channel_Interface_Room_Config.xml
@@ -0,0 +1,267 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_Room_Config"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+
+  <tp:copyright>Copyright © 2011 Collabora Ltd.</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.Channel.Interface.RoomConfig1">
+    <tp:added version="0.24.0">version 1. This replaces the old-school
+      Telepathy properties on <tp:dbus-ref
+      namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>.</tp:added>
+    <tp:requires interface='org.freedesktop.Telepathy.Channel.Interface.Room2'/>
+    <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal"
+                value="true"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>Represents the configuration of a chatroom, some aspects of which may
+        be modifiable by the user, depending on their priviledges. This
+        corresponds to the room configuration on XMPP, and various channel mode
+        flags on IRC.</p>
+
+      <p>The “topic” (on IRC) or “subject” (on XMPP) is not part of this
+        interface; it can be found on the <tp:dbus-ref
+        namespace='ofdT.Channel.Interface'>Subject2</tp:dbus-ref>
+        interface.</p>
+    </tp:docstring>
+
+    <property name="Anonymous" tp:name-for-bindings="Anonymous" type="b" access="read">
+      <tp:docstring>
+      <code>True</code> if people may join the channel without other members being made
+      aware of their identity.
+      </tp:docstring>
+    </property>
+    <property name="InviteOnly" tp:name-for-bindings="InviteOnly" type="b" access="read">
+      <tp:docstring>
+      <code>True</code> if people may not join the channel until they have been invited.
+      </tp:docstring>
+    </property>
+    <property name="Limit" tp:name-for-bindings="Limit" type="u" access="read">
+      <tp:docstring>
+      The limit to the number of members; or <tt>0</tt> if there is no limit.
+      </tp:docstring>
+    </property>
+    <property name="Moderated" tp:name-for-bindings="Moderated" type="b" access="read">
+      <tp:docstring>
+      <code>True</code> if channel membership is not sufficient to allow participation.
+      </tp:docstring>
+    </property>
+    <property name="Title" tp:name-for-bindings="Title" type="s" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      A human-visible name for the channel, if it differs from <tp:dbus-ref
+      namespace='ofdT.Channel.Interface'>Room2.RoomName</tp:dbus-ref>; the
+      empty string, otherwise.
+
+      <tp:rationale>
+        <p>On XMPP, this represents the <code>muc#roomconfig_roomname</code>
+        field of the <a
+        href='http://xmpp.org/extensions/xep-0045.html#registrar-formtype-owner'><code>muc#roomconfig</code></a>
+        form. So for <code>jdev@conference.jabber.org</code>, for example:</p>
+
+        <ul>
+          <li><tp:dbus-ref
+            namespace='ofdT.Channel.Interface'>Room2.RoomName</tp:dbus-ref>
+            = <code>"jdev"</code>;</li>
+          <li><tp:dbus-ref
+            namespace='ofdT.Channel.Interface'>Room2.Server</tp:dbus-ref>
+            = <code>"conference.jabber.org"</code>;</li>
+          <li><tp:member-ref>Title</tp:member-ref> = <code>"General Jabber
+            development discussion"</code>.</li>
+        </ul>
+
+        <p>XEP-0045 is awful.</p>
+      </tp:rationale>
+      </tp:docstring>
+    </property>
+    <property name="Description" tp:name-for-bindings="Description" type="s" access="read">
+      <tp:docstring>
+      A human-readable description of the channel's overall purpose; if any.
+      </tp:docstring>
+    </property>
+    <property name="Persistent" tp:name-for-bindings="Persistent" type="b" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <code>True</code> if the channel will remain in existence on the server after all
+      members have left it.
+      </tp:docstring>
+    </property>
+    <property name="Private" tp:name-for-bindings="Private" type="b" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <code>True</code> if the channel is not visible to non-members.
+      </tp:docstring>
+    </property>
+
+    <property name="PasswordProtected" type="b" access="read"
+              tp:name-for-bindings="Password_Protected">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <code>True</code> if contacts joining this channel must provide a
+        password to be granted entry.  Note that this property does not
+        indicate that a password is required <em>right now</em>; see the
+        <tp:dbus-ref namespace='ofdT.Channel.Interface'>Password</tp:dbus-ref>
+        interface for the API used to provide a password while joining a room.
+      </tp:docstring>
+    </property>
+
+    <property name="Password" tp:name-for-bindings="Password" type="s" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        If <tp:member-ref>PasswordProtected</tp:member-ref> is
+        <code>True</code>, the password required to enter the channel, if
+        known. If the password is unknown, or
+        <tp:member-ref>PasswordProtected</tp:member-ref> is
+        <code>False</code>, the empty string.
+
+        <tp:rationale>
+          On XMPP—bless its cotton socks!—non-owners of a MUC cannot see its
+          current password, even if they just provided the password in order to
+          join the room…
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="PasswordHint" tp:name-for-bindings="Password_Hint"
+              type="s" access="read">
+      <tp:added version="0.25.0"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If <tp:member-ref>PasswordProtected</tp:member-ref> is
+          <code>True</code>, an optional hint for the password.</p>
+
+        <p>On protocols supporting PasswordHint (indicated by its presence
+          in <tp:member-ref>MutableProperties</tp:member-ref>),
+          <tp:member-ref>Password</tp:member-ref> and PasswordHint MUST be
+          set in a single call to
+          <tp:member-ref>UpdateConfiguration</tp:member-ref>.</p>
+
+        <tp:rationale>
+          Skype requires that the password and its hint be supplied together.
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="CanUpdateConfiguration" type="b" access="read"
+              tp:name-for-bindings="Can_Update_Configuration">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        If <code>True</code>, the user may call
+        <tp:member-ref>UpdateConfiguration</tp:member-ref> to change the values
+        of the properties listed in
+        <tp:member-ref>MutableProperties</tp:member-ref>.
+      </tp:docstring>
+    </property>
+
+    <property name="MutableProperties" type="as" access="read"
+              tp:name-for-bindings="Mutable_Properties">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A list of (unqualified) property names on this interface which may
+          be modified using <tp:member-ref>UpdateConfiguration</tp:member-ref>
+          (if <tp:member-ref>CanUpdateConfiguration</tp:member-ref> is
+          <code>True</code>). Properties not listed here cannot be
+          modified.</p>
+
+        <p>For example, IRC does not have the concept of joining a room without
+          other participants knowing your true identity; so on IRC the
+          <tp:member-ref>Anonymous</tp:member-ref> property will always be
+          <code>False</code>, and
+          <tp:member-ref>MutableProperties</tp:member-ref> will not include
+          <code>"Anonymous"</code>.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="ConfigurationRetrieved" type="b" access="read"
+              tp:name-for-bindings="Configuration_Retrieved">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p><code>True</code> once the initial room configuration has been
+          retrieved, or <code>False</code> otherwise. On some services, this
+          may take some time after you've joined a room to fetch the
+          configuration. Once this property changes to <code>True</code>, the
+          other properties on this interface can be assumed to be accurate;
+          this property MUST not change to <code>False</code> after it becomes
+          <code>True</code>.</p>
+
+        <tp:rationale>
+          <p>An application's “configure this room” dialog might choose to
+            display a spinner while this property is <code>False</code>, rather
+            than allowing the user to edit probably-inaccurate
+            configuration.</p>
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <method name="UpdateConfiguration" tp:name-for-bindings="Update_Configuration">
+      <arg direction="in" name="Properties" type="a{sv}">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>
+            The new values of one or more properties on this interface, which
+            must be listed in
+            <tp:member-ref>MutableProperties</tp:member-ref>. For
+            instance, to set up a channel for discussing top-secret corporate
+            merge plans, this parameter might be:
+          </p>
+
+          <blockquote>
+            <pre>{
+  'Private': True,
+  'InviteOnly': True,
+  'Description': "The first rule of #inteltakeover is: do not talk about #inteltakeover",
+}</pre></blockquote>
+        </tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>If <tp:member-ref>CanUpdateConfiguration</tp:member-ref> is
+          <code>True</code>, modifies the current values of one or more
+          room properties. This method SHOULD NOT return until the change has
+          been accepted or declined by the server.</p>
+
+        <p>Note that the server may ostensibly accept the changes (thus
+          allowing this method to return success) but signal different values;
+          for example, the server might truncate
+          <tp:member-ref>Title</tp:member-ref> to some maximum length. Callers
+          SHOULD continue to listen for the <code>PropertiesChanged</code>
+          signal, and trust the values it signals over those provided to this
+          method.</p>
+      </tp:docstring>
+
+      <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The user is not allowed to reconfigure this room.
+        </tp:docstring>
+      </tp:error>
+
+      <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          One or more of the specified properties is unknown, or ill-typed.
+        </tp:docstring>
+      </tp:error>
+
+      <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          One or more of the specified properties cannot be modified on this
+          protocol.
+        </tp:docstring>
+      </tp:error>
+
+      <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The room's current configuration has not yet been retrieved, so we
+          cannot update it just yet. The application might like to try again
+          once the <tp:member-ref>ConfigurationRetrieved</tp:member-ref>
+          property becomes <code>True</code>.
+        </tp:docstring>
+      </tp:error>
+    </method>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_SMS.xml b/spec/Channel_Interface_SMS.xml
index 4cfe3f2f..497e9451 100644
--- a/spec/Channel_Interface_SMS.xml
+++ b/spec/Channel_Interface_SMS.xml
@@ -50,7 +50,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 { ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
       ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
   ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
-      <tp:type>Handle_Type</tp:type>_Contact,<br/>
+      <tp:value-ref type="Handle_Type">Contact</tp:value-ref>,<br/>
   ...<tp:dbus-ref namespace='ofdT.Channel.Interface'>SMS.Flash</tp:dbus-ref>:
       True,<br/>
 }</code></blockquote>
@@ -59,6 +59,36 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         namespace='ofdT.Client.Handler'>BypassApproval</tp:dbus-ref> property
         to <code>True</code>, so that it is invoked immediately for new
         channels.</p>
+
+      <h4>Contact Capabilities</h4>
+
+      <p>Contacts to whom SMSes can be sent SHOULD indicate this via a
+        requestable channel class with
+        <tp:member-ref>SMSChannel</tp:member-ref> = True as a fixed
+        property.</p>
+
+      <p>For instance, a contact that can accept both text and SMS channels:</p>
+
+      <blockquote><code>
+[<br/>
+ ({ ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
+     ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
+    ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
+       <tp:value-ref type="Handle_Type">Contact</tp:value-ref>,<br/>
+  },<br/>
+  [ ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref>,
+    ...<tp:dbus-ref namespace='ofdT.Channel'>TargetID</tp:dbus-ref> ]),<br/>
+<br/>
+ ({ ...<tp:dbus-ref namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>:
+       ...<tp:dbus-ref namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>,<br/>
+    ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>:
+       <tp:value-ref type="Handle_Type">Contact</tp:value-ref>,<br/>
+    ...<tp:member-ref>SMSChannel</tp:member-ref>: True,<br/>
+  },<br/>
+  [ ...<tp:dbus-ref namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref>,
+    ...<tp:dbus-ref namespace='ofdT.Channel'>TargetID</tp:dbus-ref> ]),<br/>
+]
+      </code></blockquote>
     </tp:docstring>
 
     <property name="Flash" tp:name-for-bindings="Flash"
@@ -175,5 +205,83 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <tp:member-ref>SMSChannel</tp:member-ref> property.
       </tp:docstring>
     </signal>
+
+    <method name="GetSMSLength"
+            tp:name-for-bindings="Get_SMS_Length">
+      <tp:added version="0.23.1"/>
+
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Returns the number of 140 octet chunks required to send a message
+          via SMS, as well as the number of remaining characters available in
+          the final chunk and, if possible, an estimate of the cost.</p>
+
+        <tp:rationale>
+          <p>There are a number of different SMS encoding mechanisms, and the
+            client doesn't know which mechanisms an individual CM might support.
+            This method allows the client, without any knowledge of the
+            encoding mechanism, to provide length details to the user.</p>
+        </tp:rationale>
+
+        <p>Clients SHOULD limit the frequency with which this method is called
+        and SHOULD NOT call it for every keystroke. Clients MAY estimate the
+        remaining size between single keystrokes.</p>
+      </tp:docstring>
+
+      <arg name="Message" type="aa{sv}" tp:type="Message_Part[]" direction="in">
+        <tp:docstring>
+          The message the user wishes to send.
+        </tp:docstring>
+      </arg>
+
+      <arg name="Chunks_Required" type="u" direction="out">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The number of 140 octet chunks required to send this message.</p>
+
+          <p>For example, in the GSM standard 7-bit encoding, a 162 character
+            message would require 2 chunks.</p>
+        </tp:docstring>
+      </arg>
+
+      <arg name="Remaining_Characters" type="i" direction="out">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The number of further characters that can be fit in the final
+            chunk. A negative value indicates that the message will be
+            truncated by <code>abs(Remaining_Characters)</code>. The value
+            <code>MIN_INT32</code> (<code>-2<sup>31</sup></code>)
+            indicates the message will be truncated by an unknown amount.</p>
+
+          <p>For example, in the GSM standard 7-bit encoding, a 162 character
+            message would return 144 remaining characters (because of the
+            space required for the multipart SMS header).</p>
+        </tp:docstring>
+      </arg>
+
+      <arg name="Estimated_Cost" type="i" direction="out">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The estimated cost of sending this message. The currency and
+            scale of this value are the same as the
+            <tp:dbus-ref namespace="ofdT.Connection.Interface">Balance.AccountBalance</tp:dbus-ref>
+            property.</p>
+
+          <p>A value of <code>-1</code> indicates the cost could not be
+            estimated.</p>
+
+        </tp:docstring>
+      </arg>
+
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
+          <tp:docstring>
+            Raised when the method is not available on this channel.
+            Clients MAY choose to make their own estimation.
+          </tp:docstring>
+        </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
+          <tp:docstring>
+            Raised when the content cannot be encoded into a valid SMS.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
   </interface>
 </node>
diff --git a/spec/Channel_Interface_Subject.xml b/spec/Channel_Interface_Subject.xml
new file mode 100644
index 00000000..fcaf3983
--- /dev/null
+++ b/spec/Channel_Interface_Subject.xml
@@ -0,0 +1,128 @@
+<?xml version="1.0" ?>
+<node name="/Channel_Interface_Subject"
+  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
+
+  <tp:copyright>Copyright © 2010–2011 Collabora Ltd.</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.Channel.Interface.Subject2">
+    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:added version="0.24.0">(version 2)</tp:added>
+    <annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal"
+                value="true"/>
+
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>An interface channels can implement to support subjects. Most
+        of the time this will be implemented by channels implementing
+        the <tp:dbus-ref
+        namespace="ofdT.Channel.Interface">Room2</tp:dbus-ref>
+        interface, but some protocols support subjects in 1-to-1 chats
+        (such as XMPP). Note that this interface is not restricted to
+        Text channels, and can also be used on Call channels.</p>
+    </tp:docstring>
+
+    <method name="SetSubject" tp:name-for-bindings="Set_Subject">
+      <arg direction="in" type="s" name="Subject">
+        <tp:docstring>The new subject.</tp:docstring>
+      </arg>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Set the room's subject. Clients SHOULD look at the subject
+          flags before calling this method as the user might not have
+          permission to set the subject.</p>
+
+        <p>A successful return of this method indicates a successful
+          change in subject, but clients should still listen for changes
+          to the <tp:member-ref>Subject</tp:member-ref> property for
+          further changes by other users or the server.</p>
+      </tp:docstring>
+      <tp:possible-errors>
+        <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented"/>
+        <tp:error name="org.freedesktop.Telepathy.Error.PermissionDenied"/>
+      </tp:possible-errors>
+    </method>
+
+    <property name="Subject" tp:name-for-bindings="Subject"
+              type="s" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The human-readable subject on the channel such as the topic
+          in an IRC channel, or the room name in XMPP MUCs.</p>
+
+        <tp:rationale>This property replaces the subject Telepathy
+          property of Text channels, as Telepathy properties are soon to
+          be deprecated completely.</tp:rationale>
+
+        <p>This property may change during the lifetime of the channel and
+          MUST not be included in a channel request.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="Actor" tp:name-for-bindings="Actor"
+              type="s" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The normalized contact ID representing who last modified
+          the subject, or the empty string if it is not known.</p>
+
+        <tp:rationale>This property replaces the subject-contact
+          Telepathy property of Text channels, as Telepathy properties
+          are soon to be deprecated completely.</tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="ActorHandle" tp:name-for-bindings="Actor_Handle"
+              type="u" tp:type="Contact_Handle" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The handle corresponding to <tp:member-ref>Actor</tp:member-ref>,
+        or 0 if the <tp:member-ref>Actor</tp:member-ref> is unknown.</p>
+      </tp:docstring>
+    </property>
+
+    <property name="Timestamp" tp:name-for-bindings="Timestamp"
+              type="x" tp:type="Unix_Timestamp64" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>A unix timestamp indicating when the subject was last
+         modified, or <code>INT_MAX64</code> if unknown.</p>
+
+        <tp:rationale>This property replaces the subject-timestamp
+          Telepathy property of Text channels, as Telepathy properties
+          are soon to be deprecated completely.</tp:rationale>
+      </tp:docstring>
+    </property>
+
+    <property name="CanSet" tp:name-for-bindings="Can_Set"
+              type="b" access="read">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>TRUE if the <tp:member-ref>Subject</tp:member-ref> property
+          can be set by the user by calling
+          <tp:member-ref>SetSubject</tp:member-ref>, otherwise
+          FALSE.</p>
+
+        <p>If implementations are unsure of what this value should be
+          it SHOULD still be set to what it believes the value
+          is. As a result, clients should be aware that
+          <tp:member-ref>SetSubject</tp:member-ref> can still fail
+          even with this property set to TRUE.</p>
+
+        <tp:rationale>In XMPP it is impossible to know whether an
+          occupant can set the subject as XMPP server implementations
+          are wildly inconsistent.</tp:rationale>
+      </tp:docstring>
+    </property>
+
+  </interface>
+</node>
+<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Channel_Interface_Tube.xml b/spec/Channel_Interface_Tube.xml
index 858a15dd..f31ab213 100644
--- a/spec/Channel_Interface_Tube.xml
+++ b/spec/Channel_Interface_Tube.xml
@@ -204,15 +204,24 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       array-name="Socket_Access_Control_List">
       <tp:enumvalue suffix="Localhost" value="0">
         <tp:docstring>
-          The IP or Unix socket can be accessed by any local user (e.g.
-          a Unix socket that accepts all local connections, or an IP socket
-          listening on 127.0.0.1 (or ::1) or rejecting connections not from
-          that address). The associated variant must be ignored.
+          <p>The IP or Unix socket can be accessed by any local user (e.g.
+            a Unix socket that accepts all local connections, or an IP socket
+            listening on 127.0.0.1 (or ::1) or rejecting connections not from
+            that address). The associated variant must be ignored.</p>
+
+          <p>For a D-Bus tube, this means that the "same user" access
+            control typically provided by default in D-Bus implementations
+            SHOULD be disabled. If the socket is only available to local users
+            (e.g. a Unix socket, an IPv4 socket bound to 127.0.0.1, or an
+            IPv6 socket bound to ::1), the <code>ANONYMOUS</code>
+            authentication mechanism MAY be enabled.</p>
         </tp:docstring>
       </tp:enumvalue>
       <tp:enumvalue suffix="Port" value="1">
         <tp:docstring>
-          May only be used on IP sockets. The associated variant must contain
+          May only be used on IP sockets, and only for Stream tubes.
+          <!-- ... and maybe Datagram tubes, one day... -->
+          The associated variant must contain
           a struct Socket_Address_IPv4 (or Socket_Address_IPv6)
           containing the string form of an IP address of the appropriate
           version, and a port number. The socket can only be accessed if the
@@ -235,19 +244,41 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:enumvalue>
       <tp:enumvalue suffix="Credentials" value="3">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>May only be used on UNIX sockets.
+          <p>The high-level meaning of this access control type is that
+            only the same user (e.g. same numeric Unix uid) is allowed to
+            interact with the tube. Exactly how this is achieved varies by
+            channel type.</p>
+
+          <p>For <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
+              >StreamTube</tp:dbus-ref> channels, this access control type
+            may only be used on UNIX sockets.
             The connecting process must send a byte when
             it first connects, which is not considered to be part of the data
             stream. If the operating system uses sendmsg() with SCM_CREDS or
             SCM_CREDENTIALS to pass credentials over sockets, the connecting
             process must do so if possible; if not, it must still send the
-            byte.</p>
+            byte, without any attached credentials. (This mechanism is
+            very similar to the first byte of a D-Bus connection, except that
+            in D-Bus the byte is always zero, whereas in Tubes it can be
+            nonzero.)</p>
+
+          <p>For <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type"
+              >DBusTube</tp:dbus-ref> channels, this access control type
+            may be used on any type of socket, and there is no extra byte
+            added by Telepathy at the beginning of the stream: all bytes in
+            the stream are part of the D-Bus tube connection. The connecting
+            process should prove its identity via any of the SASL
+            authentication mechanisms usually used for D-Bus (in typical
+            D-Bus implementations this involves either sending and receiving
+            credentials as above, or demonstrating the ability to write to a
+            file in the user's home directory).</p>
 
-          <p>The listening process will disconnect the connection unless it
-            can determine by OS-specific means that the connecting process
-            has the same user ID as the listening process.</p>
+          <p>In either case, the listening process will disconnect the
+            connection unless it can determine by OS-specific means that
+            the connecting process has the same user ID as the listening
+            process.</p>
 
-          <p>The associated variant must be ignored.</p>
+          <p>In either tube type, the associated variant must be ignored.</p>
         </tp:docstring>
       </tp:enumvalue>
     </tp:enum>
diff --git a/spec/Channel_Request.xml b/spec/Channel_Request.xml
index fbb67925..dd10049e 100644
--- a/spec/Channel_Request.xml
+++ b/spec/Channel_Request.xml
@@ -218,7 +218,7 @@
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A dictionary of metadata provided by the channel
           requester, which the handler and other clients MAY choose to
-          interpret.  Currently no standard keys are defined; clients MAY
+          interpret.  Clients MAY
           choose to use platform-specific keys for their own purposes, but MUST
           ignore unknown keys and MUST cope with expected keys being
           missing. Clients SHOULD namespace hint names by having them
@@ -249,6 +249,48 @@
           namespace="ofdT.Client.Interface.Requests">AddRequest</tp:dbus-ref>
           by the <tp:dbus-ref
           namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>.</p>
+        <p>The following standardised hints are defined:</p>
+
+        <dl>
+          <dt>org.freedesktop.Telepathy.ChannelRequest.DelegateToPreferredHandler - b</dt>
+          <dd>If present and True the client currently handling the channel
+            SHOULD pass the channel to the
+            <tp:member-ref>PreferredHandler</tp:member-ref> using
+            <tp:dbus-ref namespace="ofdT.ChannelDispatcher">DelegateChannels</tp:dbus-ref>.
+
+            <tp:rationale>
+              This hint allows the user to request a channel in their
+              preferred client in a situation where there are two chat
+              handlers (for example: requesting a channel in Empathy which is
+              currently being handled by gnome-shell).
+            </tp:rationale>
+
+            If the channel is currently unhandled, clients SHOULD ignore this
+            hint.
+
+            <tp:rationale>
+              It is assumed that Mission Control will correctly delegate an
+              unhandled channel to the preferred Handler. This allows
+              requesting clients to always include this hint in their channel
+              request.
+            </tp:rationale>
+
+            The Handler should check each
+            <tp:dbus-ref namespace="ofdT">ChannelRequest</tp:dbus-ref>
+            of the Requests_Satisfied parameter of
+            <tp:dbus-ref namespace="ofdT.Client.Handler">HandleChannels</tp:dbus-ref>
+            for the hint. The first request containing the hint SHOULD be used
+            and all further hints SHOULD be ignored.
+
+            <tp:rationale>
+              This covers the very unlikely case where
+              <tp:dbus-ref namespace="ofdT.Client.Handler">HandleChannels</tp:dbus-ref>
+              satisfies two separate requests which have different
+              <tp:member-ref>PreferredHandler</tp:member-ref>s.
+            </tp:rationale>
+          </dd>
+        </dl>
+
       </tp:docstring>
     </property>
 
diff --git a/spec/Channel_Type_Call.xml b/spec/Channel_Type_Call.xml
index 045d4169..0ea1319c 100644
--- a/spec/Channel_Type_Call.xml
+++ b/spec/Channel_Type_Call.xml
@@ -17,11 +17,13 @@ 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"
+  <interface name="org.freedesktop.Telepathy.Channel.Type.Call1"
       tp:causes-havoc="experimental">
     <tp:added version="0.19.0">(draft 1)</tp:added>
 
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
+    <tp:requires
+      interface="org.freedesktop.Telepathy.Call1.Interface.Mute"/>
     <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
@@ -52,7 +54,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
       <h4>Contents</h4>
 
-      <p><tp:dbus-ref namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>
+      <p><tp:dbus-ref namespace="ofdT.Call1">Content</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. As a
@@ -62,10 +64,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         as the Requestable Channel Classes will document.</p>
 
       <p><tp:dbus-ref
-        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> objects have
+        namespace="ofdT.Call1">Content</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>
+        <tp:dbus-ref namespace="ofdT.Call1">Content</tp:dbus-ref>
         interface page.</p>
 
       <h4>Outgoing calls</h4>
@@ -77,7 +79,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <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>,
+      namespace="ofdT.Channel.Type">Call1</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,
@@ -100,26 +102,31 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
       <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
+        <tp:value-ref type="Call_State">Pending_Initiator</tp:value-ref>. 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>
+        to <tp:value-ref type="Call_State">Initialising</tp:value-ref>, which signifies
+        that the call is waiting for the network to do
+        something. When the CM has information indicating that the remote contact has been
+        notified about the call (or immediately if the network is known not to convey such
+        information) it should also change to
+        <tp:value-ref type="Call_State">Ringing</tp:value-ref>. All changes to
+        the <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>
+        <tp:value-ref type="Call_State">Accepted</tp:value-ref>.</p>
 
       <p>At this point <a
         href="http://telepathy.freedesktop.org/doc/telepathy-farstream/">telepathy-farstream</a>
         will signal that a pad is available for the handler to show
-        in the user interface.</p>
+        in the user interface. Once media is correctly flowing in both
+        directions, the state will change to
+        <tp:value-ref type="Call_State">Active</tp:value-ref>, to inform the user that they
+        have a correctly working call there is nothing amiss.</p>
 
       <h5>Missed calls</h5>
 
@@ -129,10 +136,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         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:value-ref type="Call_State">Ended</tp:value-ref>, 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>
+        <tp:value-ref type="Call_State_Change_Reason">No_Answer</tp:value-ref>, "").</p>
 
       <h5>Rejected calls</h5>
 
@@ -140,10 +147,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         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:value-ref type="Call_State">Ended</tp:value-ref> and the
         <tp:member-ref>CallStateReason</tp:member-ref> property
         changing to (remote contact,
-        <tp:type>Call_State</tp:type>_Change_Reason_User_Requested,
+        <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
         "org.freedesktop.Telepathy.Error.Rejected").</p>
 
       <h4>Incoming calls</h4>
@@ -159,7 +166,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
   /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>,
+      namespace="ofdT.Channel.Type">Call1</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,
@@ -186,24 +193,26 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         The new channel should also be given to telepathy-farstream to
         work out how the two participants will connect together.
         telepathy-farstream will call the appropriate methods on the call's
-        <tp:dbus-ref namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>s
+        <tp:dbus-ref namespace="ofdT.Call1">Content</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
+        <tp:value-ref type="Call_State">Accepted</tp:value-ref> and once media is
         being transferred, telepathy-farstream will notify the
         handler of a new pad to be shown to the local user in the
-        UI</p>
+        UI. Once media is correctly flowing in both directions, the state will
+        change to <tp:value-ref type="Call_State">Active</tp:value-ref>, to inform the user
+        that they have a correctly working call there is nothing amiss.</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:value-ref type="Call_State">Ended</tp:value-ref> 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,
+        <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
         "org.freedesktop.Telepathy.Error.Rejected").</p>
 
       <h4>Ongoing calls</h4>
@@ -221,7 +230,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
       <blockquote>
         <pre><tp:member-ref>AddContent</tp:member-ref>("video",
-           <tp:type>Media_Stream_Type</tp:type>_Video)</pre>
+           <tp:value-ref type="Media_Stream_Type">Video</tp:value-ref>)</pre>
       </blockquote>
 
       <p>Assuming no errors, the new video content will be added to
@@ -232,142 +241,42 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
       <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
+        namespace="ofdT.Call1.Content">Remove</tp:dbus-ref> method
         is on the <tp:dbus-ref
-        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> object.</p>
+        namespace="ofdT.Call1">Content</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:value-ref type="Call_State">Ended</tp:value-ref> and
         <tp:member-ref>CallStateReason</tp:member-ref> will change
         to (self handle,
-        <tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
+        <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
         "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:value-ref type="Call_State">Ended</tp:value-ref> and
         <tp:member-ref>CallStateReason</tp:member-ref> will change
         to (remote contact,
-        <tp:type>Call_State_Change_Reason</tp:type>_User_Requested,
+        <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
         "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
+        namespace="ofdT.Channel.Type">Call1</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>,
+[( Fixed = { ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="ofdT.Channel.Type">Call1</tp:dbus-ref>,
             ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
             ...<tp:member-ref>InitialVideo</tp:member-ref>: True
           },
@@ -376,7 +285,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
               ...<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>,
+( Fixed = { ...<tp:dbus-ref namespace="ofdT.Channel">ChannelType</tp:dbus-ref>: ...<tp:dbus-ref namespace="ofdT.Channel.Type">Call1</tp:dbus-ref>,
             ...<tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>: Contact,
             ...<tp:member-ref>InitialAudio</tp:member-ref>: True
           },
@@ -393,13 +302,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         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
+        namespace="ofdT.Channel.Type">Call1</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,
+        <tp:member-ref>Hangup</tp:member-ref>(<tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref>,
         "org.freedesktop.Telepathy.Error.Terminated", "") before
         actually closing the channel.</p>
 
@@ -415,13 +324,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           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
+          <tp:value-ref type="Call_State">Ringing</tp:value-ref> (an incoming
+          call is ready and waiting for the user to be notified). Calling this method
+          SHOULD set <tp:member-ref>CallFlags</tp:member-ref>' bit
+          <tp:value-ref type="Call_Flags">Locally_Ringing</tp:value-ref>, and notify the
           remote contact that the local user has been alerted (if the
-          protocol implements this); repeated calls to this method
+          protocol supports 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
@@ -438,7 +346,47 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <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:value-ref type="Call_State">Ringing</tp:value-ref>.
+          </tp:docstring>
+        </tp:error>
+      </tp:possible-errors>
+    </method>
+
+    <method name="SetQueued" tp:name-for-bindings="Set_Queued">
+      <tp:changed version="0.21.2">renamed from Ringing</tp:changed>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Notifies the CM that the local user is already in a call, so this
+          call has been put in a call-waiting style queue.</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:value-ref type="Call_State">Initialising</tp:value-ref> or
+          <tp:value-ref type="Call_State">Ringing</tp:value-ref>. Calling this method
+          SHOULD set <tp:member-ref>CallFlags</tp:member-ref>' bit
+          <tp:value-ref type="Call_Flags">Locally_Queued</tp:value-ref>, and notify the
+          remote contact that the call is in a queue (if the
+          protocol supports this); repeated calls to this method
+          SHOULD succeed, but have no further effect.</p>
+
+        <p>Locally_Queued is a little like Locally_Held, but applies to calls that have not
+          been Accepted (the Locally_Queued flag should be unset by the CM when Accept
+          is called). It should also be set in response to the state of the
+          world, rather than in response to user action.</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:value-ref type="Call_State">Initialising</tp:value-ref> or _Ringing.
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
@@ -447,16 +395,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <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>
+          <tp:value-ref type="Call_State">Ringing</tp:value-ref>, accept the incoming call.
+          This changes the <tp:member-ref>CallState</tp:member-ref> to
+          <tp:value-ref type="Call_State">Accepted</tp:value-ref>.</p>
 
         <p>For outgoing calls in state
-          <tp:type>Call_State</tp:type>_Pending_Initiator, actually
+          <tp:value-ref type="Call_State">Pending_Initiator</tp:value-ref>, 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>
+          <tp:value-ref type="Call_State">Initialising</tp:value-ref>.</p>
 
         <p>Otherwise, this method SHOULD fail with the error NotAvailable.</p>
 
@@ -464,15 +411,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           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"
+          namespace="ofdT.Call1" >Content</tp:dbus-ref> whose
+          <tp:dbus-ref namespace="ofdT.Call1.Content"
           >Disposition</tp:dbus-ref> is
-          <tp:type>Call_Content_Disposition</tp:type>_Initial, any
+          <tp:value-ref type="Call_Content_Disposition">Initial</tp:value-ref>, 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"
+          namespace="ofdT.Call1.Stream">LocalSendingState</tp:dbus-ref>
+          is <tp:value-ref type="Sending_State">Pending_Send</tp:value-ref> will be
+          moved to <tp:value-ref type="Sending_State">Sending</tp:value-ref> as if
+          <tp:dbus-ref namespace="ofdT.Call1.Stream"
           >SetSending</tp:dbus-ref>(True) had been called.</p>
       </tp:docstring>
 
@@ -531,8 +478,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <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
+        namespace="ofdT.Call1">Content</tp:dbus-ref> of type
+        Content_Type is added to the Call1. 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.
@@ -569,7 +516,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <tp:docstring>
           Path to the newly-created <tp:dbus-ref
             namespace="org.freedesktop.Telepathy"
-            >Call.Content.DRAFT</tp:dbus-ref> object.
+            >Call1.Content</tp:dbus-ref> object.
         </tp:docstring>
       </arg>
 
@@ -585,6 +532,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
             CM.
           </tp:docstring>
         </tp:error>
+        <tp:error name="org.freedesktop.Telepathy.Error.Media.UnsupportedType">
+          <tp:docstring>
+            The media stream type requested is not supported by either the
+            local or remote side.
+          </tp:docstring>
+        </tp:error>
         <tp:error name="org.freedesktop.Telepathy.Error.NotCapable">
           <tp:docstring>
             The content type requested cannot be added to this
@@ -600,26 +553,31 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <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>
+        <p>Emitted when a new <tp:dbus-ref namespace="ofdT.Call1"
+          >Content</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.
+          Path to the newly-created <tp:dbus-ref namespace="ofdT.Call1"
+          >Content</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>
+        <p>Emitted when a <tp:dbus-ref namespace="ofdT.Call1"
+          >Content</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.
+          The <tp:dbus-ref namespace="ofdT.Call1"
+          >Content</tp:dbus-ref> which was removed.
+        </tp:docstring>
+      </arg>
+      <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason">
+        <tp:docstring>
+          Why the content was removed.
         </tp:docstring>
       </arg>
     </signal>
@@ -628,7 +586,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       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
+          namespace="ofdT.Call1">Content</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.
@@ -643,17 +601,33 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <p>The allowed transitions are:</p>
 
         <ul>
-          <li>Pending_Initiator → Pending_Receiver (for outgoing calls,
+          <li>Pending_Initiator → Initialising (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>
+          <li>Initialising → Ringing (for outgoing calls, when
+            the remote client indicates that the user has been notified about
+            the call. If the network is known not to provide feedback about whether
+            the remote side is ringing, then the call should immediately be
+            set to Ringing.</li>
+          <li>Initialising → Ringing (for incoming calls, when e.g. the
+            implementation has been initialised far enough that it is sensible
+            to notify the user about the call (to reduce the probability that
+            the user will pick up the call and have it immediately fail).
+            The UI should then alert the user about the call, and call
+            <tp:member-ref>SetRinging</tp:member-ref>)</li>
+          <li>Ringing → Accepted (for outgoing calls to a contact,
+            when the remote contact accepts the call; for incoming calls, when
+            <tp:member-ref>Accept</tp:member-ref> is called.)</li>
+          <li>Accepted → Active (when the local user successfully
+            joins the call/conference, and media is known to be flowing
+            successfully; also, when temporary connection problems are
+            resolved (See below)). If the network is known not to provide
+            feedback about when the call is properly connected, the call
+            should immediately be set to Active.</li>
+          <li>Active → Accepted (when there are temporary connection problems
+            that the CM is aware of and able to recover from)</li>
+          <li>any state → Ended (when the call is terminated
+            normally, or when an error occurs that the CM is unable to recover
+            from)</li>
         </ul>
 
         <p>Clients MAY consider unknown values from this enum to be an
@@ -661,7 +635,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           specification is declared to be stable.</p>
       </tp:docstring>
 
-      <tp:enumvalue suffix="Unknown" value = "0">
+      <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
@@ -669,7 +643,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           unknown.
         </tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Pending_Initiator" value = "1">
+      <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
@@ -678,17 +652,48 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           called.
         </tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Pending_Receiver" value = "2">
+      <tp:enumvalue suffix="Initialising" value="2">
+        <tp:docstring>
+          Progress has been made in placing the call, but the
+          contact has not been made aware of the call yet. This corresponds to SIP's
+          status code 183 Session Progress, and should be used for the period
+          where the CM is waiting for the streaming implementation to
+          initialise (before sending the initial INVITE or equivalent) and when the
+          outgoing call has reached a gateway or ICE negotiation is pending.
+          UIs should not produce a dialtone or start ringing if the call is in
+          this state.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Ringing" value="3">
         <tp:docstring>
-          The receiver (the contact being called) hasn't accepted the call yet.
+          In the outgoing case: at least one called user has been alerted
+          about the call (a SIP 180 (Ringing) packet or equivalent has been
+          received) but none have answered, so the call cannot go to Accepted
+          (use <tp:value-ref type="Call_Member_Flags">Ringing</tp:value-ref> to determine which
+          members have been informed and which haven't, if you care). UIs
+          SHOULD produce a dialtone for outgoing calls in this state.
+
+          In the incoming case, the local user should be informed of the call
+          as soon as the call reaches this state (and
+          <tp:member-ref>SetRinging</tp:member-ref> should be called
+          to inform the CM that this has happened, so that it can relay this
+          fact to the caller using a SIP 180 (Ringing) packet or equivalent).
         </tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Accepted" value = "3">
+      <tp:enumvalue suffix="Accepted" value="4">
         <tp:docstring>
-          The contact being called has accepted the call.
+          The contact being called has accepted the call, but the call is not
+          in the Active state (The most common reason for this is that the
+          streaming implementation hasn't connected yet).
         </tp:docstring>
       </tp:enumvalue>
-      <tp:enumvalue suffix="Ended" value = "4">
+      <tp:enumvalue suffix="Active" value="5">
+        <tp:docstring>
+          The contact being called has accepted the call, and discourse between
+          at least two parties should now be possible.
+        </tp:docstring>
+      </tp:enumvalue>
+      <tp:enumvalue suffix="Ended" value="6">
         <tp:docstring>
           The call has ended, either via normal termination or an error.
         </tp:docstring>
@@ -697,43 +702,18 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
     <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.
+        A set of flags representing additional information than is available
+        in <tp:member-ref>CallState</tp:member-ref>. Many of these flags only make
+        sense in a particular (or may explain why a call is in a specific
+        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:flag suffix="Locally_Held" value="1">
         <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.
+          locally held.
 
           <tp:rationale>
             Otherwise, in transient situations where some but not all contents
@@ -741,32 +721,61 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
             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!
+
+            This flag exists as a simplified proxy for <tp:dbus-ref
+            namespace="ofdT.Channel.Interface.Hold"
+              >HoldStateChanged</tp:dbus-ref>,
+            to reduce the number of signals that need to be
+            listened to by a simple UI.
           </tp:rationale>
         </tp:docstring>
       </tp:flag>
 
-      <tp:flag suffix="Forwarded" value="8">
+      <tp:flag suffix="Locally_Muted" value="2">
         <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.
+          The call has been muted by the local user, e.g. using the
+          <tp:dbus-ref namespace="ofdT.Call1.Interface"
+          >Mute</tp:dbus-ref> interface. This flag SHOULD only
+          be set if there is at least one Content, and all Contents
+          are locally muted (for the same reason as Locally_Held).
+
+          <tp:rationale>
+            This flag exists to provide a simplified verson of <tp:dbus-ref
+            namespace="ofdT.Call1.Interface.Mute"
+              >MuteStateChanged</tp:dbus-ref>,
+            to reduce the number of signals that need to be
+            listened to by a simple UI.
+          </tp:rationale>
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Locally_Ringing" value="4">
+        <tp:docstring>
+          This flag exists for observability of the
+          <tp:member-ref>SetRinging</tp:member-ref> method (e.g. so that
+          loggers can tell whether the call got as far as alerting the user,
+          or whether something went wrong before then). It should be set when
+          the SetRinging is called, and unset when the call leaves
+          <tp:value-ref type="Call_State">Ringing</tp:value-ref>.
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Locally_Queued" value="8">
+        <tp:docstring>
+          This flag exists for observability of the
+          <tp:member-ref>SetQueued</tp:member-ref> method. It should be set
+          when the SetQueued is called, and unset when the call leaves
+          <tp:value-ref type="Call_State">Ringing</tp:value-ref>.
         </tp:docstring>
       </tp:flag>
 
-      <tp:flag suffix="In_Progress" value="16">
+      <tp:flag suffix="Forwarded" 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.
+          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. It SHOULD be
+          set or unset according to informational messages from other
+          contacts.
         </tp:docstring>
       </tp:flag>
 
@@ -787,17 +796,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </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"
@@ -815,7 +813,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           <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.
+            applicable when the call state is <tp:value-ref type="Call_State">Ended</tp:value-ref>.
             <tp:rationale>
               XMPP Jingle can send such messages.
             </tp:rationale>
@@ -824,7 +822,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           <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:value-ref type="Call_Flags">Locally_Queued</tp:value-ref> is in the call flags.
             <tp:rationale>
               SIP 182 notifications can have human-readable messages attached.
             </tp:rationale>
@@ -835,7 +833,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
             <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>
+            <tp:value-ref type="Call_State">Ended</tp:value-ref>.</dd>
+
+          <dt>balance-required - i</dt>
+          <dd>Optionally included when a call cannot be connected because
+            there is <tp:error-ref>InsufficientBalance</tp:error-ref>,
+            indicating what the required balance would be to place this call.
+            The value of this key has the same units and scale as
+            <tp:dbus-ref namespace="ofdT.Connection.Interface.Balance">AccountBalance</tp:dbus-ref>.
+            </dd>
         </dl>
       </tp:docstring>
     </property>
@@ -890,7 +896,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:docstring>
       </tp:enumvalue>
 
-      <tp:enumvalue suffix="User_Requested" value="1">
+      <tp:enumvalue suffix="Progress_Made" value="1">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          Situation normal. Progress has been made in the setup/teardown of
+          the call (and it didn't require any user interaction).
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="User_Requested" value="2">
         <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>
@@ -905,7 +918,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:docstring>
       </tp:enumvalue>
 
-      <tp:enumvalue suffix="Forwarded" value="2">
+      <tp:enumvalue suffix="Forwarded" value="3">
         <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
@@ -913,15 +926,113 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:docstring>
       </tp:enumvalue>
 
-      <tp:enumvalue suffix="No_Answer" value="3">
+      <tp:enumvalue suffix="Rejected" value="4">
         <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
+            <tp:value-ref type="Call_State">Ringing</tp:value-ref> or
+            <tp:value-ref type="Call_State">Ended</tp:value-ref> (or a content's direction
+            changed) because it was rejected by the remote user.</p>
+          <p>Corresponds to <tp:error-ref>Rejected</tp:error-ref></p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="No_Answer" value="5">
+        <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:value-ref type="Call_State">Ringing</tp:value-ref> or
+            <tp:value-ref type="Call_State">Ended</tp:value-ref> because the initiator
             ended the call before the receiver accepted it. With an
             incoming call this state change reason signifies a missed
-            call.</p>
+            call, or one that was picked up elsewhere before it was
+            picked up here.</p>
+          <p>Corresponds to <tp:error-ref>NoAnswer</tp:error-ref> or
+            <tp:error-ref>PickedUpElsewhere</tp:error-ref></p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Invalid_Contact" value="6">
+        <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 because one
+            of the addresses does not exist on the network.</p>
+          <p>Corresponds to <tp:error-ref>DoesNotExist</tp:error-ref></p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Permission_Denied" value="7">
+        <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 because the
+          local user is not authorised.</p>
+          <p>Corresponds to <tp:error-ref>PermissionDenied</tp:error-ref> or
+            <tp:error-ref>InsufficientBalance</tp:error-ref>
+            </p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Busy" value="8">
+        <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:value-ref type="Call_State">Ringing</tp:value-ref>
+            <tp:value-ref type="Call_State">Ended</tp:value-ref> because the receiver is busy
+            (e.g. is already engaged in another call, and has not placed the
+            initiator in a call-waiting queue).</p>
+          <p>Corresponds to <tp:error-ref>Busy</tp:error-ref></p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Internal_Error" value="9">
+        <tp:added version="0.21.2"/>
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>There has been an unexpected error in either the CM or some other
+            local component.</p>
+          <p>Corresponds to <tp:error-ref>Confused</tp:error-ref> or
+          <tp:error-ref>Media.StreamingError</tp:error-ref>
+          </p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Service_Error" value="10">
+        <tp:added version="0.21.2"/>
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>There has been an unexpected error in the server or some other
+            remote component.</p>
+          <p>Corresponds to
+            <tp:error-ref>ServiceConfused</tp:error-ref>
+          </p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Network_Error" value="11">
+        <tp:added version="0.21.2"/>
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>There has been a network error related to the CM or the
+            signalling part of the call (compare and contrast:
+            Streaming_Error).</p>
+          <p>Corresponds to
+            <tp:error-ref>NetworkError</tp:error-ref></p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Media_Error" value="12">
+        <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>
+          <p>Corresponds to <tp:error-ref>Media.UnsupportedType</tp:error-ref>
+            or <tp:error-ref>Media.CodecsIncompatible</tp:error-ref>
+          </p>
+        </tp:docstring>
+      </tp:enumvalue>
+
+      <tp:enumvalue suffix="Connectivity_Error" value="13">
+        <tp:docstring>
+          <p>It was not possible for the streaming implementation to connect
+            to any of the users participating in this call or content.</p>
+          <p>Corresponds to <tp:error-ref>ConnectionFailed</tp:error-ref> or
+            <tp:error-ref>ConnectionLost</tp:error-ref></p>
         </tp:docstring>
       </tp:enumvalue>
     </tp:enum>
@@ -944,7 +1055,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <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
+          <tp:value-ref type="Call_State_Change_Reason">User_Requested</tp:value-ref> then
           the Actor member will dictate whether it was the local user or
           a remote contact responsible.
         </tp:docstring>
@@ -970,10 +1081,19 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           </tp:rationale>
         </tp:docstring>
       </tp:member>
+
+      <tp:member type="s" name="Message">
+        <tp:docstring>
+          An optional debug message, to expediate debugging the potentially
+          many processes involved in a call. This may be communicated across
+          the network in protocols that support doing so, but it is not
+          essential.
+        </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">
+      type="(uuss)" 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
@@ -1007,7 +1127,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:docstring>
       </arg>
 
-      <arg name="Call_State_Reason" type="(uus)" tp:type="Call_State_Reason">
+      <arg name="Call_State_Reason" type="(uuss)" tp:type="Call_State_Reason">
         <tp:docstring>
           The new value of the <tp:member-ref>CallStateReason</tp:member-ref>
           property.
@@ -1037,8 +1157,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 
         <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
+          will have the <tp:dbus-ref namespace="ofdT.Call1.Content.Interface"
+          >Media</tp:dbus-ref> interface, to communicate the necessary
           information to a streaming implementation. Connection managers SHOULD
           operate like this, if possible.</p>
 
@@ -1069,7 +1189,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:rationale>
       </tp:docstring>
 
-      <tp:flag suffix="Ringing" value = "1">
+      <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>
@@ -1082,7 +1202,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:docstring>
       </tp:flag>
 
-      <tp:flag suffix="Held" value = "2">
+      <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>
 
@@ -1094,7 +1214,21 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         </tp:docstring>
       </tp:flag>
 
-      <tp:flag suffix="Conference_Host" value="4">
+      <tp:flag suffix="Muted" value="4">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>The call member has muted their participation in this call. Note
+            that many protocols will not signal this flag, so clients should
+            not rely on it being set.</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 mute their own
+              streams.</p>
+          </tp:rationale>
+        </tp:docstring>
+      </tp:flag>
+
+      <tp:flag suffix="Conference_Host" value="8">
         <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
@@ -1132,12 +1266,22 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           flags have changed.
         </tp:docstring>
       </arg>
+      <arg name="Identifiers" type="a{us}" tp:type="Handle_Identifier_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          The identifiers of the contacts in the <var>Flags_Changed</var> map.
+        </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>
+      <arg name="Reason" type="(uuss)" tp:type="Call_State_Reason">
+        <tp:docstring>
+          A structured reason for the change.
+        </tp:docstring>
+      </arg>
     </signal>
 
     <property name="CallMembers" tp:name-for-bindings="Call_Members"
@@ -1162,13 +1306,23 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       </tp:docstring>
     </property>
 
+    <property name="MemberIdentifiers" type="a{us}" tp:type="Handle_Identifier_Map"
+      access="read" tp:name-for-bindings="Member_Identifiers">
+      <tp:docstring>
+        The string identifiers for handles mentioned in
+        <tp:member-ref>CallMembers</tp:member-ref>, to
+        give clients the minimal information necessary to create contacts
+        without waiting for round-trips.
+      </tp:docstring>
+    </property>
+
     <property name="InitialTransport" tp:name-for-bindings="Initial_Transport"
       type="u" tp:type="Stream_Transport_Type" 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 <tp:type>Stream_Transport_Type</tp:type>_Unknown,
+          is defined to be <tp:value-ref type="Stream_Transport_Type">Unknown</tp:value-ref>,
           in particular, on CMs with hardware streaming.</p>
 
         <tp:rationale>
@@ -1187,7 +1341,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           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>
+          namespace="ofdT.Channel.Type.Call1">AddContent</tp:dbus-ref>.</p>
 
         <p>If this property, or InitialVideo, is passed to EnsureChannel
           (as opposed to CreateChannel), the connection manager SHOULD ignore
@@ -1202,7 +1356,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
         <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"
+          <tp:dbus-ref namespace="ofdT.Channel.Type.Call1"
           >Contents</tp:dbus-ref>).</p>
 
         <p>The name of this new content can be decided by using the
@@ -1323,7 +1477,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
               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
+              than a single "Call1" button with the option to add and remove
               video once the call has started for contacts without this flag.
             </p>
           </tp:rationale>
@@ -1345,32 +1499,32 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
     <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>
+          namespace="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
+          property is <tp:value-ref type="Stream_Transport_Type">GTalk_P2P</tp:value-ref>.</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>
+          namespace="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
+          property is <tp:value-ref type="Stream_Transport_Type">ICE</tp:value-ref>.</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>
+          namespace="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
+          property is <tp:value-ref type="Stream_Transport_Type">WLM_2009</tp:value-ref>.</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>
+          namespace="ofdT.Call1.Stream.Interface.Media">Transport</tp:dbus-ref>
+          property is <tp:value-ref type="Stream_Transport_Type">SHM</tp:value-ref>.</p>
       </tp:docstring>
     </tp:hct>
 
@@ -1405,11 +1559,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
           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>
+          <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/audio</code></li>
+          <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/audio/speex</code></li>
+          <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/video</code></li>
+          <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/video/theora</code></li>
+          <li><code>org.freedesktop.Telepathy.Channel.Type.Call1/video/h264</code></li>
         </ul>
 
         <p>Clients MAY have media signalling abilities without explicitly
diff --git a/spec/Channel_Type_Contact_List.xml b/spec/Channel_Type_Contact_List.xml
index 5a0d3336..348d0bd4 100644
--- a/spec/Channel_Type_Contact_List.xml
+++ b/spec/Channel_Type_Contact_List.xml
@@ -21,6 +21,9 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   <interface name="org.freedesktop.Telepathy.Channel.Type.ContactList">
     <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
     <tp:requires interface="org.freedesktop.Telepathy.Channel.Interface.Group"/>
+    <tp:deprecated version="0.25.0">Replaced by <tp:dbus-ref
+      namespace="org.freedesktop.Telepathy">Connection.Interface.ContactList</tp:dbus-ref>
+      </tp:deprecated>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A channel type for representing a list of people on the server which is
diff --git a/spec/Channel_Type_Contact_Search.xml b/spec/Channel_Type_Contact_Search.xml
index fefa77a2..98789ab4 100644
--- a/spec/Channel_Type_Contact_Search.xml
+++ b/spec/Channel_Type_Contact_Search.xml
@@ -31,12 +31,31 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <p>A channel type for searching server-stored user directories. A new
         channel should be requested by a client for each search attempt, and
         closed when the search is completed or the required result has been
-        found. Channels of this type should have <tp:dbus-ref
+        found.</p>
+
+      <p>Connections that support contact search channels SHOULD have an entry
+        in <tp:dbus-ref namespace='ofdT.Connection.Interface.Requests'
+          >RequestableChannelClasses</tp:dbus-ref> with the <tp:dbus-ref
+          namespace='ofdT.Channel'>ChannelType</tp:dbus-ref> fixed to this
+        interface, and no other fixed properties. That requestable
+        channel class MAY also have the Server and Limit properties in its
+        list of allowed properties, depending on the protocol.</p>
+
+      <tp:rationale>
+        <p>The requestable channel class would normally also have <tp:dbus-ref
+            namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref> fixed to
+          <code>None</code>, but the initial implementation of ContactSearch
+          (in telepathy-gabble) didn't do this.</p>
+      </tp:rationale>
+
+      <p>All channels of this type should have <tp:dbus-ref
         namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>
         <code>None</code> (and hence <tp:dbus-ref
         namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref> <code>0</code> and
         <tp:dbus-ref namespace='ofdT.Channel'>TargetID</tp:dbus-ref>
-        <code>""</code>). Requests for channels of this type need only
+        <code>""</code>).</p>
+
+      <p>Requests for channels of this type need only
         optionally specify the <tp:member-ref>Server</tp:member-ref> property
         (if it is an allowed property in the connection's <tp:dbus-ref
         namespace='ofdT.Connection.Interface.Requests'>RequestableChannelClasses</tp:dbus-ref>).</p>
diff --git a/spec/Channel_Type_DBus_Tube.xml b/spec/Channel_Type_DBus_Tube.xml
index 96157631..74e65951 100644
--- a/spec/Channel_Type_DBus_Tube.xml
+++ b/spec/Channel_Type_DBus_Tube.xml
@@ -174,7 +174,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A list of the access control types that are supported with this channel.
         Note that only Socket_Access_Control_Localhost and
-        Socket_Access_Control_Credentials can be used with D-Bus tubes.</p>
+        Socket_Access_Control_Credentials can be used with D-Bus tubes.
+        Using Socket_Access_Control_Credentials is recommended.</p>
+
+        <tp:rationale>
+          <p>Socket_Access_Control_Credentials is easy to implement for a
+            D-Bus tube, because typical D-Bus library implementations like
+            libdbus and GDBus already have to support it to be able to
+            connect to the system or session bus, and usually enable it
+            by default; so there's typically no good reason to relax
+            access control to Localhost.</p>
+        </tp:rationale>
 
         <p>When requesting a channel with
           <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Requests.CreateChannel</tp:dbus-ref>,
diff --git a/spec/Channel_Type_File_Transfer.xml b/spec/Channel_Type_File_Transfer.xml
index 6963d213..f50b9634 100644
--- a/spec/Channel_Type_File_Transfer.xml
+++ b/spec/Channel_Type_File_Transfer.xml
@@ -96,7 +96,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="ContentType" type="s" access="read"
-      tp:name-for-bindings="Content_Type">
+      tp:name-for-bindings="Content_Type" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The file's MIME type. This cannot change once the channel has
         been created.</p>
@@ -109,7 +109,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="Filename" type="s" access="read"
-      tp:name-for-bindings="Filename">
+      tp:name-for-bindings="Filename" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The name of the file on the sender's side. This is therefore given
         as a suggested filename for the receiver. This cannot change
@@ -126,7 +126,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="Size" type="t" access="read"
-      tp:name-for-bindings="Size">
+      tp:name-for-bindings="Size" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The size of the file. If this property is set, then the file
         transfer is guaranteed to be this size. This cannot change once
@@ -145,7 +145,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="ContentHashType" type="u" tp:type="File_Hash_Type"
-      access="read" tp:name-for-bindings="Content_Hash_Type">
+      access="read" tp:name-for-bindings="Content_Hash_Type" tp:immutable="yes"
+      tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The type of the <tp:member-ref>ContentHash</tp:member-ref> property.</p>
 
@@ -168,7 +169,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="ContentHash" type="s" access="read"
-      tp:name-for-bindings="Content_Hash">
+      tp:name-for-bindings="Content_Hash" tp:immutable="yes"
+      tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Hash of the contents of the file transfer, of type described
         in the value of the <tp:member-ref>ContentHashType</tp:member-ref>
@@ -184,7 +186,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="Description" type="s" access="read"
-      tp:name-for-bindings="Description">
+      tp:name-for-bindings="Description" tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Description of the file transfer. This cannot change once the
         channel has been created.</p>
@@ -197,7 +199,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="Date" type="x" access="read"
-      tp:type="Unix_Timestamp64" tp:name-for-bindings="Date">
+      tp:type="Unix_Timestamp64" tp:name-for-bindings="Date" tp:immutable="yes"
+      tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The last modification time of the file being transferred. This
         cannot change once the channel has been created</p>
@@ -210,7 +213,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
     <property name="AvailableSocketTypes" type="a{uau}"
       tp:type="Supported_Socket_Map" access="read"
-      tp:name-for-bindings="Available_Socket_Types">
+      tp:name-for-bindings="Available_Socket_Types"
+      tp:immutable="yes" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>A mapping from address types (members of Socket_Address_Type) to
         arrays of access-control type (members of Socket_Access_Control)
@@ -243,7 +247,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     </property>
 
     <property name="InitialOffset" type="t" access="read"
-      tp:name-for-bindings="Initial_Offset">
+      tp:name-for-bindings="Initial_Offset" tp:requestable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>The offset in bytes from where the file should be sent. This MUST
         be respected by both the receiver and the sender after the state
@@ -276,7 +280,8 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
         <p>For incoming file transfers, this property MAY be set by the channel
         handler before calling <tp:member-ref>AcceptFile</tp:member-ref> to
-        inform observers where the incoming file will be saved.
+        inform observers where the incoming file will be saved. If set by an
+        approver, the handler MUST save the file to that location.
         Setting this property once <tp:member-ref>AcceptFile</tp:member-ref>
         has been called MUST fail. Once this property has been set
         <tp:member-ref>URIDefined</tp:member-ref> is emitted.</p>
diff --git a/spec/Channel_Type_Room_List.xml b/spec/Channel_Type_Room_List.xml
index 98f74582..b2b886f1 100644
--- a/spec/Channel_Type_Room_List.xml
+++ b/spec/Channel_Type_Room_List.xml
@@ -86,7 +86,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <dt>subject (s)</dt>
           <dd>The current subject of conversation in the room (as would
             be returned by getting the string part of the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
+            namespace="org.freedesktop.Telepathy.Channel.Interface.Subject2"
             >Subject</tp:dbus-ref> property)</dd>
 
           <dt>members (u)</dt>
@@ -101,13 +101,13 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <dt>room-id (s)</dt>
           <dd>The human-readable identifier of a chat room (as would be
             returned by getting the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
-            >RoomID</tp:dbus-ref> property)</dd>
+            namespace="org.freedesktop.Telepathy.Channel.Interface.Room2"
+            >RoomName</tp:dbus-ref> property)</dd>
 
           <dt>server (s)</dt>
           <dd>The DNS name of the server hosting these channels (as would be
             returned by getting the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
+            namespace="org.freedesktop.Telepathy.Channel.Interface.Room2"
             >Server</tp:dbus-ref> property)</dd>
         </dl>
       </tp:docstring>
diff --git a/spec/Channel_Type_Text.xml b/spec/Channel_Type_Text.xml
index 0cd4d5bb..76123293 100644
--- a/spec/Channel_Type_Text.xml
+++ b/spec/Channel_Type_Text.xml
@@ -24,6 +24,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
     interface="org.freedesktop.Telepathy.Channel.Interface.Messages"/>
     <tp:changed version="0.21.5">The Messages interface is now
       mandatory</tp:changed>
+    <tp:changed version="0.24.0">This interface used to have a bunch of
+      clunky <tp:dbus-ref
+      namespace='org.freedesktop'>Telepathy.Properties</tp:dbus-ref>. They have
+      been removed in favour of D-Bus properties on the <tp:dbus-ref
+      namespace='ofdT.Channel.Interface'>Room2</tp:dbus-ref>, <tp:dbus-ref
+      namespace='ofdT.Channel.Interface'>Subject2</tp:dbus-ref> and
+      <tp:dbus-ref namespace='ofdT.Channel.Interface'>RoomConfig1</tp:dbus-ref>
+      interfaces.</tp:changed>
 
     <tp:simple-type name="Message_ID" type="u" array-name="Message_ID_List">
       <tp:docstring>
@@ -430,92 +438,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       </tp:flag>
     </tp:flags>
 
-    <tp:property name="anonymous" type="b">
-      <tp:docstring>
-      True if people may join the channel without other members being made
-      aware of their identity.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="invite-only" type="b">
-      <tp:docstring>
-      True if people may not join the channel until they have been invited.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="limit" type="u">
-      <tp:docstring>
-      The limit to the number of members, if limited is true.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="limited" type="b">
-      <tp:docstring>
-      True if there is a limit to the number of channel members.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="moderated" type="b">
-      <tp:docstring>
-      True if channel membership is not sufficient to allow participation.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="name" type="s">
-      <tp:docstring>
-      A human-visible name for the channel, if it differs from the channel's
-      <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetID</tp:dbus-ref>.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="description" type="s">
-      <tp:docstring>
-      A human-readable description of the channel's overall purpose.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="password" type="s">
-      <tp:docstring>
-      The password required to enter the channel if password-required is true.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="password-required" type="b">
-      <tp:docstring>
-      True if a password must be provided to enter the channel.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="persistent" type="b">
-      <tp:docstring>
-      True if the channel will remain in existence on the server after all
-      members have left it.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="private" type="b">
-      <tp:docstring>
-      True if the channel is not visible to non-members.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="subject" type="s">
-      <tp:docstring>
-      A human-readable description of the current subject of conversation in
-      the channel, similar to /topic in IRC. This is equivalent to the
-      <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
-      >Subject</tp:dbus-ref> property in the Room interface which will replace
-      this Telepathy property.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="subject-contact" type="u" tp:type="Contact_Handle">
-      <tp:docstring>
-      A contact handle representing who last modified the subject, or 0
-      if it isn't known. This is equivalent to the
-      <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
-      >Subject</tp:dbus-ref> property in the Room interface which will replace
-      this Telepathy property.
-      </tp:docstring>
-    </tp:property>
-    <tp:property name="subject-timestamp" type="u" tp:type="Unix_Timestamp">
-      <tp:docstring>
-      A unix timestamp indicating when the subject was last modified.
-      This is equivalent to the
-      <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Room.DRAFT"
-      >Subject</tp:dbus-ref> property in the Room interface which will replace
-      this Telepathy property.
-      </tp:docstring>
-    </tp:property>
-
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>A channel type for sending and receiving messages. This channel type
         is primarily used for textual messages, but can also be used for
@@ -555,14 +477,22 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <p>Simple one-to-one chats (such as streams of private messages in
         XMPP or IRC) should be represented by a Text channel whose
         <tp:dbus-ref namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref>
-        is <tp:type>Handle_Type</tp:type>_Contact. The expected way to
-        request such a channel is to set the ChannelType, TargetHandleType,
-        and either TargetHandle or TargetID in a call to EnsureChannel.</p>
+        is <tp:value-ref type="Handle_Type">Contact</tp:value-ref>. The
+        expected way to request such a channel is to set the <tp:dbus-ref
+        namespace='ofdT.Channel'>ChannelType</tp:dbus-ref>, <tp:dbus-ref
+        namespace='ofdT.Channel'>TargetHandleType</tp:dbus-ref>,
+        and either <tp:dbus-ref
+        namespace='ofdT.Channel'>TargetHandle</tp:dbus-ref> or <tp:dbus-ref
+        namespace='ofdT.Channel'>TargetID</tp:dbus-ref> in a call to
+        <tp:dbus-ref
+        namespace='ofdT.ChannelDispatcher'>EnsureChannel</tp:dbus-ref>.</p>
 
       <p>Named chat rooms whose identity can be saved and used again later
         (IRC channels, Jabber MUCs) are expected to be represented by Text
-        channels with <tp:type>Handle_Type</tp:type>_Room and the <tp:dbus-ref
-          namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
+        channels with <tp:dbus-ref
+        namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> =
+        <tp:value-ref type="Handle_Type">Room</tp:value-ref> and the
+        <tp:dbus-ref namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
         interface. In protocols where a chatroom can be used as a continuation
         of one or more one-to-one chats, these channels should also have the
         <tp:dbus-ref namespace="ofdT.Channel.Interface">Conference</tp:dbus-ref>
@@ -571,7 +501,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <p>Unnamed, transient chat rooms which cannot be rejoined by their
         unique identifier (e.g. a conversation on MSN which has, or once had,
         three or more participants) are expected to be represented by Text
-        channels with Handle_Type_None (and hence TargetHandle 0), the
+        channels with <tp:dbus-ref
+        namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> = <tp:value-ref
+        type="Handle_Type">None</tp:value-ref> (and hence <tp:dbus-ref
+        namespace="ofdT.Channel">TargetHandle</tp:dbus-ref> = 0),
         <tp:dbus-ref namespace="ofdT.Channel.Interface">Group</tp:dbus-ref>
         interface, and optionally the
         <tp:dbus-ref namespace="ofdT.Channel.Interface">Conference</tp:dbus-ref>
@@ -580,7 +513,10 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <p>On protocols like MSN where a conversation with a user is actually
         just a nameless chat room starting with exactly two members, to which
         more members can be invited, the initial one-to-one conversation
-        SHOULD be represented with Handle_Type_Contact. If a third participant
+        SHOULD be represented with <tp:dbus-ref
+        namespace="ofdT.Channel">TargetHandleType</tp:dbus-ref> =
+        <tp:value-ref type="Handle_Type">Contact</tp:value-ref>. If a third
+        participant
         joins or is invited, this SHOULD be represented by signalling
         a new <tp:dbus-ref
           namespace="ofdT.Channel.Interface">Conference</tp:dbus-ref> channel
@@ -606,8 +542,11 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         <tp:dbus-ref
           namespace="ofdT.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
         signal. The new channel should resemble the old channel, but have
-        Requested = FALSE regardless of its previous value; the InitiatorHandle
-        and InitiatorID should correspond to the sender of one of the pending
+        <tp:dbus-ref namespace='ofdT.Channel'>Requested</tp:dbus-ref> = FALSE
+        regardless of its previous value; the <tp:dbus-ref
+        namespace='ofdT.Channel'>InitiatorHandle</tp:dbus-ref>
+        and <tp:dbus-ref namespace='ofdT.Channel'>InitiatorID</tp:dbus-ref>
+        should correspond to the sender of one of the pending
         messages.</p>
 
       <tp:rationale>
@@ -663,6 +602,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           eventually need a distinction between Close and Destroy.</p>
       </tp:rationale>
 
+      <p>Opaquely-named rejoinable chatrooms (such as Skype rooms) are
+        represented using the properties in the <tp:dbus-ref
+        namespace="ofdT.Channel.Interface">Room2</tp:dbus-ref>
+        interface. Instructions and examples of how to request
+        such channels are given in said interface's description.</p>
+
     </tp:docstring>
   </interface>
 </node>
diff --git a/spec/Connection.xml b/spec/Connection.xml
index 0ba095a9..6a560fc3 100644
--- a/spec/Connection.xml
+++ b/spec/Connection.xml
@@ -595,11 +595,17 @@ USA.</p>
         </tp:docstring>
       </tp:enumvalue>
       <tp:enumvalue suffix="List" value="3">
+        <tp:deprecated version="0.25.0">Replaced by <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy">Connection.Interface.ContactList</tp:dbus-ref>
+        </tp:deprecated>
         <tp:docstring>
           A server-generated contact list (see Channel.Interface.Group)
         </tp:docstring>
       </tp:enumvalue>
       <tp:enumvalue suffix="Group" value="4">
+        <tp:deprecated version="0.25.0">Replaced by <tp:dbus-ref
+          namespace="org.freedesktop.Telepathy">Connection.Interface.ContactList</tp:dbus-ref>
+        </tp:deprecated>
         <tp:docstring>
           A user-defined contact list (see Channel.Interface.Group)
         </tp:docstring>
@@ -625,12 +631,18 @@ USA.</p>
 
     <tp:simple-type name="List_Handle" type="u"
       array-name="List_Handle_List">
+      <tp:deprecated version="0.25.0">Replaced by <tp:dbus-ref
+        namespace="org.freedesktop.Telepathy">Connection.Interface.ContactList</tp:dbus-ref>
+      </tp:deprecated>
       <tp:docstring>An unsigned 32-bit integer representing a handle of type
         Handle_Type_List</tp:docstring>
     </tp:simple-type>
 
     <tp:simple-type name="Group_Handle" type="u"
       array-name="Group_Handle_List">
+      <tp:deprecated version="0.25.0">Replaced by <tp:dbus-ref
+        namespace="org.freedesktop.Telepathy">Connection.Interface.ContactList</tp:dbus-ref>
+      </tp:deprecated>
       <tp:docstring>An unsigned 32-bit integer representing a handle of type
         Handle_Type_Group</tp:docstring>
     </tp:simple-type>
diff --git a/spec/Connection_Interface_Addressing.xml b/spec/Connection_Interface_Addressing.xml
index 497c6d0d..ef9df3ee 100644
--- a/spec/Connection_Interface_Addressing.xml
+++ b/spec/Connection_Interface_Addressing.xml
@@ -21,6 +21,7 @@
     <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
     <tp:requires interface="org.freedesktop.Telepathy.Connection.Interface.Contacts"/>
     <tp:added version="0.19.12">(as draft)</tp:added>
+    <tp:changed version="0.25.1">Both methods now return two dictionaries.</tp:changed>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>This interface deals with the multiple address types that can
       refer to the same contact, such as vCard fields and URIs.</p>
@@ -39,7 +40,7 @@
           <p>The vCard field of the addresses we are requesting. The
             field name SHOULD be in lower case. Supported
             fields can be found in
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing.DRAFT">AddressableVCardFields</tp:dbus-ref>.</p>
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing">AddressableVCardFields</tp:dbus-ref>.</p>
 
           <p>The <code>url</code> vCard field MUST NOT appear here; see
             <tp:member-ref>GetContactsByURI</tp:member-ref> instead.</p>
@@ -76,7 +77,18 @@
           </tp:docstring>
       </arg>
 
-      <arg direction="out" type="a{ua{sv}}" name="Requested_Contacts"
+      <arg direction="out" type="a{su}" name="Requested"
+           tp:type="Addressing_Normalization_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>A mapping from requested vCard addresses to the corresponding
+            contact handles.</p>
+
+          <p>Requested addresses that are not valid or understood for this protocol
+            MUST be omitted from the mapping.</p>
+        </tp:docstring>
+      </arg>
+
+      <arg direction="out" type="a{ua{sv}}" name="Attributes"
            tp:type="Contact_Attributes_Map">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>A dictionary mapping the contact handles to contact attributes.
@@ -86,14 +98,12 @@
             the attribute should either be omitted from the result or
             replaced with a default value.</p>
 
-          <p>Requested addresses that cannot be satisfied MUST be ommitted
-            from the mapping.</p>
+          <p>Requested addresses that are not valid or understood for this protocol
+            MUST be omitted from the mapping.</p>
 
           <p>Each contact's attributes will always include at least the
             identifier that would be obtained by inspecting the handle
-            (<code>org.freedesktop.Telepathy.Connection/contact-id</code>),
-          and the vCard field used for requesting the contact in
-            <code>org.freedesktop.Telepathy.Connection.Interface.ContactInfo/info</code>.
+            (<code>org.freedesktop.Telepathy.Connection/contact-id</code>).
           </p>
         </tp:docstring>
       </arg>
@@ -121,7 +131,7 @@
         <tp:docstring>
           The URI addresses to get contact handles for. Supported
           schemes can be found in
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing.DRAFT">AddressableURISchemes</tp:dbus-ref>.
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing">AddressableURISchemes</tp:dbus-ref>.
         </tp:docstring>
       </arg>
       <arg direction="in" name="Interfaces" type="as"
@@ -143,7 +153,17 @@
           </tp:docstring>
       </arg>
 
-      <arg direction="out" type="a{ua{sv}}" name="Requested_Contacts"
+      <arg direction="out" type="a{su}" name="Requested"
+           tp:type="Addressing_Normalization_Map">
+        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+          <p>A mapping of requested URIs to the corresponding contact handles.</p>
+
+          <p>Requested URIs that are not valid or understood for this protocol
+            MUST be omitted from the mapping.</p>
+        </tp:docstring>
+      </arg>
+
+      <arg direction="out" type="a{ua{sv}}" name="Attributes"
            tp:type="Contact_Attributes_Map">
         <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
           <p>A dictionary mapping the contact handles to contact attributes.
@@ -153,8 +173,8 @@
             the attribute should either be omitted from the result or
             replaced with a default value.</p>
 
-          <p>Requested URIs that cannot be satisfied MUST be ommitted
-            from the mapping.</p>
+          <p>Requested URIs that are not valid or understood for this protocol
+            MUST be omitted from the mapping.</p>
 
           <p>Each contact's attributes will always include at least the
             identifier that would be obtained by inspecting the handle
@@ -201,57 +221,25 @@
       </tp:docstring>
     </tp:contact-attribute>
 
-    <tp:contact-attribute name="requested-address" type="(ss)"
-                          tp:type="Requested_Address">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The contact's address, as it was requested
-        through <tp:member-ref>GetContactsByVCardField</tp:member-ref>. This
-        attribute MUST be ommitted if the contact was not retrieved
-        through <tp:member-ref>GetContactsByVCardField</tp:member-ref>.</p>
-      <tp:rationale>
-        <p>When retrieving more than one contact
-          through <tp:member-ref>GetContactsByVCardField</tp:member-ref>,
-          there needs to be a way to map the given contact back o the
-          original request.</p>
-      </tp:rationale>
-      </tp:docstring>
-    </tp:contact-attribute>
-
-    <tp:contact-attribute name="requested-uri" type="s">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The contact's URI, as it was requested through
-        <tp:member-ref>GetContactsByURI</tp:member-ref>. This
-        attribute MUST be ommitted if the contact was not retrieved
-        through <tp:member-ref>GetContactsByURI</tp:member-ref>.</p>
-      <tp:rationale>
-        <p>When retrieving more than one contact
-        through <tp:member-ref>GetContactsByURI</tp:member-ref>,
-        there needs to be a way to map the given contact back o the
-        original request.</p>
-      </tp:rationale>
-      </tp:docstring>
-    </tp:contact-attribute>
-
-    <tp:struct name="Requested_Address" array-name="">
+    <tp:mapping name="Addressing_Normalization_Map">
       <tp:docstring>
-        The address that has been requested by
-        <tp:member-ref>GetContactsByVCardField</tp:member-ref> or
-        <tp:member-ref>GetContactsByURI</tp:member-ref>.
+        A map from URIs/vCard addresses to the corresponding handle.
       </tp:docstring>
+      <tp:added version="0.25.1"/>
 
-      <tp:member name="Field" type="s">
+      <tp:member type="s" name="Requested_String">
         <tp:docstring>
-          The vCard field used in <tp:member-ref>GetContactsByVCardField</tp:member-ref>.
+        The URI or vCard address that has been requested by
+        <tp:member-ref>GetContactsByVCardField</tp:member-ref> or
+        <tp:member-ref>GetContactsByURI</tp:member-ref>.
         </tp:docstring>
       </tp:member>
-
-      <tp:member name="Address" type="s">
+      <tp:member type="u" name="Handle" tp:type="Contact_Handle">
         <tp:docstring>
-          The address that was requested.
+          A nonzero handle.
         </tp:docstring>
       </tp:member>
-
-    </tp:struct>
+    </tp:mapping>
 
   </interface>
 </node>
diff --git a/spec/Connection_Interface_Balance.xml b/spec/Connection_Interface_Balance.xml
index 76f9040e..974c651f 100644
--- a/spec/Connection_Interface_Balance.xml
+++ b/spec/Connection_Interface_Balance.xml
@@ -93,6 +93,26 @@
       </tp:docstring>
     </property>
 
+    <property name="ManageCreditURI"
+              tp:name-for-bindings="Manage_Credit_URI"
+              access="read" type="s">
+      <tp:added version="0.22.2"/>
+      <tp:docstring>
+        A URI the user may visit via the web browser to manage and top-up their
+        account balance. This property is not guaranteed to be well-defined
+        until the connection becomes Connected; there is no change
+        notification.
+
+        <tp:rationale>
+          Different protocols and even servers or gateways (e.g. SIP and XMPP
+          PSTN gateways) will have a different website used to manage a user's
+          account balance. This property enables the client to provide that
+          to the user. A Connection Manager MAY set this itself (because it is
+          static or discoverable), or expose it as a connection parameter.
+        </tp:rationale>
+      </tp:docstring>
+    </property>
+
     <signal name="BalanceChanged" tp:name-for-bindings="Balance_Changed">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Emitted when the user's balance has changed.</p>
diff --git a/spec/Connection_Interface_Forwarding.xml b/spec/Connection_Interface_Forwarding.xml
index e5457b1e..32c7e1cb 100644
--- a/spec/Connection_Interface_Forwarding.xml
+++ b/spec/Connection_Interface_Forwarding.xml
@@ -92,7 +92,7 @@
         the group with the self handle as the actor, and
         <tp:type>Channel_Group_Change_Reason</tp:type> <code>No_Answer</code> or
         <code>Busy</code>, as appropriate. For <tp:dbus-ref
-        namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref> channels, the
+        namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref> channels, the
         <tp:type>Call_State_Change_Reason</tp:type> <code>Forwarded</code>
         should be used.</p>
     </tp:docstring>
diff --git a/spec/Connection_Interface_Location.xml b/spec/Connection_Interface_Location.xml
index fe549234..c4fd68c3 100644
--- a/spec/Connection_Interface_Location.xml
+++ b/spec/Connection_Interface_Location.xml
@@ -60,7 +60,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
 
     <!-- Potentially to be reinstated later:
          http://bugs.freedesktop.org/show_bug.cgi?id=19585
-    <tp:enum name="Location_Accuracy_Level" type="i">
+    <tp:enum name="Location_Accuracy_Level" type="u">
       <tp:docstring>
         A location accuracy level. This should be kept in sync with
         GeoclueAccuracyLevel in the Geoclue project.
diff --git a/spec/Connection_Interface_Requests.xml b/spec/Connection_Interface_Requests.xml
index 2f233fa5..c8dc3280 100644
--- a/spec/Connection_Interface_Requests.xml
+++ b/spec/Connection_Interface_Requests.xml
@@ -486,7 +486,10 @@
           <tp:dbus-ref>org.freedesktop.Telepathy.Channel.ChannelType</tp:dbus-ref>
           and
           <tp:dbus-ref>org.freedesktop.Telepathy.Channel.TargetHandleType</tp:dbus-ref>.
-          </p>
+          (One exception is that <tp:dbus-ref namespace="ofdT.Channel.Type"
+            >ContactSearch</tp:dbus-ref> channels do not have TargetHandleType
+          <code>None</code> in their requestable channel classes, for
+          historical reasons.)</p>
       </tp:docstring>
 
       <tp:member type="s" name="Key" tp:type="DBus_Qualified_Member">
diff --git a/spec/Connection_Interface_Simple_Presence.xml b/spec/Connection_Interface_Simple_Presence.xml
index 7788161e..0860f5fe 100644
--- a/spec/Connection_Interface_Simple_Presence.xml
+++ b/spec/Connection_Interface_Simple_Presence.xml
@@ -276,6 +276,49 @@
       </tp:docstring>
     </property>
 
+    <property name="MaximumStatusMessageLength"
+      tp:name-for-bindings="Maximum_Status_Message_Length" access="read"
+      type="u">
+      <tp:added version="0.22.2"/>
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>The maximum length in characters for any individual status
+          message, or 0 if there is no limit.</p>
+
+        <p>While the connection is in the DISCONNECTED state, this property will
+          be 0. The connection manager will attempt to set the appropriate value
+          when the connection becomes connected, but cannot necessarily
+          guarantee it. The maximum length cannot change until the
+          connection status changes, so there is no change notification.</p>
+
+        <p>While the connection is in the CONNECTED state, this property
+          contains the maximum length in characters for any individual status
+          message which is actually allowed on this protocol.
+          This value is constant for the remaining lifetime
+          of the connection, so again, there is no change notification.</p>
+
+        <p>While the connection is in the CONNECTING state, the value of
+          this property is undefined and SHOULD NOT be used. It can change
+          at any time without notification (in particular, any cached values
+          from when the connection was in the DISCONNECTED or CONNECTING
+          state MUST NOT be assumed to still be correct when the state has
+          become CONNECTED).</p>
+
+        <p>If a message passed to <tp:member-ref>SetPresence</tp:member-ref> is
+          longer than allowed by this property, the connection manager MUST
+          truncate the supplied message; when emitting
+          <tp:member-ref>PresencesChanged</tp:member-ref>, the truncated version
+          of the message MUST be used.</p>
+
+        <tp:rationale>
+          <p>Some XMPP servers, like Google Talk, define a maximum length for
+          status messages. Whether the user's server is one of
+          these cannot be detected until quite late in the connection
+          process.</p>
+        </tp:rationale>
+
+      </tp:docstring>
+    </property>
+
     <signal name="PresencesChanged" tp:name-for-bindings="Presences_Changed">
       <arg name="Presence" type="a{u(uss)}" tp:type="Simple_Contact_Presences">
         <tp:docstring>
@@ -547,57 +590,75 @@
 
       <table>
         <tr>
-          <th>status identifier</th>
-          <th>Connection_Presence_Type</th>
-          <th>comments</th>
+          <th>Status identifier</th>
+          <th><tp:type>Connection_Presence_Type</tp:type></th>
+          <th>Remarks</th>
         </tr>
         <tr>
-          <td>available</td>
-          <td>Connection_Presence_Type_Available</td>
+          <td><code>"available"</code></td>
+          <td>Available</td>
           <td></td>
         </tr>
         <tr>
-          <td>away</td>
-          <td>Connection_Presence_Type_Away</td>
+          <td><code>"chat"</code></td>
+          <td>Available</td>
+          <td>Actively interested in chatting, as opposed to merely
+            available.</td>
+        </tr>
+        <tr>
+          <td><code>"pstn"</code></td>
+          <td>Available</td>
+          <td>This contact is actually a phone number, not an IM account. As
+            such, the contact is conceptually always available, but not in the
+            same way that a contact can set their IM status to “available”.
+            It does not make sense to allow the user to set this status on
+            herself; hence, on protocols where this status is supported, its
+            entry in <tp:member-ref>Statuses</tp:member-ref> SHOULD have
+            <var>May_Set_On_Self</var> set to <code>False</code>.</td>
+        </tr>
+        <tr>
+          <td><code>"away"</code></td>
+          <td>Away</td>
           <td></td>
         </tr>
         <tr>
-          <td>brb</td>
-          <td>Connection_Presence_Type_Away</td>
+          <td><code>"brb"</code></td>
+          <td>Away</td>
           <td>Be Right Back (a more specific form of Away)</td>
         </tr>
         <tr>
-          <td>busy</td>
-          <td>Connection_Presence_Type_Busy</td>
+          <td><code>"busy"</code></td>
+          <td>Busy</td>
           <td></td>
         </tr>
-        <tr><td>dnd</td>
-          <td>Connection_Presence_Type_Busy</td>
+        <tr>
+          <td><code>"dnd"</code></td>
+          <td>Busy</td>
           <td>Do Not Disturb (a more specific form of Busy)</td>
         </tr>
         <tr>
-          <td>xa</td>
-          <td>Connection_Presence_Type_Extended_Away</td>
+          <td><code>"xa"</code></td>
+          <td>Extended_Away</td>
           <td>Extended Away</td>
         </tr>
         <tr>
-          <td>hidden</td>
-          <td>Connection_Presence_Type_Hidden</td>
+          <td><code>"hidden"</code></td>
+          <td>Hidden</td>
           <td>Also known as "Invisible" or "Appear Offline"</td>
         </tr>
         <tr>
-          <td>offline</td>
-          <td>Connection_Presence_Type_Offline</td>
+          <td><code>"offline"</code></td>
+          <td>Offline</td>
           <td></td>
         </tr>
         <tr>
-          <td>unknown</td>
-          <td>Connection_Presence_Type_Unknown</td>
+          <td><code>"unknown"</code></td>
+          <td>Unknown</td>
           <td>special, see below</td>
         </tr>
         <tr>
-          <td>error</td>
-          <td>Connection_Presence_Type_Error</td>
+          <td><code>"error"</code></td>
+          <td>Error</td>
           <td>special, see below</td>
         </tr>
       </table>
diff --git a/spec/Connection_Manager.xml b/spec/Connection_Manager.xml
index 3683fcad..10ade57e 100644
--- a/spec/Connection_Manager.xml
+++ b/spec/Connection_Manager.xml
@@ -196,11 +196,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         </tp:docstring>
       </arg>
       <tp:docstring>
-        Get a list of the parameters which must or may be provided to the
-        <tp:member-ref>RequestConnection</tp:member-ref> method when connecting
-        to the given protocol,
-        or registering (the boolean &quot;register&quot; parameter is available,
-        and set to true).
+        Get a list of the parameters which may be specified in the
+        <tp:dbus-ref namespace='ofdT.Account'>Parameters</tp:dbus-ref> of an
+        <tp:dbus-ref namespace='ofdT'>Account</tp:dbus-ref> (or, for
+        specialised applications which do not use the account manager, passed
+        to <tp:member-ref>RequestConnection</tp:member-ref>). Some parameters
+        are mandatory, and some parameters only make sense when registering new
+        accounts with the server; see the <tp:type>Param_Spec</tp:type>
+        documentation for more details.
       </tp:docstring>
       <tp:possible-errors>
         <tp:error name="org.freedesktop.Telepathy.Error.NotImplemented">
@@ -323,6 +326,15 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
           <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection">Connect</tp:dbus-ref>
           method.</p>
 
+        <p><strong>Most applications should not use this method</strong>: they
+          should instead use the the <tp:dbus-ref
+          namespace='ofdT.Account'>Connection</tp:dbus-ref> property on an
+          <tp:dbus-ref namespace='ofdT'>Account</tp:dbus-ref> object obtained
+          from the <tp:dbus-ref
+          namespace='ofdT'>AccountManager</tp:dbus-ref>. This method is used
+          internally by the account manager to create connections when
+          needed.</p>
+
         <p>The parameters which must and may be provided in the parameters
         dictionary can be discovered with the
         <tp:member-ref>GetParameters</tp:member-ref> method. These
diff --git a/spec/Media_Stream_Handler.xml b/spec/Media_Stream_Handler.xml
index 123ea8be..0a833709 100644
--- a/spec/Media_Stream_Handler.xml
+++ b/spec/Media_Stream_Handler.xml
@@ -20,6 +20,12 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
   </tp:license>
   <interface name="org.freedesktop.Telepathy.Media.StreamHandler">
 
+    <tp:docstring>
+    Handles signalling the information pertaining to a specific media stream.
+    A client should provide information to this handler as and when it is
+    available.
+    </tp:docstring>
+
     <tp:struct name="Media_Stream_Handler_Candidate"
       array-name="Media_Stream_Handler_Candidate_List">
       <tp:member type="s" name="Name"/>
@@ -533,7 +539,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:docstring>
         Signal emitted when the connection manager wishes to inform the
         client of the codecs supported by the remote end.
-	If these codecs are compatible with the remote codecs, then the client
+        If these codecs are compatible with the remote codecs, then the client
         must call <tp:member-ref>SupportedCodecs</tp:member-ref>,
         otherwise call <tp:member-ref>Error</tp:member-ref>.
       </tp:docstring>
@@ -581,16 +587,16 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
      <arg name="Codec_ID" type="u">
         <tp:docstring>
           The payload type to use when sending events. The value 0xFFFFFFFF
-	  means to send with the already configured event type instead of using
-	  the specified one.
+          means to send with the already configured event type instead of using
+          the specified one.
         </tp:docstring>
       </arg>
       <tp:docstring>
         Request that a telephony event (as defined by RFC 4733) is transmitted
         over this stream until StopTelephonyEvent is called. This differs from
         StartTelephonyEvent in that you force the event to be transmitted
-	as a RFC 4733 named event, not as sound. You can also force a specific
-	Codec ID.
+        as a RFC 4733 named event, not as sound. You can also force a specific
+        Codec ID.
       </tp:docstring>
     </signal>
     <signal name="StartSoundTelephonyEvent"
@@ -605,7 +611,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         Request that a telephony event (as defined by RFC 4733) is transmitted
         over this stream until StopTelephonyEvent is called. This differs from
         StartTelephonyEvent in that you force the event to be transmitted
-	as sound instead of as a named event.
+        as sound instead of as a named event.
       </tp:docstring>
     </signal>
     <signal name="StopTelephonyEvent"
@@ -715,11 +721,186 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
       <tp:added version="0.17.3"/>
     </method>
 
-    <tp:docstring>
-    Handles signalling the information pertaining to a specific media stream.
-    A client should provide information to this handler as and when it is
-    available.
-    </tp:docstring>
+    <tp:struct name="RTCP_Feedback_Message_Properties">
+      <tp:added version="0.22.1"/>
+      <tp:changed version="0.23.4">This struct is also used by Call, but
+        in call, the CM should know about RTP profiles, and never use MAXUINT
+        as a default value, because it complicates things unnecessarily.
+      </tp:changed>
+      <tp:member type="u" name="RTCPMinimumInterval">
+        <tp:docstring>
+          The minimum interval between two regular RTCP packets in
+          milliseconds for this content. If no special value is desired, one
+          should put MAXUINT (0xFFFFFFFF).
+
+          Implementors and users of Call's <tp:dbus-ref
+          namespace="ofdT.Call1.Content.MediaDescription.Interface"
+          >RTCPFeedback</tp:dbus-ref> should not use the MAXUINT default.
+          Instead, in RTP/AVP, the default should be 5000 (5 seconds).
+          If using the RTP/AVPF profile, it can be set to a lower value,
+          the default being 0.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="a(sss)" tp:type="RTCP_Feedback_Message[]"
+                 name="Messages">
+        <tp:docstring>
+          The RTCP feedback messages for this codec.
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <tp:struct name="RTCP_Feedback_Message"
+               array-name="RTCP_Feedback_Message_List">
+      <tp:added version="0.22.1"/>
+      <tp:docstring>
+        A struct defining an RTCP feedback message.
+      </tp:docstring>
+      <tp:member type="s" name="Type">
+        <tp:docstring>
+          Feedback type, for example "ack", "nack", or "ccm".
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="s" name="Subtype">
+        <tp:docstring>
+          Feedback subtype, according to the Type, can be an empty string (""),
+          if there is no subtype.
+          For example, generic nack is Type="nack" Subtype="".
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="s" name="Parameters">
+        <tp:docstring>
+          Feedback parameters as a string. Format is defined in the relevant RFC
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <tp:mapping name="RTCP_Feedback_Message_Map">
+      <tp:added version="0.22.1"/>
+      <tp:docstring>
+        A map of codec and its feedback properties.
+      </tp:docstring>
+      <tp:member type="u" name="Codec_Identifier">
+        <tp:docstring>
+          Numeric identifier for the codec. This will be used as the
+          PT in the SDP or content description.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="(ua(sss))" tp:type="RTCP_Feedback_Message_Properties"
+                 name="Properties">
+        <tp:docstring>
+          The RTCP feedback properties for this codec.
+        </tp:docstring>
+      </tp:member>
+    </tp:mapping>
+
+    <signal name="SetRemoteFeedbackMessages"
+            tp:name-for-bindings="Set_Remote_Feedback_Messages">
+      <tp:added version="0.22.1"/>
+      <arg name="Messages" type="a{u(ua(sss))}"
+           tp:type="RTCP_Feedback_Message_Map">
+        <tp:docstring>
+          Remote Feedback messages desired by the remote side
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        Signal emitted when the connection manager wishes to inform the
+        client of the feedback messages supported by the remote end.
+        This signal is emitted before
+        <tp:member-ref>SetRemoteCodecs</tp:member-ref>. If the client
+        supports any of these messages, it must call
+        <tp:member-ref>SupportedFeedbackMessages</tp:member-ref> before calling
+        <tp:member-ref>SupportedCodecs</tp:member-ref>.
+      </tp:docstring>
+    </signal>
+
+    <method name="SupportedFeedbackMessages"
+            tp:name-for-bindings="Supported_Feedback_Messages">
+      <tp:added version="0.22.1"/>
+      <arg name="Messages" direction="in" type="a{u(ua(sss))}"
+           tp:type="RTCP_Feedback_Message_Map">
+        <tp:docstring>
+          Locally supported feedback messages.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        Inform the connection manager of the supported feedback messages
+        for this session.
+        This is called a before calling
+        <tp:member-ref>SupportedCodecs</tp:member-ref>,
+        <tp:member-ref>Ready</tp:member-ref> or
+        <tp:member-ref>CodecsUpdated</tp:member-ref> to indicate the local,
+        or negotiated feedback messages.
+      </tp:docstring>
+    </method>
+
+    <tp:struct name="RTP_Header_Extension"
+      array-name="RTP_Header_Extensions_List">
+      <tp:added version="0.22.1"/>
+      <tp:docstring>
+        A struct defining a RTP Header extension
+      </tp:docstring>
+      <tp:member type="u" name="ID">
+        <tp:docstring>
+          Identifier to be negotiated
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="u" tp:type="Media_Stream_Direction"  name="Direction">
+        <tp:docstring>
+          Direction in which the Header Extension is negotiated.
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="s" name="URI">
+        <tp:docstring>
+          URI defining the extension
+        </tp:docstring>
+      </tp:member>
+      <tp:member type="s" name="Parameters">
+        <tp:docstring>
+          Feedback parameters as a string. Format is defined in the relevant RFC
+        </tp:docstring>
+      </tp:member>
+    </tp:struct>
+
+    <signal name="SetRemoteHeaderExtensions"
+            tp:name-for-bindings="Set_Remote_Header_Extensions">
+      <tp:added version="0.22.1"/>
+      <arg name="Header_Extensions" type="a(uuss)"
+           tp:type="RTP_Header_Extension[]">
+        <tp:docstring>
+          Header extensions desired by the remote side
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        Signal emitted when the connection manager wishes to inform the
+        client of the RTP header extensions supported by the remote end.
+        This signal is emitted before
+        <tp:member-ref>SetRemoteCodecs</tp:member-ref>. If the client
+        supports any of these messages, it must call
+        <tp:member-ref>SupportedHeaderExtensions</tp:member-ref> before calling
+        <tp:member-ref>SupportedCodecs</tp:member-ref>.
+      </tp:docstring>
+    </signal>
+
+    <method name="SupportedHeaderExtensions"
+            tp:name-for-bindings="Supported_Header_Extensions">
+      <tp:added version="0.22.1"/>
+      <arg name="Header_Extensions" direction="in" type="a(uuss)"
+           tp:type="RTP_Header_Extension[]">
+        <tp:docstring>
+          Locally supported RTP header extensions.
+        </tp:docstring>
+      </arg>
+      <tp:docstring>
+        Inform the connection manager of the supported RTP header extensions
+        for this session.
+        This is called before calling
+        <tp:member-ref>SupportedCodecs</tp:member-ref>,
+        <tp:member-ref>Ready</tp:member-ref> or
+        <tp:member-ref>CodecsUpdated</tp:member-ref> to indicate the local
+        or negotiated RTP header extensions.
+      </tp:docstring>
+    </method>
+
   </interface>
 </node>
 <!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/spec/Properties_Interface.xml b/spec/Properties_Interface.xml
index bc9c8b26..09ce3b9c 100644
--- a/spec/Properties_Interface.xml
+++ b/spec/Properties_Interface.xml
@@ -19,6 +19,8 @@ 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.Properties">
+    <tp:deprecated version="0.24.0">All uses of this interface have been
+      expunged, and it may now be laid to rest.</tp:deprecated>
 
     <tp:struct name="Property_Spec" array-name="Property_Spec_List">
       <tp:docstring>A struct (property ID, property name, D-Bus signature,
diff --git a/spec/Protocol.xml b/spec/Protocol.xml
index 5e2c9b19..f779492f 100644
--- a/spec/Protocol.xml
+++ b/spec/Protocol.xml
@@ -99,10 +99,15 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
       access="read" type="a(susv)" tp:type="Param_Spec[]"
       tp:immutable="yes">
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>The parameters which must or may be provided to the
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.ConnectionManager"
-            >RequestConnection</tp:dbus-ref> method when connecting to the
-          given protocol.</p>
+        <p>The parameters which may be specified in the
+          <tp:dbus-ref namespace='ofdT.Account'>Parameters</tp:dbus-ref> of an
+          <tp:dbus-ref namespace='ofdT'>Account</tp:dbus-ref> (or, for
+          specialised applications which do not use the account manager, passed
+          to <tp:dbus-ref
+          namespace='ofdT.ConnectionManager'>RequestConnection</tp:dbus-ref>).
+          Some parameters are mandatory, and some parameters only make sense
+          when registering new accounts with the server; see the
+          <tp:type>Param_Spec</tp:type> documentation for more details.</p>
 
         <p>Connection managers with a <code>.manager</code> file
           (as described as part of the
@@ -221,7 +226,7 @@ allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy
 
         <p>A more exhaustive list of addressable vCard fields can be found in
           the Protocol's Addressing interface's
-          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing.DRAFT">AddressableVCardFields</tp:dbus-ref>.</p>
+          <tp:dbus-ref namespace="org.freedesktop.Telepathy.Protocol.Interface.Addressing">AddressableVCardFields</tp:dbus-ref>.</p>
 
         <p>It is not necessarily valid to interpret contacts' identifiers
           as values of this vCard field. For instance, telepathy-sofiasip
diff --git a/spec/Protocol_Interface_Addressing.xml b/spec/Protocol_Interface_Addressing.xml
index 3722c3b8..0c62e1bd 100644
--- a/spec/Protocol_Interface_Addressing.xml
+++ b/spec/Protocol_Interface_Addressing.xml
@@ -21,9 +21,10 @@
   </tp:license>
 
   <interface
-     name="org.freedesktop.Telepathy.Protocol.Interface.Addressing.DRAFT"
-     tp:causes-havoc="experimental">
-    <tp:added version="0.19.12">(as draft)</tp:added>
+     name="org.freedesktop.Telepathy.Protocol.Interface.Addressing">
+    <tp:added version="0.25.1">(as stable API). From the draft,
+      NormalizeURI was renamed to NormalizeContactURI, clarifying that
+      it removes any actions from the URI.</tp:added>
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>An interface for protocols that support multiple forms of
         addressing contacts, for example through vCard addresses and URIs.</p>
@@ -62,13 +63,6 @@ AddressableURISchemes=tel;sip;
               schemes that make sense to resolve as a contact.</p>
           </tp:rationale>
 
-        <p>This property should only be used when the connection is
-          offline. When it is connected the addressable fields should be
-          retrieved from the
-          <tp:dbus-ref
-             namespace="org.freedesktop.Telepathy.Connection.Interface">Requests.RequestableChannelClasses</tp:dbus-ref>'s
-             TargetVCardField fixed-property instead.</p>
-
         <p>Connection managers with a <code>.manager</code> file
           MUST cache this property in the protocol's section of the
           <code>.manager</code> file if it is non-empty, using the key
@@ -102,6 +96,9 @@ AddressableURISchemes=tel;sip;
           <dd>The X-MSN vCard field. Used for MSN contacts.</dd>
           <dt><code>x-yahoo</code></dt>
           <dd>The X-YAHOO vCard field. Used for Yahoo! IDs.</dd>
+          <dt><code>x-facebook-id</code></dt>
+          <dd>Used for Facebook IDs in XMPP. If the user JID is
+          "-12345@chat.facebook.com" then the x-facebook-id is "12345"</dd>
         </dl>
 
       </tp:docstring>
@@ -147,7 +144,7 @@ AddressableURISchemes=tel;sip;
             For example: <code>xmpp:julien@example.com</code>.</dd>
           <dt><code>msnim</code></dt>
           <dd>For the purposes of
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing</tp:dbus-ref>,
             <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Addressing.DRAFT</tp:dbus-ref>,
             and
             <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Addressing.DRAFT</tp:dbus-ref>,
@@ -157,7 +154,7 @@ AddressableURISchemes=tel;sip;
             For example: <code>msnim:add?contact=julien</code>.</dd>
           <dt><code>aim</code></dt>
           <dd>For the purposes of
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing</tp:dbus-ref>,
             <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Addressing.DRAFT</tp:dbus-ref>,
             and
             <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Addressing.DRAFT</tp:dbus-ref>,
@@ -170,7 +167,7 @@ AddressableURISchemes=tel;sip;
             For example: <code>skype:julien</code>.</dd>
           <dt><code>ymsgr</code></dt>
           <dd>For the purposes of
-            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing.DRAFT</tp:dbus-ref>,
+            <tp:dbus-ref namespace="org.freedesktop.Telepathy">Protocol.Interface.Addressing</tp:dbus-ref>,
             <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection.Interface.Addressing.DRAFT</tp:dbus-ref>,
             and
             <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Addressing.DRAFT</tp:dbus-ref>,
@@ -217,7 +214,8 @@ AddressableURISchemes=tel;sip;
 
       <arg direction="in" name="VCard_Address" type="s">
         <tp:docstring>
-          The address to normalize.
+          The address to normalize, which is assumed to belong to a
+          contact (and not, for instance, a chatroom or server).
         </tp:docstring>
       </arg>
 
@@ -243,8 +241,9 @@ AddressableURISchemes=tel;sip;
       </tp:possible-errors>
     </method>
 
-    <method name="NormalizeURI"
-      tp:name-for-bindings="Normalize_URI">
+    <method name="NormalizeContactURI"
+      tp:name-for-bindings="Normalize_Contact_URI">
+      <tp:added version="0.25.1">(renamed from NormalizeURI)</tp:added>
       <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
         <p>Attempt to normalize the given contact URI. Where possible, this
           SHOULD return an address that would appear in the
@@ -258,8 +257,28 @@ AddressableURISchemes=tel;sip;
             namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>,
           this method SHOULD perform a best-effort normalization.</p>
 
-        <p>Example: <code>xmpp:eitan@EXAMPLE.COM</code> would be normalized to
-        <code>xmpp:eitan@example.com</code>.</p>
+        <p>If the URI has extra information beyond what's necessary to
+          identify a particular contact, such as an XMPP resource or an
+          action to carry out, this extra information SHOULD be removed.
+          If all URIs in a scheme contain a verb or action
+          (like <code>aim</code>, <code>ymsgr</code> and
+          <code>msnim</code> URIs), then the verb SHOULD be replaced
+          with the one specified in
+          <tp:member-ref>AddressableURISchemes</tp:member-ref>.</p>
+
+        <tp:rationale>
+          <p>This method is intended to normalize URIs stored in address
+            books, for instance. In protocols like XMPP, if you
+            vary the resource or action (query string), the URI still
+            refers to the same high-level contact.</p>
+        </tp:rationale>
+
+        <p>For instance,
+          <code>xmpp:romeo@Example.Com/Empathy?message;body=Hello</code>
+          would be normalized to <code>xmpp:romeo@example.com</code>,
+          and <code>aim:goim?screenname=Romeo%20M&amp;message=Hello</code>
+          would be normalized to
+          <code>aim:addbuddy?screenname=romeom</code>.</p>
 
         <p>This method MAY simply raise NotImplemented on some
         protocols, if it has no use.</p>
@@ -267,9 +286,18 @@ AddressableURISchemes=tel;sip;
 
       <arg direction="in" name="URI" type="s">
         <tp:docstring>
-          The URI to normalize. The URI's scheme (i.e. the part before
-          the first colon) MUST appear in
-          <tp:member-ref>AddressableURISchemes</tp:member-ref>.
+          <p>The URI to normalize, which is assumed to refer to a contact
+            (as opposed to, for instance, a chatroom or a server).</p>
+
+        <tp:rationale>
+          <p>In some protocols, like XMPP, there is no way to tell whether
+            a given URI refers to a contact or a chatroom by looking at
+            its syntax.</p>
+        </tp:rationale>
+
+          <p>The URI's scheme (i.e. the part before
+            the first colon) MUST appear in
+            <tp:member-ref>AddressableURISchemes</tp:member-ref>.</p>
         </tp:docstring>
       </arg>
 
@@ -289,7 +317,14 @@ AddressableURISchemes=tel;sip;
 
         <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
           <tp:docstring>
-            The URI is syntactically incorrect.
+            <p>The URI is syntactically incorrect or cannot be interpreted
+              as a reference to a contact.</p>
+
+            <tp:rationale>
+              <p>For instance, <code>aim:!?</code> is not a valid AIM URI,
+                while <code>aim:goaway?message=Absent</code> is a
+                valid AIM URI, but not a contact.</p>
+            </tp:rationale>
           </tp:docstring>
         </tp:error>
       </tp:possible-errors>
diff --git a/spec/Protocol_Interface_Avatars.xml b/spec/Protocol_Interface_Avatars.xml
index cd913510..1bf0515e 100644
--- a/spec/Protocol_Interface_Avatars.xml
+++ b/spec/Protocol_Interface_Avatars.xml
@@ -68,7 +68,7 @@ MaximumAvatarBytes=8192
 
     <property name="SupportedAvatarMIMETypes"
       tp:name-for-bindings="Supported_Avatar_MIME_Types"
-      type="as" access="read">
+      type="as" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
           namespace="org.freedesktop.Telepathy"
@@ -79,7 +79,7 @@ MaximumAvatarBytes=8192
 
     <property name="MinimumAvatarHeight"
       tp:name-for-bindings="Minimum_Avatar_Height"
-      type="u" access="read">
+      type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
           namespace="org.freedesktop.Telepathy"
@@ -90,7 +90,7 @@ MaximumAvatarBytes=8192
 
     <property name="MinimumAvatarWidth"
       tp:name-for-bindings="Minimum_Avatar_Width"
-      type="u" access="read">
+      type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
           namespace="org.freedesktop.Telepathy"
@@ -101,7 +101,7 @@ MaximumAvatarBytes=8192
 
     <property name="RecommendedAvatarHeight"
       tp:name-for-bindings="Recommended_Avatar_Height"
-      type="u" access="read">
+      type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
           namespace="org.freedesktop.Telepathy"
@@ -112,7 +112,7 @@ MaximumAvatarBytes=8192
 
     <property name="RecommendedAvatarWidth"
       tp:name-for-bindings="Recommended_Avatar_Width"
-      type="u" access="read">
+      type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
           namespace="org.freedesktop.Telepathy"
@@ -123,7 +123,7 @@ MaximumAvatarBytes=8192
 
     <property name="MaximumAvatarHeight"
       tp:name-for-bindings="Maximum_Avatar_Height"
-      type="u" access="read">
+      type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
           namespace="org.freedesktop.Telepathy"
@@ -134,7 +134,7 @@ MaximumAvatarBytes=8192
 
     <property name="MaximumAvatarWidth"
       tp:name-for-bindings="Maximum_Avatar_Width"
-      type="u" access="read">
+      type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
           namespace="org.freedesktop.Telepathy"
@@ -145,7 +145,7 @@ MaximumAvatarBytes=8192
 
     <property name="MaximumAvatarBytes"
       tp:name-for-bindings="Maximum_Avatar_Bytes"
-      type="u" access="read">
+      type="u" access="read" tp:immutable="yes">
       <tp:docstring>
         The expected value of the <tp:dbus-ref
           namespace="org.freedesktop.Telepathy"
diff --git a/spec/all.xml b/spec/all.xml
index 31db7806..7e8c8342 100644
--- a/spec/all.xml
+++ b/spec/all.xml
@@ -3,7 +3,7 @@
   xmlns:xi="http://www.w3.org/2001/XInclude">
 
 <tp:title>Telepathy D-Bus Interface Specification</tp:title>
-<tp:version>0.22.0</tp:version>
+<tp:version>0.25.1</tp:version>
 
 <tp:copyright>Copyright © 2005-2011 Collabora Limited</tp:copyright>
 <tp:copyright>Copyright © 2005-2011 Nokia Corporation</tp:copyright>
@@ -162,13 +162,17 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
    <xi:include href="Channel_Interface_Addressing.xml"/>
    <xi:include href="Channel_Interface_Anonymity.xml"/>
    <xi:include href="Channel_Interface_Destroyable.xml"/>
+   <xi:include href="Channel_Interface_File_Transfer_Metadata.xml"/>
    <xi:include href="Channel_Interface_Group.xml"/>
    <xi:include href="Channel_Interface_Password.xml"/>
    <xi:include href="Channel_Interface_Room.xml"/>
+   <xi:include href="Channel_Interface_Room_Config.xml"/>
    <xi:include href="Channel_Interface_SASL_Authentication.xml"/>
    <xi:include href="Channel_Interface_Credentials_Storage.xml"/>
    <xi:include href="Channel_Interface_Securable.xml"/>
    <xi:include href="Channel_Interface_Service_Point.xml"/>
+   <xi:include href="Channel_Interface_Subject.xml"/>
+   <xi:include href="Channel_Interface_Picture.xml"/>
    <xi:include href="Channel_Interface_Tube.xml"/>
 
    <tp:section name="Text-specific interfaces">
@@ -191,7 +195,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
        namespace='ofdT.Channel.Interface'>Hold</tp:dbus-ref> and
        <tp:dbus-ref namespace="ofdT.Channel.Interface">DTMF</tp:dbus-ref>
        interfaces, which may also appear on <tp:dbus-ref
-       namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref> channels.</p>
+       namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref> channels.</p>
     </tp:docstring>
 
     <xi:include href="Channel_Interface_Call_State.xml"/>
@@ -206,7 +210,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
        chat rooms. They are primarily intended for <tp:dbus-ref
        namespace='ofdT.Channel.Type'>Text</tp:dbus-ref>, <tp:dbus-ref
        namespace='ofdT.Channel.Type'>StreamedMedia</tp:dbus-ref> and
-       <tp:dbus-ref namespace='ofdT.Channel.Type'>Call.DRAFT</tp:dbus-ref>
+       <tp:dbus-ref namespace='ofdT.Channel.Type'>Call1</tp:dbus-ref>
        channels, but may also appear on other types of channel.</p>
     </tp:docstring>
 
@@ -236,9 +240,14 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
  <tp:section name="Calls">
    <xi:include href="Call_Content.xml"/>
    <xi:include href="Call_Content_Interface_Media.xml"/>
-   <xi:include href="Call_Content_Interface_Mute.xml"/>
+   <xi:include href="Call_Interface_Mute.xml"/>
    <xi:include href="Call_Content_Interface_Video_Control.xml"/>
-   <xi:include href="Call_Content_Codec_Offer.xml"/>
+   <xi:include href="Call_Content_Interface_Audio_Control.xml"/>
+   <xi:include href="Call_Content_Media_Description.xml"/>
+   <xi:include href="Call_Content_Media_Description_Interface_RTP_Header_Extensions.xml"/>
+   <xi:include href="Call_Content_Media_Description_Interface_RTCP_Feedback.xml"/>
+   <xi:include
+   href="Call_Content_Media_Description_Interface_RTCP_Extended_Reports.xml"/>
    <xi:include href="Call_Stream.xml"/>
    <xi:include href="Call_Stream_Interface_Media.xml"/>
    <xi:include href="Call_Stream_Endpoint.xml"/>
@@ -278,7 +287,6 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
  </tp:docstring>
  <xi:include href="Channel_Dispatcher.xml"/>
  <xi:include href="Channel_Dispatcher_Interface_Operation_List.xml"/>
- <xi:include href="Channel_Dispatcher_Interface_Messages.xml"/>
  <xi:include href="Channel_Dispatch_Operation.xml"/>
  <xi:include href="Channel_Request.xml"/>
 </tp:section>
diff --git a/spec/errors.xml b/spec/errors.xml
index 9afaa1c7..30c0b44c 100644
--- a/spec/errors.xml
+++ b/spec/errors.xml
@@ -386,6 +386,45 @@
     </tp:docstring>
   </tp:error>
 
+  <tp:error name="Media.Codecs Incompatible">
+    <tp:added version="0.23.4"/>
+    <tp:docstring>
+      Raised when the local streaming implementation has no codecs in common
+      with the remote side.
+
+      <tp:rationale>
+        This corresponds to
+        <tp:value-ref type="Call_State_Change_Reason">Media_Error</tp:value-ref>.
+      </tp:rationale>
+    </tp:docstring>
+  </tp:error>
+
+  <tp:error name="Media.Unsupported Type">
+    <tp:added version="0.23.4"/>
+    <tp:docstring>
+      The media stream type requested is not supported by either the
+      local or remote side.
+
+      <tp:rationale>
+        This corresponds to
+        <tp:value-ref type="Call_State_Change_Reason">Media_Error</tp:value-ref>.
+      </tp:rationale>
+    </tp:docstring>
+  </tp:error>
+
+  <tp:error name="Media.Streaming Error">
+    <tp:added version="0.23.4"/>
+    <tp:docstring>
+      Raised when the call's streaming implementation has some kind of internal
+      error.
+
+      <tp:rationale>
+        This corresponds to
+        <tp:value-ref type="Call_State_Change_Reason">Internal_Error</tp:value-ref>.
+      </tp:rationale>
+    </tp:docstring>
+  </tp:error>
+
   <tp:error name="Connection Refused">
     <tp:docstring>
       Raised when a connection is refused.
@@ -495,7 +534,7 @@
     <tp:added version="0.21.2"/>
     <tp:docstring>
       Raised when an incoming or outgoing <tp:dbus-ref
-      namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> is
+      namespace="ofdT.Channel.Type">Call1</tp:dbus-ref> is
       rejected by the the receiver.
     </tp:docstring>
   </tp:error>
@@ -537,7 +576,7 @@
         errors bad-format, invalid-xml, etc., which can't happen unless
         the local (or remote) XMPP implementation is faulty. This is
         also analogous to
-        <tp:type>Media_Stream_Error</tp:type>_Invalid_CM_Behavior,
+        <tp:value-ref type="Media_Stream_Error">Invalid_CM_Behavior</tp:value-ref>,
         <code>TP_DBUS_ERROR_INCONSISTENT</code> in telepathy-glib, and
         <code>TP_QT_ERROR_INCONSISTENT</code> in telepathy-qt.
       </tp:rationale>
@@ -581,6 +620,23 @@
     </tp:docstring>
   </tp:error>
 
+  <tp:error name="Insufficient Balance">
+    <tp:added version="0.22.1"/>
+    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+      <p>Raised if the user has insufficient
+        <tp:dbus-ref namespace="ofdT.Connection.Interface">Balance</tp:dbus-ref>
+        to place a call or send a message.</p>
+
+      <p>The key 'balance-required' MAY be included in
+        <tp:dbus-ref namespace="ofdT.Channel.Type.Call1">CallStateDetails</tp:dbus-ref>
+        or a delivery report's <tp:type>Message_Part</tp:type>
+        (with the same units and scale as
+        <tp:dbus-ref namespace="ofdT.Connection.Interface.Balance">AccountBalance</tp:dbus-ref>)
+        to indicate how much credit is required to make this call or send
+        this message.</p>
+    </tp:docstring>
+  </tp:error>
+
   <tp:copyright>Copyright © 2005-2010 Collabora Limited</tp:copyright>
   <tp:copyright>Copyright © 2005-2009 Nokia Corporation</tp:copyright>
   <tp:license xmlns="http://www.w3.org/1999/xhtml">
diff --git a/spec/template.xml b/spec/template.xml
index 72647207..283804a9 100644
--- a/spec/template.xml
+++ b/spec/template.xml
@@ -22,7 +22,7 @@
 
   <interface name="org.freedesktop.Telepathy.Foo.DRAFT"
     tp:causes-havoc="experimental">
-    <tp:added version="0.21.UNRELEASED">(draft 1)</tp:added>
+    <tp:added version="0.UNRELEASED">(draft 1)</tp:added>
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Foo.</p>