RFComm behaviour with nokia mobiles

[Guido Falsi]

Iain Hibbert wrote:
> On Fri, 7 Nov 2008, Guido Falsi wrote:
> 
>> Iain Hibbert wrote:
>>> The attribute ID list should be in ascending order according to
>>> the specification. This means though that some logic could be
>>> wrong because the protocol descriptor list for any given service
>>> class would likely appear before the service name in the response
>>> attribute list and you would use the wrong channel..
>> Uhm, I did not get this detail in the specification.
> 
> You can find this in the small print of the SDP spec sections
> relating to ServiceSearch and ServiceSearchAttribute requests, in the
> AttributeIDList box.
> 
> I guess its so that a server can do a straight pass through search
> without having to loop up and down the list, but I don't know if that
> would work out simpler or not in practice. Obviously the Nokia people
> thought not, as it worked anyway :)
> 

After some reading, some coding and some experimenting I think I found
what is happening.

I have this code(I hope mozilla will not mangle this too much):

uint32_t attrs[] =
{
SDP_ATTR_RANGE(
SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET,
SDP_ATTR_PRIMARY_LANGUAGE_BASE_ID+SDP_ATTR_SERVICE_NAME_OFFSET),
SDP_ATTR_RANGE(
SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST,
SDP_ATTR_PROTOCOL_DESCRIPTOR_LIST),
};

so I define 2 ranges with a single attribute in each. This one defines 
the order in which objects are returned.

Since I think code written the way you suggested is cleaner and more 
readable I'll just swap the two ranges and have it work the way you said.

I think FreeBSD's sdp is making 2 requests in this case...Or maybe 
forcing the order to be the same as the request.

-- 
Guido Falsi <mad at madpilot.net>