[telepathy-spec/master] MediaSignalling.FUTURE: remove all the NAT traversal flags
Simon McVittie
simon.mcvittie at collabora.co.uk
Sun Aug 16 07:57:53 PDT 2009
We're pretty unanimous that this is not the way to do it.
---
spec/Channel_Interface_Media_Signalling_Future.xml | 122 --------------------
1 files changed, 0 insertions(+), 122 deletions(-)
diff --git a/spec/Channel_Interface_Media_Signalling_Future.xml b/spec/Channel_Interface_Media_Signalling_Future.xml
index bbb8b87..a31943f 100644
--- a/spec/Channel_Interface_Media_Signalling_Future.xml
+++ b/spec/Channel_Interface_Media_Signalling_Future.xml
@@ -38,127 +38,5 @@
</tp:rationale>
</tp:docstring>
- <property name="ICETransportAvailable"
- tp:name-for-bindings="ICE_Transport_Available"
- type="b" access="read">
- <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>True if this channel supports the use of the ICE-UDP transport
- (<a href="http://xmpp.org/extensions/xep-0176.html">XEP-0176</a>,
- <a href="http://tools.ietf.org/html/draft-ietf-mmusic-ice">ICE RFC
- draft)</a>. Various other transports have boolean properties
- that work in the same way as this one, so this description covers
- all such transports.</p>
-
- <p>This property is immutable (cannot change), and therefore SHOULD
- appear wherever immutable properties are reported, e.g. <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
- signals.</p>
-
- <p>Connection managers capable of signalling streamed media calls to
- contacts SHOULD include the properties representing all supported
- transports in the allowed properties list of the channel class
- in <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
- that advertises support for streamed media channels.</p>
-
- <p>Similarly, connection managers that support the <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities.DRAFT</tp:dbus-ref>
- interface SHOULD include all supported transports in the allowed
- properties list of the channel class that advertises a contact's
- ability to receive streamed media calls.</p>
-
- <p>Clients SHOULD NOT pass ICETransportAvailable and similar
- properties to <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>
- or similar functions. If they do, the connection manager MUST
- accept and ignore any such property that is in the allowed properties
- list.</p>
-
- <tp:rationale>
- <p>There is currently no way for clients to influence the choice
- of transport: in general, a client making a call can't know the
- capabilities of the streaming implementation, or even which
- streaming implementation will be used (channels will often be
- requested by an address book or similar application that will not
- handle the channel itself).</p>
-
- <p>If a mechanism for transport negotiation is added, it should be
- something that happens after the request, but before calling
- <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">Media.SessionHandler.Ready</tp:dbus-ref>,
- so that it is the streaming implementation that chooses the
- transport, rather than the requesting client.</p>
- </tp:rationale>
-
- <p>Clients that are able to receive calls with particular transports
- MUST include the following filters if calling <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT">SetSelfCapabilities</tp:dbus-ref>
- (clients of a <tp:dbus-ref
- namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref>
- SHOULD instead arrange for the ChannelDispatcher to do this,
- by including the filters in their <tp:dbus-ref
- namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref>
- properties):</p>
-
- <ul>
- <li>{ ChannelType = StreamedMedia, ICETransportAvailable = true }
- if the ICE transport is supported</li>
- <li>{ ChannelType = StreamedMedia, RawUDPTransportAvailable = true }
- if the raw UDP transport is supported</li>
- <li>... and so on, one filter per available transport.</li>
- </ul>
-
- <p>Connection managers MAY use this information to adjust the
- transports for which they advertise support to other contacts.</p>
-
- <tp:rationale>
- <p>In particular, in XMPP, the connection manager will not be
- callable unless a client has told it to advertise support for
- at least one transport.</p>
- </tp:rationale>
- </tp:docstring>
- </property>
-
- <property name="RawUDPTransportAvailable"
- tp:name-for-bindings="Raw_UDP_Transport_Available"
- type="b" access="read">
- <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>The same as <tp:member-ref>ICETransportAvailable</tp:member-ref>,
- but for raw UDP streaming as described by <a
- href="http://xmpp.org/extensions/xep-0177.html">XEP-0177</a>.</p>
- </tp:docstring>
- </property>
-
- <property name="GTalkP2PTransportAvailable"
- tp:name-for-bindings="GTalk_P2P_Transport_Available"
- type="b" access="read">
- <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>The same as <tp:member-ref>ICETransportAvailable</tp:member-ref>,
- but for the variant of ICE used by the Google Talk peer-to-peer
- connectivity establishment mechanism (as implemented in libjingle
- 0.3).</p>
- </tp:docstring>
- </property>
-
- <property name="WLM85TransportAvailable"
- tp:name-for-bindings="WLM_8_5_Transport_Available"
- type="b" access="read">
- <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>The same as <tp:member-ref>ICETransportAvailable</tp:member-ref>,
- but for the transport implemented by Windows Live Messenger 8.5 or
- later (which resembles ICE draft 6).</p>
- </tp:docstring>
- </property>
-
- <property name="WLM2009TransportAvailable"
- tp:name-for-bindings="WLM_2009_Transport_Available"
- type="b" access="read">
- <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
- <p>The same as <tp:member-ref>ICETransportAvailable</tp:member-ref>,
- but for the transport implemented by Windows Live Messenger 2009
- or later (which resembles ICE draft 19).</p>
- </tp:docstring>
- </property>
-
</interface>
</node>
--
1.5.6.5
More information about the telepathy-commits
mailing list