[Bluez-devel] multi rfcomm/sco connection

[Bluez-devel] multi rfcomm/sco connection

[ubaldo]

Buondi', 

I would like to understand why it is not possible to establish more than one 
sco connection and more than an rfcomm connection with and usb-dongle. 




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] multi rfcomm/sco connection

[Marcel Holtmann]

Hi,

> I would like to understand why it is not possible to establish more than one 
> sco connection and more than an rfcomm connection with and usb-dongle. 

it is possible to establish up to 30 RFCOMM connections into each
direction. The number of SCO connections is limited to one per ACL link.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: multi rfcomm/sco connection

[ubaldo]

>> I would like to understand why it is not possible to establish more than one 
>> sco connection and more than an rfcomm connection with and usb-dongle. 
> 
> it is possible to establish up to 30 RFCOMM connections into each
> direction. The number of SCO connections is limited to one per ACL link.

Does it mean that for each SCO connection I need another bt-dongle, or there 
is a way to allow multi SCO connection with the same bt-dongle?

[Bluez-devel] Re: multi rfcomm/sco connection

[Marcel Holtmann]

Hi,

> > it is possible to establish up to 30 RFCOMM connections into each
> > direction. The number of SCO connections is limited to one per ACL link.
> 
> Does it mean that for each SCO connection I need another bt-dongle, or there 
> is a way to allow multi SCO connection with the same bt-dongle?

I said per ACL link. The Bluetooth specification defines that between
two devices one ACL and up to three SCO links can exists. The max number
of SCO links per piconet is also three. In BlueZ we currently allow one
ACL and one SCO link between two devices. This limitation is some kind
of historic. Feel free to fix it.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: multi rfcomm/sco connection

[ubaldo]

Thanx Marcel for your unlimited patience! :) 


>> > it is possible to establish up to 30 RFCOMM connections into each
>> > direction. The number of SCO connections is limited to one per ACL link. 
>> 
>> Does it mean that for each SCO connection I need another bt-dongle, or there 
>> is a way to allow multi SCO connection with the same bt-dongle?
> 
> I said per ACL link. The Bluetooth specification defines that between
> two devices one ACL and up to three SCO links can exists. The max number
> of SCO links per piconet is also three. In BlueZ we currently allow one
> ACL and one SCO link between two devices. This limitation is some kind
> of historic. Feel free to fix it.

Any tip for where to put the eyes on for fixing? 

[Bluez-devel] Re: multi rfcomm/sco connection

[Marcel Holtmann]

Hi,

> > I said per ACL link. The Bluetooth specification defines that between
> > two devices one ACL and up to three SCO links can exists. The max number
> > of SCO links per piconet is also three. In BlueZ we currently allow one
> > ACL and one SCO link between two devices. This limitation is some kind
> > of historic. Feel free to fix it.
> 
> Any tip for where to put the eyes on for fixing? 

actually I don't see why you need more than one SCO link in a connection
between two devices. However take a look at the kernel source code of
Linux 2.6.x and especially at net/bluetooth/hci_conn.c
Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: multi rfcomm/sco connection

[ubaldo]

Ciao Marcel, 

> actually I don't see why you need more than one SCO link in a connection
> between two devices. However take a look at the kernel source code of
> Linux 2.6.x and especially at net/bluetooth/hci_conn.c

I explain you a bit more my situation... 

I need to be able with a single usb-bt-dongle to play/capture audio for 
several bt-handsfree, I tried with one and there are no problems, but if I 
try to connect another one then I get something like "sco channel busy". 

I studied the net/bluetooth directory but I cannot find any good way to 
achieve what I need! :) 

Am I wrong in something or is this feature really missing?

[Bluez-devel] Re: multi rfcomm/sco connection

[Marcel Holtmann]

Hi,

> > actually I don't see why you need more than one SCO link in a connection
> > between two devices. However take a look at the kernel source code of
> > Linux 2.6.x and especially at net/bluetooth/hci_conn.c
> 
> I explain you a bit more my situation... 
> 
> I need to be able with a single usb-bt-dongle to play/capture audio for 
> several bt-handsfree, I tried with one and there are no problems, but if I 
> try to connect another one then I get something like "sco channel busy". 
> 
> I studied the net/bluetooth directory but I cannot find any good way to 
> achieve what I need! :) 
> 
> Am I wrong in something or is this feature really missing?

as I said, between two devices BlueZ supports only one ACL link and one
SCO link. These links a bi-directional so you can play and capture audio
data at the same time. The limit to one SCO link is only a per ACL link
limitation. If you open a second ACL to another device you can also have
a second SCO link bound to that connection.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: multi rfcomm/sco connection

[Radha Thiagarajan]

Marcel,

We need clarification from you about two things regarding SCO.

1) We noticed that the SCO module has different behavior when dealing 
with BDADDR_ANY as opposed to a specific bluetooth address. If a device 
is told to listen for a SCO connection with BDADDR_ANY, and then creates 
an outgoing SCO connection to a device using BDADDR_ANY, the connection 
succeeds. Later, if an incoming SCO connection is received, the listen 
socket will accept the connection (thus producing two SCO connections 
over 2 ACL connections to 2 different devices).

This is all fine, but if instead, we bind the listen socket with a 
specific device address (instead of BDADDR_ANY) and then try to make the 
outgoing SCO connection using the specific address, it will fail 
claiming that the address is already in use. This looks like 
inconsistent behavior, given that even if we specify BDADDR_ANY and we 
only have one interface, both connections will be using the same interface.

So, in short, if BlueZ is asked to use a specific interface for both 
incoming and outgoing SCO connections, it will refuse to carry out the 
bind calls, but if BDADDR_ANY is used, it will allow both connections. 
Therefore, it appears to be a bug - either BlueZ really can't handle 
more than one SCO at a time and it is being tricked into doing it, or it 
should allow the user to specify the address and not complain.


2) Consider two devices A and B. A uses BlueZ while B does not. Let us 
also assume that B can handle more than one SCO per ACL connection.  Let 
us say that there is a SCO connection between A and B already. Then B 
initiates a second SCO connection on the same ACL to A. Looking at the 
source for this situation, it appears that  the device A will overwrite 
the SCO socket values with the new one that was just established (since 
it allows only one SCO per ACL). Is this the intended behavior?

Thanks,
Radha


On 07/16/2004 10:29 AM, Marcel Holtmann wrote:

>as I said, between two devices BlueZ supports only one ACL link and one
>SCO link. These links a bi-directional so you can play and capture audio
>data at the same time. The limit to one SCO link is only a per ACL link
>limitation. If you open a second ACL to another device you can also have
>a second SCO link bound to that connection.
>
>Regards
>
>Marcel
>
>  
>

Re: [Bluez-devel] Re: multi rfcomm/sco connection

[Marcel Holtmann]

Hi Radha,

> 1) We noticed that the SCO module has different behavior when dealing 
> with BDADDR_ANY as opposed to a specific bluetooth address. If a device 
> is told to listen for a SCO connection with BDADDR_ANY, and then creates 
> an outgoing SCO connection to a device using BDADDR_ANY, the connection 
> succeeds. Later, if an incoming SCO connection is received, the listen 
> socket will accept the connection (thus producing two SCO connections 
> over 2 ACL connections to 2 different devices).
> 
> This is all fine, but if instead, we bind the listen socket with a 
> specific device address (instead of BDADDR_ANY) and then try to make the 
> outgoing SCO connection using the specific address, it will fail 
> claiming that the address is already in use. This looks like 
> inconsistent behavior, given that even if we specify BDADDR_ANY and we 
> only have one interface, both connections will be using the same interface.
> 
> So, in short, if BlueZ is asked to use a specific interface for both 
> incoming and outgoing SCO connections, it will refuse to carry out the 
> bind calls, but if BDADDR_ANY is used, it will allow both connections. 
> Therefore, it appears to be a bug - either BlueZ really can't handle 
> more than one SCO at a time and it is being tricked into doing it, or it 
> should allow the user to specify the address and not complain.

there is a simply answer to that question. It is a bug :(

> 2) Consider two devices A and B. A uses BlueZ while B does not. Let us 
> also assume that B can handle more than one SCO per ACL connection.  Let 
> us say that there is a SCO connection between A and B already. Then B 
> initiates a second SCO connection on the same ACL to A. Looking at the 
> source for this situation, it appears that  the device A will overwrite 
> the SCO socket values with the new one that was just established (since 
> it allows only one SCO per ACL). Is this the intended behavior?

I read the source that the new SCO connection will be overwritten with
the value of the first one. However this still doesn't looks very nice
in any case.

Are you planning to use SCO over HCI or PCM?

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Re: multi rfcomm/sco connection

[Radha Thiagarajan]

Hi Marcel,

Thanks for the reply. We will be using SCO over PCM.
Are you planning on a fix for both the problems?

Thanks,
Radha.


On 08/04/2004 06:35 PM, Marcel Holtmann wrote:

>Hi Radha,
>
>> 1) We noticed that the SCO module has different behavior when dealing 
>> with BDADDR_ANY as opposed to a specific bluetooth address. If a device 
>> is told to listen for a SCO connection with BDADDR_ANY, and then creates 
>> an outgoing SCO connection to a device using BDADDR_ANY, the connection 
>> succeeds. Later, if an incoming SCO connection is received, the listen 
>> socket will accept the connection (thus producing two SCO connections 
>> over 2 ACL connections to 2 different devices).
>> 
>> This is all fine, but if instead, we bind the listen socket with a 
>> specific device address (instead of BDADDR_ANY) and then try to make the 
>> outgoing SCO connection using the specific address, it will fail 
>> claiming that the address is already in use. This looks like 
>> inconsistent behavior, given that even if we specify BDADDR_ANY and we 
>> only have one interface, both connections will be using the same interface.
>> 
>> So, in short, if BlueZ is asked to use a specific interface for both 
>> incoming and outgoing SCO connections, it will refuse to carry out the 
>> bind calls, but if BDADDR_ANY is used, it will allow both connections. 
>> Therefore, it appears to be a bug - either BlueZ really can't handle 
>> more than one SCO at a time and it is being tricked into doing it, or it 
>> should allow the user to specify the address and not complain.
>
>there is a simply answer to that question. It is a bug :(
>
>> 2) Consider two devices A and B. A uses BlueZ while B does not. Let us 
>> also assume that B can handle more than one SCO per ACL connection.  Let 
>> us say that there is a SCO connection between A and B already. Then B 
>> initiates a second SCO connection on the same ACL to A. Looking at the 
>> source for this situation, it appears that  the device A will overwrite 
>> the SCO socket values with the new one that was just established (since 
>> it allows only one SCO per ACL). Is this the intended behavior?
>
>I read the source that the new SCO connection will be overwritten with
>the value of the first one. However this still doesn't looks very nice
>in any case.
>
>Are you planning to use SCO over HCI or PCM?
>
>Regards
>
>Marcel
>
>  
>

Re: [Bluez-devel] Re: multi rfcomm/sco connection

[Marcel Holtmann]

Hi Radha,

> Thanks for the reply. We will be using SCO over PCM.
> Are you planning on a fix for both the problems?

the point is if you use SCO over PCM then the SCO socket interface is
really useless. My idea is to add an ioctl to the L2CAP and RFCOMM
sockets for adding and releasing a SCO link. Actually I realized that I
never thought about incoming SCO connections for that case. Are there
any proposals for getting a nice SCO over PCM support?

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel