Opened 5 years ago

Closed 5 years ago

#6114 closed defect (fixed)

Can't hang up voice with user

Reported by: binary Owned by: ThibG
Priority: normal Milestone: 0.15
Component: jingle Version:
Severity: normal Keywords:
Cc: Blocked By:
Blocking: OS: All

Description

Bug description

There is no possibility to hang up the call if user has no voice capability. I mean if gajim thinks that user has no voice support but this user calls to it and call negotiated I will not be able to hang up the call because the button is inactive.

Steps to reproduce

  1. Call from jid with, for example, subscription "from" then we can't know user's capabilities
  1. Accept the call
  1. Can't hang up from gajim

Software versions

OS version: Gentoo GTK version:
PyGTK version:

Change History (6)

comment:1 Changed 5 years ago by asterix

I understand the problem, but I don't know how to properly fix that.

One solution: add a new property to Contact instances like "supported_features" where we put features that seems to be supported even if we don't have his cpas, like when we receive a file or a voice call.

Any better solution?

comment:2 follow-up: Changed 5 years ago by binary

I think that if we don't have caps we need to allow all the features: user will receive "feature-not-implemented" error if a feature is not supported and you will be able to properly inform about it.

But I don't clearly understand... Look: I have contact with two resources. I can call to the resource with lower priority. When this resource going offline and then online again (but I have open tab still) I can't call to the resource. As I understand caps should be received normally with available presence but buttons still unavailable.

comment:3 in reply to: ↑ 2 Changed 5 years ago by asterix

Replying to binary:

I think that if we don't have caps we need to allow all the features: user will receive "feature-not-implemented" error if a feature is not supported and you will be able to properly inform about it.

In this case caps are useless. No the properway is maybe to fix #4071

But I don't clearly understand... Look: I have contact with two resources. I can call to the resource with lower priority. When this resource going offline and then online again (but I have open tab still) I can't call to the resource. As I understand caps should be received normally with available presence but buttons still unavailable.

Indeed icons are not re-drawn correctly. Will look at that.

comment:4 Changed 5 years ago by binary

In this case caps are useless. No the properway is maybe to fix #4071

Why? It will be useful if client sends it's caps. If caps is not sent then client is bad and there are not our fault :)))

comment:5 Changed 5 years ago by binary

#4071 seems to be good but I don't think that any strict restrictions for user is good decision. I think that we must disable any functionality only if client broadcasts that it can't use these features (use service discovery to learn it is good idea too). Only in this case we can be sure that we don't make wrong decision and don't limit user when it's not necessary.

comment:6 Changed 5 years ago by Yann Leboulanger <asterix@…>

  • Milestone set to 0.15
  • Resolution set to fixed
  • Status changed from new to closed

(In [2258fef7fc35]) redraw chat buttons when we get caps information. Fixes #6114

Note: See TracTickets for help on using tickets.