GNOME Bugzilla – Bug 582597
Accept/Decline incoming call dialog should ask if we want to send video
Last modified: 2011-04-19 14:26:16 UTC
As said on bug #582589 if an incoming call can't be upgraded to audio/video once accepted, the dialog should display a ticky box to send video when accepting. Or maybe we should always do that if the call supports video?
The "Send Video" button will be set to True by default if InitialVideo is set. * If ImmutableStreams is set: the button is unsensitive. * If ImmutableStreams is NOT set: the button is sensitive. If it's changed we'll have to call RequestStreamDirection *before* accepting the call to enable/disable video.
Actually the only case when the button should be insensitive is when ImmutableStreams is set and InitialVideo is NOT set. In all the other cases we can always change the stream direction before accepting.
I started implementing this in this branch but I'm currently facing 2 issues: http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/send-video-582597 A) When accepting an incoming video call from the echo bot, it displays only the first frame of my video. This is a regression from master. B) Adding video to an incoming audio call doesn't work because of this Gabble bug: http://bugs.freedesktop.org/show_bug.cgi?id=26093
<sjoerd> cassidy: simple workaround, make it possible to turn of video once an a/v call comes in, but don't allow video being turned on if only an audio call comes in
I implemented this workaround so the only remaining issue is A). I noticed that this regression has been introduced by this commit: http://git.collabora.co.uk/?p=user/cassidy/empathy;a=commitdiff;h=e4e7a513127789b3dc772aac61c6fea75049021d More precisely by this hunk: @@ -310,6 +313,8 @@ event_manager_call_window_confirmation_dialog_response_cb (GtkDialog *dialog, else { EmpathyCallFactory *factory = empathy_call_factory_get (); + + empathy_tp_call_request_video_stream_direction (call, send_video); empathy_call_factory_claim_channel (factory, approval->operation); } } Calling this function when accepting an incoming video call (with video enabled, so send_video=TRUE) causes the regression. empathy_tp_call_request_video_stream_direction calls tp_cli_channel_type_streamed_media_call_request_stream_direction with 3 as direction (Bidirectional). This adds the following in the Gabble logs: (telepathy-gabble:27364): gabble-DEBUG: gabble_media_channel_request_stream_direction: called (stream stream2, direction 3) (telepathy-gabble:27364): gabble-DEBUG: gabble_media_stream_set_property: changing combined direction from 6 to 3 (telepathy-gabble:27364): gabble-DEBUG: stream_direction_changed_cb: direction: 3, pending_send: 0 (telepathy-gabble:27364): gabble-DEBUG: gabble_media_stream_change_direction: current_dir: 3, requested_dir: 3 Could that be the reason of this issue?
Created attachment 152025 [details] gabble logs
Actually, if you receive an immutable video call. Then you an accept it as-is (including the video) or you have to reject the whole call. So having a check box in the "accept call?" dialog does not make sense. You have to tell the user "this is a pure audio call or pure video call" ?
I know; that's why the checkbox is unsensitive when the call is immutable. Anyway, that's not the case here as the videocall is initiated by the echobot using proper Jingle (not google video) and I do accept video.
Let's redo this for Call as that's the way to go.
This has been fixed with Call.