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

Reply via email to