> On Aug. 4, 2012, 10:26 a.m., George Kiagiadakis wrote: > > src/call-window.cpp, lines 477-478 > > <http://git.reviewboard.kde.org/r/105829/diff/4/?file=75962#file75962line477> > > > > This cannot happen in StateUnheld. It should also be handled as unknown > > error. > > Rohan Garg wrote: > Why not? Let's say the user hold's a call and a couple of seconds later > the driver responsible for Video/Audio capture crashes or the wires are not > securely connected causing a input error. Won't the telepathy backend reply > with a Tp::LocalHoldStateReasonResourceNotAvailable error?
No, if the call is Unheld and something goes wrong with the gstreamer pipeline, if tp-farstream is aware of the problem, it will simply change the direction of the Call.Stream object(s) so that media doesn't flow from the side that there is an error. Or alternatively, if the error is fatal, the call will terminate with an appropriate CallStateReason. The ResourceNotAvailable *hold state* reason here only exists because it is possible that while trying to put a call off hold, some device may not be opening (for example because some other program captured the camera while we were on hold - note that we close all devices while we are on hold). In this case, the Call returns to StateHeld with reason = ResourceNotAvailable instead of altering streams or terminating the call. See the possible state changes here: http://telepathy.freedesktop.org/spec/Channel_Interface_Hold.html#Method:RequestHold > On Aug. 4, 2012, 10:26 a.m., George Kiagiadakis wrote: > > src/main.cpp, line 67 > > <http://git.reviewboard.kde.org/r/105829/diff/4/?file=75964#file75964line67> > > > > This will cause a failure if the hold interface is not available in the > > call, but I think both gabble and rakia implement it so I think we can get > > away with it for now > > Rohan Garg wrote: > Is it possible to query the backend if a particular feature is available? > If yes, why not do it for all the features we add? Not possible at this point. Don't be concerned with that, it is something that needs fixing in telepathy-qt. - George ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105829/#review16852 ----------------------------------------------------------- On Aug. 3, 2012, 9:56 p.m., Rohan Garg wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105829/ > ----------------------------------------------------------- > > (Updated Aug. 3, 2012, 9:56 p.m.) > > > Review request for Telepathy. > > > Description > ------- > > Enables call holding in ktp-call-ui > > > Diffs > ----- > > src/main.cpp 4ab3a23 > src/call-window.ui 14144cc > src/call-window.h d8741c3 > src/call-window.cpp e4aed4d > src/call-manager.cpp df6e701 > > Diff: http://git.reviewboard.kde.org/r/105829/diff/ > > > Testing > ------- > > Successfully held and unheld calls using ktp-call-ui > > > Thanks, > > Rohan Garg > >
_______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
