[Telepathy-commits] [telepathy-spec/master] MediaSignalling.FUTURE: Explain how FooTransportAvailable works in requests

[Simon McVittie]

---
 spec/Channel_Interface_Media_Signalling_Future.xml |   42 ++++++++++++++++++++
 1 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/spec/Channel_Interface_Media_Signalling_Future.xml b/spec/Channel_Interface_Media_Signalling_Future.xml
index 8690235..e1d2d25 100644
--- a/spec/Channel_Interface_Media_Signalling_Future.xml
+++ b/spec/Channel_Interface_Media_Signalling_Future.xml
@@ -110,6 +110,48 @@
             "standard" transports known to any connection manager, and
             lowers the "barrier to entry" for new Telepathy clients.</p>
         </tp:rationale>
+
+        <p>Clients making outgoing calls for which the same client that made
+          the request will handle the streaming MAY indicate their ability or
+          inability to handle particular transports by including
+          <code>ICETransportAvailable = true</code>,
+          <code>RawUDPTransportAvailable = false</code>, etc.
+          in the request properties parameter of their call to <tp:dbus-ref
+            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>
+          or similar functions. When they do so, the connection manager
+          SHOULD attempt to use a transport that the client has indicated
+          it is able to handle; if this is not possible, the connection
+          manager SHOULD raise an error instead of creating a channel.</p>
+
+        <tp:rationale>
+          <p>This enables such clients to restrict the CM to the subset of
+            transports supported by that particular client.</p>
+        </tp:rationale>
+
+        <p>Clients making outgoing calls for which they will not themselves
+          handle the streaming (e.g. an address book starting a call which
+          will be streamed by a separate call UI) SHOULD NOT include those
+          properties in the request.</p>
+
+        <tp:rationale>
+          <p>In general, such a client can't know the capabilities of the
+            streaming implementation, or even which streaming implementation
+            will be used.</p>
+        </tp:rationale>
+
+        <p>In the absence of any indication of supported transports from the
+          client, the connection manager SHOULD assume that the transports
+          indicated by calling SetSelfCapabilities are available. If
+          no transports were indicated as supported by calling
+          SetSelfCapabilities either, it SHOULD assume that any transport
+          that it can signal will be acceptable.</p>
+
+        <p>If this property, or any of the similar transport availability
+          properties, is passed to EnsureChannel (as opposed to CreateChannel),
+          the connection manager SHOULD ignore these properties when checking
+          whether it can return an existing channel as suitable; these
+          properties only become significant when the connection manager has
+          decided to create a new channel.</p>
       </tp:docstring>
     </property>
 
-- 
1.5.6.5