Update to spec 0.21.4

* add NewActiveTransportPair
* fix the namespace of MailNotification

7 files changed, 75 insertions, 9 deletions

diff --git a/spec/Call_Content.xml b/spec/Call_Content.xml
index 82d40443e..17ed71095 100644
--- a/spec/Call_Content.xml
+++ b/spec/Call_Content.xml
@@ -116,6 +116,15 @@
       </tp:possible-errors>
     </method>
 
+    <signal name="Removed" tp:name-for-bindings="Removed">
+      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
+        <p>Emitted when the content is removed from the call. This
+          is the same as the <tp:dbus-ref
+          namespace="ofdT.Channel.Type">Call.DRAFT.ContentRemoved</tp:dbus-ref>
+          signal.</p>
+      </tp:docstring>
+    </signal>
+
     <property name="Interfaces" tp:name-for-bindings="Interfaces"
       type="as" tp:type="DBus_Interface[]" access="read" tp:immutable="yes">
       <tp:added version="0.19.11"/>
diff --git a/spec/Call_Content_Interface_Media.xml b/spec/Call_Content_Interface_Media.xml
index 0552111a6..24811fd62 100644
--- a/spec/Call_Content_Interface_Media.xml
+++ b/spec/Call_Content_Interface_Media.xml
@@ -27,7 +27,14 @@
 
     <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
       <p>Interface to use by a software implementation of media
-        streaming.</p>
+        streaming. The reason behind splitting the members of this
+        interface out from the main <tp:dbus-ref
+        namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> interface is
+        that the software is not necessarily what controls the
+        media. An example of this is in GSM phones, where the CM just
+        tells the phone to dial a number and it does the audio routing
+        in a device specific hardware way and the CM does not need
+        to concern itself with codecs.</p>
 
       <p>On new <tp:dbus-ref
         namespace="ofdT.Channel.Type">Call.DRAFT</tp:dbus-ref> channels,
diff --git a/spec/Channel_Type_Call.xml b/spec/Channel_Type_Call.xml
index eb1a66358..a45d95622 100644
--- a/spec/Channel_Type_Call.xml
+++ b/spec/Channel_Type_Call.xml
@@ -52,11 +52,14 @@ 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> objects
-        represent the actual media that forms the Call (for example an
-        audio content and a video content). Calls always have one or
-        more Content objects associated with them.</p>
+      <p><tp:dbus-ref namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref>
+        objects 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
+        result, a new Call channel request MUST have either
+        <tp:member-ref>InitialAudio</tp:member-ref>=True, or
+        <tp:member-ref>InitialVideo</tp:member-ref>=True, or both,
+        as the Requestable Channel Classes will document.</p>
 
       <p><tp:dbus-ref
         namespace="ofdT.Call">Content.DRAFT</tp:dbus-ref> objects have
diff --git a/spec/Connection.xml b/spec/Connection.xml
index fb8cd228e..a694e2429 100644
--- a/spec/Connection.xml
+++ b/spec/Connection.xml
@@ -1102,7 +1102,7 @@ USA.</p>
             the Google XMPP Mail Notification extension, which can be used
             to implement <tp:dbus-ref
               namespace="org.freedesktop.Telepathy.Connection.Interface"
-              >MailNotification.DRAFT</tp:dbus-ref>. In this protocol, the CM
+              >MailNotification</tp:dbus-ref>. In this protocol, the CM
             receives a notification that something has changed, but to get
             more information, the CM must request this information. Knowing
             that nobody is currently interested in this information, the CM
diff --git a/spec/Connection_Interface_Mail_Notification.xml b/spec/Connection_Interface_Mail_Notification.xml
index 003e255c1..1ac6d1a67 100644
--- a/spec/Connection_Interface_Mail_Notification.xml
+++ b/spec/Connection_Interface_Mail_Notification.xml
@@ -19,7 +19,7 @@ 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.Connection.Interface.MailNotification.DRAFT">
+    name="org.freedesktop.Telepathy.Connection.Interface.MailNotification">
     <tp:requires interface="org.freedesktop.Telepathy.Connection"/>
     <tp:added version="0.21.3">(as stable API)</tp:added>
 
diff --git a/spec/Media_Stream_Handler.xml b/spec/Media_Stream_Handler.xml
index 8881c115b..123ea8be7 100644
--- a/spec/Media_Stream_Handler.xml
+++ b/spec/Media_Stream_Handler.xml
@@ -337,6 +337,53 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.</
         has been discovered and streaming is in progress.
       </tp:docstring>
     </method>
+    <method name="NewActiveTransportPair"
+      tp:name-for-bindings="New_Active_Transport_Pair">
+      <arg direction="in" name="Native_Candidate_ID" type="s"/>
+      <arg direction="in" name="Native_Transport" type="(usuussduss)"
+        tp:type="Media_Stream_Handler_Transport"/>
+      <arg direction="in" name="Remote_Candidate_ID" type="s"/>
+      <arg direction="in" name="Remote_Transport" type="(usuussduss)"
+        tp:type="Media_Stream_Handler_Transport"/>
+      <tp:docstring>
+        <p>Informs the connection manager that a valid transport pair
+          has been discovered and streaming is in progress. Component
+          id MUST be the same for both transports and the pair is
+          only valid for that component.</p>
+
+        <tp:rationale>
+          <p>The connection manager might need to send the details of
+            the active transport pair (e.g. c and o parameters of SDP
+            body need to contain address of selected native RTP transport
+            as stipulated by RFC 5245). However, the candidate ID might
+            not be enough to determine these info if the transport was
+            found after <tp:member-ref>NativeCandidatesPrepared</tp:member-ref>
+            has been called (e.g. peer reflexive ICE candidate). </p>
+        </tp:rationale>
+
+        <p>This method must be called before
+          <tp:member-ref>NewActiveCandidatePair</tp:member-ref>.</p>
+
+        <tp:rationale>
+          <p>This way, connection managers supporting this method can
+            safely ignore subsequent
+            <tp:member-ref>NewActiveCandidatePair</tp:member-ref> call.</p>
+        </tp:rationale>
+
+        <p>Connection managers SHOULD NOT implement this method unless
+          they need to inform the peer about selected transports. As a
+          result, streaming implementations MUST NOT treat errors raised
+          by this method as fatal.</p>
+
+        <tp:rationale>
+          <p>Usually, connection managers only need to do one answer/offer
+            round-trip. However, some protocols give the possibility to
+            to send an updated offer (e.g. ICE defines such mechanism to
+            avoid some race conditions and to properly set the state of
+            gateway devices).</p>
+        </tp:rationale>
+      </tp:docstring>
+    </method>
     <tp:enum name="Media_Stream_Base_Proto" type="u">
       <tp:enumvalue suffix="UDP" value="0">
         <tp:docstring>UDP (User Datagram Protocol)</tp:docstring>
diff --git a/spec/all.xml b/spec/all.xml
index d3f1d851b..afb48dfc6 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.21.3</tp:version>
+<tp:version>0.21.4</tp:version>
 
 <tp:copyright>Copyright © 2005-2010 Collabora Limited</tp:copyright>
 <tp:copyright>Copyright © 2005-2010 Nokia Corporation</tp:copyright>