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

Radha Thiagarajan
2004-08-05T15:33:02Z

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