From owner-freebsd-bluetooth@FreeBSD.ORG Thu Jul 28 18:06:30 2005 Return-Path: X-Original-To: freebsd-bluetooth@freebsd.org Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E976A16A41F for ; Thu, 28 Jul 2005 18:06:29 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FF5C43D45 for ; Thu, 28 Jul 2005 18:06:29 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id BD2413C07F; Thu, 28 Jul 2005 13:06:28 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29641-01-97; Thu, 28 Jul 2005 13:06:28 -0500 (CDT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (Postfix) with ESMTP id 88ED33BEF4; Thu, 28 Jul 2005 13:06:28 -0500 (CDT) Received: from s228130hz1ew171.apptix-01.savvis.net ([10.146.4.29]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 13:06:26 -0500 Received: from [10.254.186.111] ([64.14.1.106]) by s228130hz1ew171.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 13:06:13 -0500 Message-ID: <42E91E90.4010703@savvis.net> Date: Thu, 28 Jul 2005 11:06:08 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Oliver References: <20050728113713.2925.5@@vodafone.es> <42E90D5E.3030404@savvis.net> <20050728193504.14880.1@@vodafone.es> In-Reply-To: <20050728193504.14880.1@@vodafone.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2005 18:06:13.0681 (UTC) FILETIME=[0A990210:01C5939F] X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-bluetooth@freebsd.org Subject: Re: SCO / eSCO X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2005 18:06:30 -0000 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