Re: Make bluetoothd start w/o SDP Server

[Iain Hibbert <plunky@rya-online.net>]

On Thu, 12 Nov 2009, Susanne Goldammer wrote:

> I would like to explain in more detail why I use this option to start
> bluetoothd without its own SDP-Server.
>
> The goal is to test the SDP implementation of bluetooth-capable Daimler
> headunits. For this i need my own SDP-Server implementation running,
> cause this SDP Server answers with predefined and invalid SDP Responses
> to special Requests from headunit.

I guess that a "Daimler headunit" is something to do with the Daimler car,
is that some kind of builtin radio with integrated handsfree capability?

I would be interested to find out why you need to use proprietary SDP
requests?  They would only be accessible from a proprietary device and as
there are no vendor-specific PDU IDs defined in the SDP specification
there is a chance of conflict with future extensions. (I admit its
unlikely, but the ID is only 8-bit).

The Bluetooth specifications allow numerous ways to provide proprietary
services, and IMO the proper way to advertise such is to create your own
UUID describing the service class, your own UUID describing the protocol
(if any), search for that in the standard way and connect to the service
in the same way as you would any other. The attribute values are defined
by the service class so you can provide as much information as you want in
this way, no secret handshakes required at all.

regards,
iain

(please note, I don't even run BlueZ/Linux and thus can't object to this
specific implementation in any meaningful way. I'm just interested :)