From #24936 > > > Chan.I.DTMF has methods that are in terms of integer stream IDs. We could > > > either reimplement it as a channel interface in terms of streams' object paths, > > > or reimplement it as a stream (or even content) interface? > > It should either be an interface on the Channel (with no stream identifier) or > on the Content. The same "data" is sent on all streams of one Content. I'd > personally be favorable to putting in on the Content. In any regular call there > will be only one audio Content, so no loss there. And in the case of a fancy > application, then the application can decide what it wants.
Mr Crêpe says: > If the RemoteCredentialsSet signal is fired again, and the credentials > have changed, then there has been an ICE restart. > Also, in the same case, the CM should empty the remote candidate list > If you the CM does an ICE restart, then it fires PleaseRestartICE > and tp-fs should reply with SetCredentials...
(In reply to comment #1) > Mr Crêpe says: Ignore this please, wrong bug.
We decided to use the Channel interface. I've already implemented this in gabble.
I'm unsure if this was the right decision.. picking one random audio channel seems strange.. I definitely this we should move DTMF onto the Content.
Moving this interface onto the Content object would also be a good occasion to remove the Stream argument too..
(In reply to comment #4) > I'm unsure if this was the right decision.. picking one random audio channel > seems strange.. I definitely this we should move DTMF onto the Content. Yeah I can get behind that. I don't understand my reasoning behind comment #3 over a year ago. Perhaps I'm wiser nowadays?
Created attachment 54997 [details] [review] patch The patch just copies the interface over to the Content and removes the Stream_ID stuff
Comment on attachment 54997 [details] [review] patch Review of attachment 54997 [details] [review]: ----------------------------------------------------------------- Looks good, gogogo.
Created attachment 55195 [details] [review] Updated patch that keeps InitialTones on the channel interface Actually, while implementing it, I realised that the InitialTones had to stay on the channel as it is a requestable property. So my suggestion is that when deprecating StreamedMedia, we deprecate everything in the Channel interface except for InitialTones. Attach patch reflects that. Here is a tp-glib branch with the implementation: http://cgit.collabora.com/git/user/tester/telepathy-glib.git/log/?h=call1-dtmf The nice thing about the new code is that the implementation is 100% inside tp-glib for gabble and rakia, they don't even have to know that DTMF exists.
InitialTones should have tp:requestable="oui" too. Other than that, yes.
Merged !
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.