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
Re: FSO and VoIP
Nicola Mfb writes: > a dialer that interacts both with FSO and the VoIP stack. We should use freeswitch as the central daemon for voice and video sessions. This should talk to the GSM daemon. A dialer should just be a simple SIP client. This means we can use any SIP client out there to make the call and it won't matter how this call is setup in freeswitch. We can also bridge them, to have a conference with people on VoIP and GSM. This all happens in freeswitch. The contact application should not be an integral part of the dialer, either. It simple launches your preferred dialing application with the number. Routing calls any way you like, even over your network, now becomes a breeze. -- Esben Stien is b...@e s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO and VoIP
Esben Stien writes: > a simple SIP client. This means we can use any SIP client out there to > make the call and it won't matter how this call is setup in But when you use GSM then the audio data is transmitted from GSM to speakers in analog form. It does not go through the CPU so your SIP client can not receive it, right? ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO and VoIP
Timo Juhani Lindfors writes: > But when you use GSM then the audio data is transmitted from GSM to > speakers in analog form. It does not go through the CPU so your SIP > client can not receive it, right? Well, this is the wrong route, if the audio goes from the audio GSM chip to the audio chip. Other than prevent post processing of the audio, it hinders flexible audio routing. This is not hard wired, so we can avoid sending it directly to the audio chip. The audio should go into freeswitch, which allows us very good management of the audio and video streams. -- Esben Stien is b...@e s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO and VoIP
Esben Stien writes: > The audio should go into freeswitch, which allows us very good > management of the audio and video streams. But that'd also add latency and make it possible for the audio to lag if freerunner does not have enough cpu power to process the audio? At least linphone-3's echo cancellation feature eats too much cpu power and I have to keep it disabled. ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO and VoIP
On Sunday 26 April 2009, Esben Stien wrote: > Nicola Mfb writes: > > a dialer that interacts both with FSO and the VoIP stack. > > We should use freeswitch as the central daemon for voice and video > sessions. This should talk to the GSM daemon. A dialer should just be > a simple SIP client. This means we can use any SIP client out there to > make the call and it won't matter how this call is setup in > freeswitch. Except that because of the audio routing required it won't be that easy. You will have to use the one channel (say left) for connecting PCM to the GSM, and the other for PCM to the mic/earpiece. I doubt generic SIP clients and freeswitch, or asterisk's chan_alsa, will play nicely under those conditions. ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO and VoIP
Timo Juhani Lindfors writes: > that'd also add latency and make it possible for the audio to lag if > freerunner does not have enough cpu power to process the audio? The process doing audio must run with posix 1.e realtime priority. No other process in the system will be able to preempt this process. > At least linphone-3's echo cancellation feature eats too much cpu > power and I have to keep it disabled. Maybe it's a poor implementation, then?. -- Esben Stien is b...@e s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO and VoIP
Al Johnson writes: > You will have to use the one channel (say left) for connecting PCM > to the GSM Not sure what you mean here. You mean connect the PCM (audio chip) to the GSM (gsm chip)?. We shouldn't do that. We connect the GSM to a software PBX. We either write a module to talk to the GSM chip, which speaks SIP, or we integrate the gsm modem code into a software switch, such as freeswitch. -- Esben Stien is b...@e s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO and VoIP
Esben Stien writes: > Not sure what you mean here. You mean connect the PCM (audio chip) > to the GSM (gsm chip)?. We shouldn't do that. We connect the GSM to > a software PBX. Ok. I get what you mean. As of now, the GSM chip is connected to the Wolfson CODEC, which has instructions to just route the audio directly to the speakers. We should definitely use JACK here. No application should really use ALSA directly. With JACK, routing the channels to arbitrary modules is easy. http://jackaudio.org -- Esben Stien is b...@e s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
Re: FSO and VoIP
On Sunday 26 April 2009, Esben Stien wrote: > Al Johnson writes: > > You will have to use the one channel (say left) for connecting PCM > > to the GSM > > Not sure what you mean here. You mean connect the PCM (audio chip) to > the GSM (gsm chip)?. We shouldn't do that. We connect the GSM to a > software PBX. How? AFAIK there is no way to send audio data through the serial port, so we have to go through analogue on the audio chip. ___ Smartphones-userland mailing list Smartphones-userland@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-userland
