ok I think I found the problem. I had paired up with my wife's phone a while back, and I think I only had the hfag service registered at that time. After I re-paired, they both work with the hf service. So it looks like the phone saves the channel associations at pairing time. So I guess I only need to listen on one channel.
Quick reply, i'll post more in the morning.
An issue I had with my phone (Samsung) is that I could connect to my app from the phone itself, but the phone strangely enough would not let my app dial out. If my app conected to the phone than everything was fine. I never really chased it down as the expected behavior was for my app to connect. I was just connecting with the phone for testing.
Here's some good news...
First, I found THE Handsfree spec. This describes in great detail how everything works. And, yes, we get access to the phonebook, as well as in-band ringtones :)
Second, I made some progress on the re-written app this weekend. It's still in it's infancy, but it can accept as well as initiate connections to a phone (but doesn't do anything with that connection yet). Hopefully within the next few days I'll get the OK to release the utility classes I'm using, then I'll set up a Sourceforge CVS site.
Edit: The part about access to the phonebook and the in-band ringtones actually came from here: http://msdn2.microsoft.com/en-us/library/aa916242.aspx
I wish that I could help out with this, but I'm still a very newb C++ programmer. Bluetooth is about the last thing to hold me back from making a linux box for the car.
The document I linked earlier was for the V1.0 of the HF spec. Thats for 1.5.
Originally Posted by gentoocar
The SDP records returned by the phone will tell you if your phone supports 1.5 or not.
Service Name: Voice Gateway
Service RecHandle: 0x10003
Service Class ID List:
"Handfree Audio Gateway" (0x111f)
"Generic Audio" (0x1203)
Protocol Descriptor List:
Profile Descriptor List:
Version: 0x0100 <-- Verison 1.0, will be 0x0105 for v1.5
Retrieving the phonebook is not part of the Handsfree Profile. It may still work over the rfcomm link, but we may still have to open a second connection to the serial port for phone book entries.
BTW, AT+BRSF=127 is all my phone needs to feel a HF connection is established, good for just plugging random commands for testing.
Despite bluetooth being a standard, every phone behaves a little differently.
So now a days i still lose my sco audio connection. Gentoocar said it was normal but is there any way to solve it? After reading part of the software i though that "houston we was connected " should appear.
The worst thing is that i make a phone call to my mobile phone a i get a Segmentation Fault and my sound system does not work any more.
About the coding audio after asking to Simon Vogl (author of the handsfree) i definitely agree with you to use S16_LE. I also asked about the pipe to the author and he replied "The missing pipe should raise an error but not cause any other trouble (you can replace it by ctrl=0 to set it to stdin :) it is used for controlling behavior only "
So basically we really do not have to worry about that.
Any suggestion what to do?
I hacked the handsfree.c code a little and stopped the sco audio connection from cutting out -- or sleeping. Unfortunately this caused a kernel oops.
After a reboot and another execution, the application never got to the code section I edited.
I may be wrong here, but it could be the case that different mobiles/cells output different integer codes for what status they are at (I assume this is GSM codes?) For instance, my Motorola Razr gives 6,3 for when the call is trying to connect, so I changed the if(which == 1 && what ==3) to 6 & 3.
After this, every outbound call I made was transmitted to the speakers. Regular Seg. faults occurred, and with me not being much of a C coder, I couldn't pin down exactly what went wrong. I'm guessing too much data is being sent to the buffer/sound card.
I've since realised that everyone on this thread and I have different goals - I was looking for the opposite thing! I wanted to have incoming calls via Skype/X-Ten/etc directed to my phone... i.e Use the actual handset as a headset. From what I've read so far, I don't think this is possible, unless the bluetooth stack on the phone has the headset profile... and I doubt that it does or it can be added easily.
For the guys making a go of this; I'd check out the source for either or both chan_bluetooth and chan_cellphone from the Asterisk. Both of these modules work very nicely. To speed up development, you could fork either if the licence permits.
I'll still check this thread and offer as much help as I can.
Best of luck.
Hmm, looks like my phone uses handsfree version 1.1 (0x0101), and headset version 1.0. And my bluetooth dongle uses handsfree version 1.1 as well.
So I guess I'll use the 1.0 spec. I'm not sure what has changed between the two but I assume 1.5 devices are backwards compatible. So far in my reading everything looks the same.
BTW my dongle is a Zonet, with a Broadcom "BCM92045DG Non-UHE" chipset.
Ah, I tried that with my phone and the BRSF command alone didn't make it "connected", so I plugged in the rest of the commands from the spec ("AT+BRSF=0", "AT+CIND=?", "AT+CIND?", "AT+CMER=3,0,0,1") and that does the trick for me.
Originally Posted by Zimans
Looks like I have some more spec-reading and parser-writing ahead of me, but I feel like I'm making progress :)
It seems that 1.5 adds more status type of information. For example, roaming/not roaming, signal strength, battery level, etc. However, I believe you can get alot of this information through the serial port, or may be able to atleast. There are at commands to retrieve this. 1.5 also provides a mechanism to retrieve current cell carrier.
Originally Posted by gentoocar
1.5 has more options in the CIND response, so make sure you parse it properly (No assumptions :P)
The basic call control seems to be un-changed.