Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 08 Nov 2008 02:03:07 +0100
From:      Guido Falsi <mad@madpilot.net>
To:        Iain Hibbert <plunky@rya-online.net>
Cc:        freebsd-bluetooth@freebsd.org
Subject:   Re: RFComm behaviour with nokia mobiles
Message-ID:  <4914E54B.4060206@madpilot.net>
In-Reply-To: <1226097099.328979.788.nullmailer@galant.ukfsn.org>
References:  <20081104111947.GB62907@megatron.madpilot.net> <1225799105.807983.1164.nullmailer@galant.ukfsn.org> <20081104135107.GA64776@megatron.madpilot.net> <1225821264.107584.759.nullmailer@galant.ukfsn.org> <4910B6E6.7070206@madpilot.net> <4910CA97.6030708@madpilot.net> <1226091521.039371.399.nullmailer@galant.ukfsn.org> <4914B113.60303@madpilot.net> <1226097099.328979.788.nullmailer@galant.ukfsn.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@madpilot.net>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4914E54B.4060206>