[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bluetooth-dev] Question on SDP_SERVICEATTR_RSP
You got a ServiceAttributeRsp, and a it consists of a AttributeListByteCount and a AttributeList field, followed by the Continuation state field. As stated in the spec, the AttributeList is:
"a data element sequence containing attribute IDs
and attribute values. The first element in the sequence contains the
attribute ID of the first attribute to be returned. The second element in
the sequence contains the corresponding attribute value."
And in your case the first element is the 0x090100 which is the AttributeID for ServiceName, and the second element is the ServiceName in ascii code.
>From: Marcus Smith [mailto:email@example.com]
>Sent: Thursday, February 08, 2001 1:04 AM
>Subject: [bluetooth-dev] Question on SDP_SERVICEATTR_RSP
>I've initiated a SDP_SERVICEATTR_REQ with a handle that I received
>from a prior SDP_SERVICESEARCH_REQ. I receive the following data
>sequence back from the SDP server:
>0x5, 0x28, 0x5e, 0x0, 0x1e, 0x0, 0x1b,
>0x35, 0x19, 0x9, 0x1, 0x0, 0x25, 0x14,
>0x4c, 0x41, 0x4e, 0x20, 0x41, 0x63, 0x63,
>0x65, 0x73, 0x73, 0x20, 0x75, 0x73, 0x69,
>0x6e, 0x67, 0x20, 0x50, 0x50, 0x50, 0x0
>Now, I understand everything up to the DES and length (which
>is 0x35 and
>0x19). After looking at
>sdp.xml, I realized that "0x9, 0x1, 0x0" was Parameter0
>I was actually asking for ServiceName for LANAccessOverPPP.
>Isn't this missing a data element type descriptor?
>I was under the impression after reading the bluetooth spec that
>everything in a
>DES has a type descriptor followed by data, thereby making it rather
>easy to build
>an algorithm to parse a DES.
>To unsubscribe from this list: send the line "unsubscribe
>the body of a message to firstname.lastname@example.org
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to email@example.com