Date: Thu, 28 Jul 2005 11:06:08 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Oliver <urnenfel@tiscali.es> Cc: freebsd-bluetooth@freebsd.org Subject: Re: SCO / eSCO Message-ID: <42E91E90.4010703@savvis.net> In-Reply-To: <20050728193504.14880.1@@vodafone.es> References: <20050728113713.2925.5@@vodafone.es> <42E90D5E.3030404@savvis.net> <20050728193504.14880.1@@vodafone.es>
next in thread | previous in thread | raw e-mail | index | archive | help
Oliver,
>>i have some code already sitting in my local cvs. i will clean it up and
>>commit it soon (within a month or so).
>
> Sorry, now i remember, this question was already commented in the list
ok
>>what are you planning to do with SCO?
>
> Actually at the moment, I just wanted to understand the Stack, as it is the
> first FreeBSD code i am looking at. Concretely know how HCI looks at, and
> talks with the upper layers (L2CAP & SCO).
SCO is *not* upper layer protocol. the picture goes something like this:
| OBEX | IrMC | etc|
---------------------------------
| SDP | RFCOMM | etc. |
---------------------------------
| L2CAP |
--------------------------------------------
| HCI |
--------------------------------------------
| Link Manager (device firmware) |
--------------------------------------------
| SCO link | ACL link |
--------------------------------------------
| baseband radio |
--------------------------------------------
so both ACL (data) and SCO (voice/video) links are at the same level.
ACL (data) link is used for *reliable* data transfer. it supports packet
segmentation etc. SCO link is unreliable, no packet segmentation, etc.
think of it as two pipes over the same radio link.
L2CAP is a upper layer protocol that supports multiple logical channels,
reliable data transfer, packet segmentation etc. it runs over ACL link
because it assumes that underlaying data link is *reliable*.
the protocols that run over L2CAP, i.e SDP, RFCOMM, etc. essentially use
different logical L2CAP channels (similar to well known ports in UDP/TCP
protocols).
so, SCO is really a side channel for *unreliable* data transfer. it is
well suited for streaming audio/video where it does not matter if you
loose one or few packets. L2CAP does not run over SCO. in fact, i do not
think any upper layer protocol uses SCO as transport layer. for example
headset profile: there are two channels: one is RFCOMM connection, i.e.
reliable control channel, and other is SCO link to send/receive voice.
>>SCO (just like ACL) is just a link type. its not really a protocol. HCI
>>- Host Controller Interface - is just a way to access bluetooth device,
>>you might call it a protocol. there is set of HCI commands that will
>>make device create a ACL and SCO link using the same baseband radio
>>link. eSCO is a bluetooth v1.2 thing and i have not looked at bluetooth
>>v1.2 yet.
>
> So this confirms me that L2CAP absotulelly doesnt make any handling in the
> SCO data, am i wrong?
you are correct. L2CAP does not have anything to do with SCO.
> But as I understood in your explanation there will not be a ""paralel
> layer"" to the L2CAP (being HCI below them) am i wrong again? just the
> socket interface and support in the driver...
ACL and SCO links are parallel. HCI is on top of them. L2CAP asks HCI to
create a ACL (data) link and then uses it as transport.
>>you are the second person on the list who wanted to start working on the
>>SCO support. if you are serious about this i will commit my code to
>>-current, but then someone has to help me with maintaining it (i.e.
>>fixing bugs, adding features etc.), because i'm not comfortable with
>>committing untested code. if you are not prepared to actively work on
>>the code then please wait until i have chance to finish it.
>
> Sure, no hurries at all for commiting, as I told I was just trying to
> understand.
ok
thanks,
max
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42E91E90.4010703>