Bug 18170 - org.freedesktop.Telepathy.Connection.Interface.Capabilities: AdvertiseCapabilities() ignored
Summary: org.freedesktop.Telepathy.Connection.Interface.Capabilities: AdvertiseCapabil...
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
Depends on:
Reported: 2008-10-22 00:54 UTC by Stefan Eilers
Modified: 2009-02-09 07:06 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

D-BUS Dump of test case (32.04 KB, text/plain)
2008-10-22 02:13 UTC, Stefan Eilers

Description Stefan Eilers 2008-10-22 00:54:26 UTC
If I read my capabilities with GetCapabilities() I receive a "org.freedesktop.Telepathy.Channel.Type.Text"  as expected.

Regarding the documentation I should receive a signal after changing the capability. I tried to modify the received capability (modified the Type_Specific_Flags) and added a new capability "org.freedesktop.Telepathy.Channel.Type.StreamedMedia".
In both cases I do not receive a signal. Reading the my current capability after this changes just returns the original one without modification.

1. Is changing of the own capability implemented?
2. Which changes are supported/handled by gabble?

Thanks in advance!
Comment 1 Stefan Eilers 2008-10-22 02:13:55 UTC
Created attachment 19805 [details]
D-BUS Dump of test case

I've added a dump of the communication on D-BUS.
Comment 2 Alban Crequy 2008-10-23 13:36:10 UTC
1. Is changing of the own capability implemented?

Yes, it is implemented by Gabble: see

The signal CapabilitiesChanged should be emitted with your own handle if the previous caps and the new caps are different:

> if (caps ^ save_caps)
> ...
>   _emit_capabilities_changed (self, base->self_handle,
>          save_caps, caps);

There is some tests for the Connection.Interface.Capabilities interface but it seems AdvertiseCapabilities is not tested.

I will add a test for that.

2. Which changes are supported/handled by gabble?

I am not sure to understand the question.
Comment 3 Alban Crequy 2008-10-23 13:44:21 UTC
Note on this interface:

The interface Connection.Interface.Capabilities is not expressive enough for tube capabilities: an application cannot advertise a capability for its ad-hoc tube (example: it cannot advertise the "daap" stream tube capability).

The Connection.Interface.Capabilities will remain for compatibily but a new interface is in development in a branch:

I generated the html spec here:


from my git branch:


and there is a branch in Gabble and Salut that implements it.
Comment 4 Alban Crequy 2008-10-23 14:26:43 UTC
In your log, the specific flags you specify are "5", defined by:
That is all flags except Channel_Media_Capability_NAT_Traversal_GTalk_P2P.

I can reproduce the problem in this case. When I use the flags 15 (all bits set), it works and I receive the signal correctly.

What should be the correct behavior here?
Comment 5 Alban Crequy 2008-10-23 14:48:15 UTC
This is the piece of code I used to test this bug:

Comment 6 Stefan Eilers 2008-10-28 08:17:45 UTC
I'm not sure which behavior is correct.
I think that the client has to decide which capabilites are set and the connection manager should not ignore anything.
But it might be reasons of this behavior that I don't know.. 
Comment 7 Simon McVittie 2009-02-09 07:06:00 UTC
I believe the problem here is that the result of calling AdvertiseCapabilities is determined by details of the protocol - we tell you what capabilities other contacts will think you have as a result of the call to AdvertiseCapabilities.  You're not setting enough capabilities that other contacts will believe they can call you, and as a result, you're not callable. (In recent telepathy-spec versions, we've clarified that this is the case.)

In the case of XMPP, other XMPP clients won't believe they can call you unless you advertise support for at least one transport. gtalk-p2p (Google's variation of ICE) is the only transport currently implemented in Gabble (ICE-UDP and raw UDP are on the way), so Gabble is right to indicate that you aren't capable of receiving calls in this state. Gabble is behaving correctly, so closing as NOTABUG.

If you're using telepathy-stream-engine or telepathy-farsight with the recommended plugins, then you do support STUN, gtalk-p2p, audio and (UI permitting) video, so it's appropriate to set all these flags.

The ContactCapabilities interface, currently a draft, will improve the documentation and semantics of what you need to do to become callable. We'll hopefully also provide API in Telepathy-Qt4 and telepathy-glib that makes it easier to deal with media signalling.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.