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 :) -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
