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

[Radha Thiagarajan <rthiaga1@urbana.css.mot.com>]

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
>
>  
>