Re: choosing a RFCOMMChannel channelID ?
Re: choosing a RFCOMMChannel channelID ?
- Subject: Re: choosing a RFCOMMChannel channelID ?
- From: Eric Brown <email@hidden>
- Date: Thu, 24 Jun 2004 10:40:36 -0700
On Jun 24, 2004, at 6:46 AM, Yann Bizeul wrote:
>
>> I use kBluetoothSDPUUID16ServiceClassDialupNetworking because I see
>
>> AddressBook use this channel (for the phones I tested). Since this is
>
>> the same channel as AB, I gracefully free the connection when AB is
>
>> launched, and re-establish it when it is quit.
>
>
>
> how did you find this is the SDPUUID service used by AB ?
>
Because there *seem* to be standards saying channel ID 1 is
>
kBluetoothSDPUUID16ServiceClassDialupNetworking. And with
>
BluetoothMonitor, it seem AB always connect to channel ID 1 :-/ I
>
guess.... As you said, Apple lacks documentations and guidelines about
>
this.
>
Actually, there are no standards tying RFCOMM channel ID to service
type. The Bluetooth spec defines many different profiles for various
purposes - i.e. Serial Port Profile for direct serial access, Dial Up
Networking for modem access, Object Push for sending files, etc...
Each profile typically defines a service that gets published and a
service class that identifies it. The RFCOMM channel ID for a specific
service is dynamically assigned by the device and stored within its
service record. A single device may define several services each with
a unique RFCOMM channel ID. In order to find the RFCOMM channel ID to
use, you must perform an SDP query to fetch the services and then look
up the desired service using an appropriate UUID. In many cases the
service class UUID is the right one to use.
In the situation discussed earlier, the dial up networking service
class is the correct one to be using since it will allow you to
communicate with the built-in modem. The code sample shown earlier for
BuddyPop is basically correct. I do have a couple of suggestions for
changes to it however. It would probably be useful to call [device
peformSDPQuery:] before calling -getServiceRecordForUUID: to make sure
that the system has an up to date cache of the device's services.
There is nothing preventing a device from dynamically re-assigning the
services (although I don't think any existing devices do). Also, I
would highly recommend checking the return code from
-getRFCOMMChannelID: to protect against devices that might not have a
complete service record.
- Eric
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
bluetooth-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/bluetooth-dev
Do not post admin requests to the list. They will be ignored.