Profiles and Service publicing
Hi,
This post is about a specific headset, about btsco and about SDP support in BlueZ. I'm not sure if btsco is being talked here, but anyway I think
this post also concerns BlueZ
This is the context:
· BlueZ and btsco installed and working.
· btsco works fine with the headset (Bluetrek G2).
· once SCO connected, pushing the TALK button on the headset leads to a SCO disconnect state, but pushing TALK again will reconnect without problems.
But:
· When the headset is switched OFF, the SCO channel is abrubtly disconnected and the btsco daemon goes on running.
· When I switch ON the headset again (not in the pairing mode, only switch on) it won't connect to the Audio GAteway again.
· Pushing now the TALK button breafly it enters in which I have named "dumb mode" (because it is unfructuous). I have dumped what is going on in the dumb mode, which I will interpret for you:
The following SDP transaction is repeating again and again until the headset gets tired:
Quoted 1 line
ACL data: handle
0x0029flags0x02dlen 19
L2CAP(d): cid 0x0040 len 15 [psm 1]
SDP SS Req: tid 0x49 len 0xa
pat uuid-32 0x1112 (AG)
max 0x28
cont 00
< ACL data: handle 0x0029 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 1]
SDP SS Rsp: tid 0x49 len 0x5
tot 0x0 cur 0x0
cont 00The first is a SDP_ServiceSearch Request from the headset looking for a service with UUID of value 0x1112 (corresponds to AudioGateway).
The second is a SDP_ServiceSearch Response from BlueZ saying that the requested service is not found in the SDP database nor nothing even similar, which is really true because I have not add this service ("sdptool add AG" is not supported)
Now:
Now is when some leak of knowledge hammers mi soul:
· In the assumption that, some way, I could create a service record in the service database specifying AudioGateway UUID, would it be enough for the heaset to reconnect again?
· I think of btsco as if it was an AudioGateway implementation (or headset profile implementation) using the BLuez stack, but if it doesn't register by its own the AG service in the local database, maybe it is not a profile imlpementation?
So:
Please, could you give me some points to understand this? Also, if it's not being possible to fix the reconnection problem because of some lack of development, I would like to know where is the failure.
Thank you very much
Luis
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi
Quoted 2 lines
The first is a
SDP_ServiceSearchRequest from the headset looking for a service with UUID of value0x1112(corresponds to AudioGateway).
The second is aSDP_ServiceSearchResponse from BlueZ saying that the requested service is not found in the SDP database nor nothing even similar, which is really true because I have not add this service ("sdptool add AG" is not supported)
We need sdptool to support ag for one thing. I hadn't realized it wasn't supported (I have always been initiating computer->headset but we want to support headset->computer)
If you are comfortable with it, get the sdptool from cvs (to make sure it hasn't been added recently) and add ag support. It's likely a table somewhere with the uuid value and "ag" string. Submit patches here.
Quoted 1 line
· In the assumption that, some way, I could create a service record in the service database specifying AudioGateway UUID, would it be enough for the heaset to reconnect again?
There are more details to take care of probably, but we need to try it to find out.
Quoted 1 line
· I think of btsco as if it was an AudioGateway implementation (or headset profile implementation) using the BLuez stack, but if it doesn't register by its own the AG service in the local database, maybe it is not a profile imlpementation?
We are trying to implement the profile completely. The profile is not finished if it doesn't advertise the service.
Quoted 3 lines
So:
Please, could you give me some points to understand this? Also, if it's not being possible to fix the reconnection problem because of some lack of development, I would like to know where is the failure.
Yes, it is a shortcoming of the current system. We want to fix it but we need more good developers trying stuff like you are and fixing stuff.
Brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann
maintainerHi,
Quoted 15 lines
The following SDP transaction is repeating again and again until the headset gets tired:
Quoted 1 line
ACL data: handle
0x0029flags0x02dlen 19L2CAP(d): cid 0x0040 len 15 [psm 1] SDP SS Req: tid 0x49 len 0xa pat uuid-32 0x1112 (AG) max 0x28 cont 00 < ACL data: handle 0x0029 flags 0x02 dlen 14 L2CAP(d): cid 0x0040 len 10 [psm 1] SDP SS Rsp: tid 0x49 len 0x5 tot 0x0 cur 0x0 cont 00
Quoted 6 lines
The first is a
SDP_ServiceSearchRequest from the headset looking for a service with UUID of value0x1112(corresponds to AudioGateway). The second is aSDP_ServiceSearchResponse from BlueZ saying that the requested service is not found in the SDP database nor nothing even similar, which is really true because I have not add this service ("sdptool add AG" is not supported)
if the headset ends up in a loop like this, then the implementation of the headset profile inside the headset has a bug. It is that simple, because they should be able to handle a non existing audio gateway record nicely.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi,
Quoted 8 lines
if the headset ends up in a loop like this, then the implementation of the headset profile inside the headset has a bug. It is that simple, because they should be able to handle a non existing audio gateway record nicely.
Regards
Marcel
Indeed it hangs in the loop and nothing else can be done with it until it is powered off.
I have add a "false" AudioGAteway service to my local SDP database so when the headset looks for it, she find it. At least now there is no loop but, as expected, the headset doesn't work nicely: it won't close an ACL connection to the gateway by its own so, in order to connect with btsco I should disconnect this ACL myself (hcitool dc bdaddr_)
How did I add AudioGateway service?
The ugliest way:
·copy add_headset(...) function in sdptool.c
·paste the code and rename to add_headset_ag(...)
·with the changes:
" si->channel: 5;" to " si->channel: 1;"HEADSET_SVCLASS_ID to HEADSET_AGW_SVCLASS_IDHEADSET_PROFILE_ID to HEADSET_AGW_PROFILE_ID
·also adding the line:
{ "HSAG", HEADSET_AGW_SVCLASS_ID, add_hs_audio_gw },
in the service[] structure
Certainly I don't understand roughly what I'm doing...
Regards,
Luis
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users