Re: FSO and VoIP
Hi, On Thu, Apr 23, 2009 at 5:29 AM, Nicola Mfb wrote: > Hi! > I'm experimenting some VoIP solution on Freerunner and need > suggestions about using it togheter with GSM. > I guess the only solution is to disable alsa scenarios switch/ring > rules in framekworkd.conf and write a dialer that interacts both with > FSO and the VoIP stack. > Are there other solutions? and in the long term are there plans for > VoIP integration/support directly in FSO? > In general all applications using audio in a critical way may suffer > for alsa scenario switching on incoming call, is there a dbus way to > say to frameworkd to avoid incoming call trigger events? > I was thinking some time ago in another approach, but due to lack of time i didn't started anything yet. It would be really nice to have a SW modem/device that interacts with your preferred VoIP transport agent through fso framework, doing it transparent to the dialer, and allowing to use the same dialer. This would be helpful to improve the dialer apps, allowing us to choose what "modem"/device we wan't for doing the call. I'd like to see any comments > Regards > > Nicola > > ___ > Smartphones-userland mailing list > Smartphones-userland@linuxtogo.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland > Best Regards, -- ___ Rafael Campos o0 Methril 0o http://openblog.methril.net/ ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO and VoIP
On Thursday 23 April 2009, Nicola Mfb wrote: > Hi! > I'm experimenting some VoIP solution on Freerunner and need > suggestions about using it togheter with GSM. > I guess the only solution is to disable alsa scenarios switch/ring > rules in framekworkd.conf and write a dialer that interacts both with > FSO and the VoIP stack. > Are there other solutions? and in the long term are there plans for > VoIP integration/support directly in FSO? > In general all applications using audio in a critical way may suffer > for alsa scenario switching on incoming call, is there a dbus way to > say to frameworkd to avoid incoming call trigger events? It was suggested fairly early on that the org.freesmartphone.Phone and org.freesmartphone.Phone.Call interfaces would be able to handle other backends as well as GSM. I've been looking at adding a SIP backend using liblinphone, but lack of skill is holding me back. Mapping the dbus methods and signals to the SIP ones from liblinphone looks like it would be easy if I knew my way around C, or interfacing C with Python. From what I remember of call handling in asterisk the mapping there shouldn't be too hard either. I would like to see a single dialer that handles both GSM and VoIP (and any other) calls. If the dialer already uses the above interfaces then it shouldn't need too much modification to support the extra protocols. Then again I've not tried using this interface ;-) Ring handling on a second incoming call should just be a rules issue. Having 2 lines on GSM is common, so the rules need to handle ringing in the current audio context anyway if there is an active call. If it doesn't, or if it checks GSM rather than Phone for active calls, then we have a bug. Contention for audio has worried me for a while. I think we need something like the Resource interface so apps can request it before changing scenarios, but with priority levels so that 'important' apps still get to stomp on lesser ones. Even that seems a little course, but I haven't thought of anything better. ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO and VoIP
2009/4/23 Al Johnson : [...] > It was suggested fairly early on that the org.freesmartphone.Phone and > org.freesmartphone.Phone.Call interfaces would be able to handle other > backends as well as GSM. I've been looking at adding a SIP backend using > liblinphone, but lack of skill is holding me back. Mapping the dbus methods > and signals to the SIP ones from liblinphone looks like it would be easy if I > knew my way around C, or interfacing C with Python. From what I remember of > call handling in asterisk the mapping there shouldn't be too hard either. I was thinking about a way to have support for different sip/voip backends and other nice things in FSO trying to minimize the impact on the framework. A nice way may be to register a dbus "agent" announcing it's capabilities (like bluetooth). FSO may interact without needing to implement code or link external libraries, but only implement a standardized dbus interface. The same may be done for message backend, to have an unified message management system integrated with mail, chat, obex transfer and so on. > I would like to see a single dialer that handles both GSM and VoIP (and any > other) calls. If the dialer already uses the above interfaces then it > shouldn't need too much modification to support the extra protocols. Then > again I've not tried using this interface ;-) I think almost no one did it :) what's about its status? > Ring handling on a second incoming call should just be a rules issue. Having 2 > lines on GSM is common, so the rules need to handle ringing in the current > audio context anyway if there is an active call. If it doesn't, or if it > checks GSM rather than Phone for active calls, then we have a bug. Yes, I do not know deeply the audio routing, but if is it possible to send both gsm voice and pcm output it's simple and right to produce a small beep and may be a vibration to advise user of an other incoming call.Of course we need support for holding and conferencing (this may be a little hard!). > Contention for audio has worried me for a while. I think we need something > like the Resource interface so apps can request it before changing scenarios, > but with priority levels so that 'important' apps still get to stomp on lesser > ones. Even that seems a little course, but I haven't thought of anything > better. Exactly, it was another thought trekking in my brain, for example an audio recorder for interview, register teachers lessons etc, may "occupy" the audio resource with high priority as you do not want an incoming call breaks them, while an ogg player will use a lower priority and so on. In the meaning, suggestions for now? writing a new dialer may be nice but it needs some time, I have some frozen code waiting for opimd and I may resume it if no other solution is available before of a couple of months... FSO is really a great work, as you see everything depends on it, it was a pity funding was suspended, I hope you'll find a new sponsor soon! Regards Nicola ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
[debian] New TangoGPS package requires 14MB library?
When I try to install the new `tangogps' package with `apt-get', it tells me that it needs to also install libicu40, which happens to eat up 14MB of disk space. I know that the 210kB of the previous `tangogps' executable get linked to 16MB's worth of libraries (cairo, sqlite, k5crypto, younameit), but 14MB more almost doubles the footprint. Stefan PS: I'm getting to the point where I might use up less disk space by installing gcc and recompiling tangogps myself with different options (even though gcc+make already take up a good chunk of space). ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [debian] New TangoGPS package requires 14MB library?
PS: I'm getting to the point where I might use up less disk space by installing gcc and recompiling tangogps myself with different options (even though gcc+make already take up a good chunk of space). well, if you figure out, what options are sensible, just tell -- i think i have a working cross building environment for deb packages on my laptop. ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: [debian] python2.5 depends on libsqlite3-0 (New TangoGPS package requires 14MB library?)
Stefan Monnier writes: > When I try to install the new `tangogps' package with `apt-get', it > tells me that it needs to also install libicu40, which happens to eat up > 14MB of disk space. I know that the 210kB of the previous `tangogps' > executable get linked to 16MB's worth of libraries (cairo, sqlite, > k5crypto, younameit), but 14MB more almost doubles the footprint. I don't think this problem has anything to do with tangogps. With apt-cache dotty libicu40 python | dot -Tpng | xli /dev/stdin you can see that python2.5 depends on libsqlite3-0 which depends on libicu40 -- are you perhaps using some python program? ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
