2009/4/23 Al Johnson <alast...@truebox.co.uk>:
[...]
> 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
