Hi Robert > Hi Matthieu, > > Please don't repeatedly post the same question to the list. This thread > is now 14 deep in my mail client, and only has 4 or 5 posts which are > not from you, so I think most people might not even have seen that you > were posting there any more. It might help that if you have a new > question, start a new thread. >
First of all, thank you for your answer. I am new in the world of open source, so thank you for educating me and giving me some advises. I am also new in the telepathy world. I understand more and more things but there are still some interactions between processes (telepathy-cilent (tp_caller), connection-manager, stream-engine) that are not clear, and some details I don t understand... but I am working on it :) > That said, nobody is under any /obligation/ to help you, although we are > happy to help people if they are polite and have reasonable questions. > If you are using Telepathy for a commercial project and /require/ a > support arrangement, you might follow the link off the Telepathy > homepage to Collabora, who can offer commercial support for users of the > project. > > You might also note that tp_caller is just a piece of test/example code > released by Nokia as part of tp-sofiasip, and isn't a very good thing to > try and ask for detailed information about using - we don't know much > about it at all. The Python examples call.py and call-gtk.py in > telepathy-python/examples/ are a much simpler starting point to > understand the APIs you're trying to use. > > Matthieu LAURENT wrote: > >> I don't see any binding in libtelepathy in order to access interface >> org.freedesktop.Telepathy.StreamEngine, method SetOutputVolume for example >> >> Could you tell me how to add this functionality in libtelepathy, and how >> to call it from the telepathy client tp_caller, in oder to access >> directly to the whole interface of the stream-engine (or if there is a >> simplest way to access this function SetOutputVolume)? >> > > You can see the whole D-Bus API of stream engine by introspecting it > over the bus, or by viewing > stream-engine/generate/xml-modified/tp-stream-engine.xml. This API is > specific to stream engine, and isn't a part of the Telepathy standard, > which is why libtelepathy doesn't contain it. You can either use > dbus-binding-tool on the XML file and generate the same kinds of headers > that libtelepathy contains. > > Alternatively, for simple usages you can also use dbus-glib directly to > make calls to these functions by making a DBusGProxy and use > dbus_g_proxy_call (proxy, "MethodName", G_TYPE_FOO, foo, G_TYPE_INVALID, > G_TYPE_BAR, &bar, G_TYPE_INVALID) for a method called MethodName which > took a FOO argument called "foo" and returned a BAR argument called "bar". > ok I understand what you mean. I can create a binding like libetelpathy, that will make easier calls to stream-engine, or directly call the dbus interface thanks dbus-glib. So the telepathy-client (tp_caller, or another on) can directly call methods of the stream-engine, without passing through the connection-manager. Am I right? > Elsewhere, Matthieu LAURENT also wrote: > >> If I would like the stream-engine to bring back information to the >> telepathy client tp_caller, for example current duration of the call. >> What should I implement? >> Can the information be addressed directly to the telepathy client >> tp_caller or must it passed through the connection-manager? >> > > At the moment, you should just start a timer when a) the call is > accepted (the MembersChanged signal is emitted on the channel and both > members of the call are no longer local or remote pending) and b) the > Receiving signal is emitted by Stream Engine, indicating that packets > are being received. > > I am going to add some kind of StreamStateChanged signal to Stream > Engine's API which will tell you when the stream is either Sending *or* > Receiving. This fixes a minor issue with just looking at the Receiving > signal - in some cases you don't think the call is in progress until the > remote end makes some noise and sends some packets. > the example of the duration was just an example. I may want to inform the telepathy-client of current delay in communication; percentage of rebuffering in the buffer-jitter queue... What is the best way to bring this information from the stream-engine to the telepathy-client? Send regularly signals from the stream-engine that will be caught by the telepathy-client (without passing through the connection-manager)? If yes, this means, as you said, add some signal to the stream engine's api. > >> thanks for your help >> >> Matthieu >> > > Regards, > Rob Thanks again for your help Matthieu
_______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
