According to the spec:

"
The RequestableChannelClasses for Call1 channels can be:
[( Fixed = { ...ChannelType: ...Call1,
            ...TargetHandleType: Contact,
            ...InitialVideo: True
          },
  Allowed = [ ...InitialVideoName,
              ...InitialAudio,
              ...InitialAudioName
            ]
),
( Fixed = { ...ChannelType: ...Call1,
            ...TargetHandleType: Contact,
            ...InitialAudio: True
          },
  Allowed = [ ...InitialAudioName,
              ...InitialVideo,
              ...InitialVideoName
            ]
)]
Clients aren't allowed to make outgoing calls that have neither initial audio nor initial video. Clearly, CMs which don't support video should leave out the first class and omit InitialVideo from the second class, and vice versa for CMs without audio support.
"

Apparently gabble advertises just:

[call1-1on1-5]
org.freedesktop.Telepathy.Channel.TargetHandleType u=1
org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.Call1
allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy.Channel.TargetID;org.freedesktop.Telepathy.Channel.Type.Call1.InitialAudio;org.freedesktop.Telepathy.Channel.Type.Call1.InitialAudioName;org.freedesktop.T
elepathy.Channel.Type.Call1.InitialVideo;org.freedesktop.Telepathy.Channel.Type.Call1.InitialVideoName;org.freedesktop.Telepathy.Channel.Type.Call1.MutableContents;

...which is not correct according to the spec, as the fixed properties do not contain Initial{Audio,Video}. This currently breaks tp-qt's capabilities detection, which follows the spec.