SCO / eSCO

[Maksim Yevmenkin]

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