Created attachment 19805 [details]
D-BUS Dump of test case

I've added a dump of the communication on D-BUS.

1. Is changing of the own capability implemented?

Yes, it is implemented by Gabble: see
src/connection.c:gabble_connection_advertise_capabilities()

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.

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:
Connection.Interface.ContactCapabilities.DRAFT

I generated the html spec here:

http://people.collabora.co.uk/~alban/tmp/spec.html#org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT

from my git branch:

http://git.collabora.co.uk/?p=user/alban/telepathy-spec.git;a=shortlog;h=refs/heads/alban-enhanced-contact-capabilities-with-complex-types

and there is a branch in Gabble and Salut that implements it.

In your log, the specific flags you specify are "5", defined by:
http://telepathy.freedesktop.org/spec.html#type-Channel_Media_Capabilities
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?

This is the piece of code I used to test this bug:

http://git.collabora.co.uk/?p=user/alban/telepathy-gabble.git;a=shortlog;h=refs/heads/alban-test-advertise-caps

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.. 

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.