Bluetooth Controller: SCO connection fails with 2 existing phones connected (IDFGH-11172)

[mringwal]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.2-dev-3065-g272b4091f1

Espressif SoC revision.

ESP32-D0WD-V3 (revision v3.0)

Operating System used.

macOS

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32_LyraT

Power Supply used.

USB

What is the expected behavior?

After connecting an iPhone Mini 12 with iOS 17 and an Google Pixel 7a, I expect both of them to be able to open an SCO for HFP.

What is the actual behavior?

When iOS initiates the SCO connection for WBS, the connection fails with error 0x1b - SCO Offset Rejected

Steps to reproduce.

• Run the BTstack hfp_hf_demo
• Pair and connect with iPhone
• Pair and connect with Android
• Start Voice Memos on iPhone and press Record

Here are the HCI traces for both ESP32 as well as an USB Bluetooth Dongle. Can be analyzed with Wireshark.

hfp_hf_two_phones.zip

Debug Logs.

Full logs are in the "Steps to reproduce"

Here the snippet for the SCO setup

Jan 01 18:00:47.382  HCI Event        Connection Request - 48:35:2B:90:47:3C  RECV  
	Parameter Length: 10 (0x0A)
	Bluetooth Device Address: 48:35:2B:90:47:3C
	Class Of Device: 0x000000
	Service Class: 0x0000
	Major Class: 0x0000
	    Miscellaneous
	Minor Class: 0x0000
	Link Type: 0x02 -- eSCO Connection
Jan 01 18:00:47.382  HCI Event        00000000: 040A 3C47 902B 3548 0000 0002            ..<G.+5H....  RECV  
Jan 01 18:00:47.387  Note             hci.c.3644: Connection_incoming: 48:35:2B:90:47:3C, type 2  RECV  
Jan 01 18:00:47.394  Note             hci.c.316: create_connection_for_addr 48:35:2B:90:47:3C, type fc  RECV  
Jan 01 18:00:47.402  Note             hfp.c.896: accept sco 2  RECV  
Jan 01 18:00:47.406  HCI Event        Undecoded Event  RECV  
Jan 01 18:00:47.410  Note             hfp.c.2104: Sending hci_accept_connection_request for link settings 8: packet types 0x0048, sco_voice_setting 0x43  RECV  
Jan 01 18:00:47.421  Note             hci.c.7409: Possible SCO packet types 0x0048 => payload length 60  RECV  
Jan 01 18:00:47.428  HCI Command      [0429] Accept Synchronous Connection Request - 48:35:2B:90:47:3C  SEND  
	[0429] Opcode: 0x0429 (OGF: 0x01    OCF: 0x29)
	Parameter Length: 21 (0x15)
	Bluetooth Device Address: 48:35:2B:90:47:3C
	Transmit Bandwidth: 0x00001F40
	Receive Bandwidth: 0x00001F40
	Max Latency: 0xFFFF
	Content Format: 0x0043
	    Input Coding -- Linear
	    Input Data Format -- 2's Complement
	    Input Sample Size -- 8 Bit
	    Linear PCM Bit Position: 0x0000
	    Air Coding Format -- Transparent Data
	Retransmission Effort: 0x00FF
	    Don't Care
	Packet Type: 0x0388
	    EV3 May Be Used
	    3-EV3 May Not Be Used
	    2-EV5 May Not Be Used
	    3-EV5 May Not Be Used
Jan 01 18:00:47.428  HCI Command      00000000: 2904 153C 4790 2B35 4840 1F00 0040 1F00  )..<G.+5H@...@..  SEND  
Jan 01 18:00:47.438  HCI Event        Command Status - Accept Synchronous Connection Request  RECV  
Jan 01 18:00:47.441  HCI Event        Synchronous Connection Complete - SCO Offset Rejected  RECV  
	Parameter Length: 17 (0x11)
	Status: 0x1B - SCO Offset Rejected
	Connection Handle: 0x0180
	Bluetooth Device Address: 48:35:2B:90:47:3C
	Link Type: 0x02 -- eSCO Connection
	Transmission Interval: 0x06
	Retransmission Window: 0x00
	Rx Packet Length: 0x001E
	Tx Packet Length: 0x001E
	Air Mode: 0x03 -- Transparent Data
Jan 01 18:00:47.441  HCI Event        00000000: 2C11 1B80 013C 4790 2B35 4802 0600 1E00  ,....<G.+5H.....  RECV

More Information.

When running the same demo on a CSR8510 USB Bluetooth dongle, the SCO connection gets initiated as expected.
When only iPhone is connected, the SCO connection gets also correctly initiated.

BTstack uses:

• Max Latency: Don't care
• Retransmission Efforts: Don't care
• Packet Types: EV3 and 2-EV3

Quick look into Bluedroid tells me that it uses:

• Max Latency: 13
• Retransmission Efforts: At least one retransmission, optimize for link quality
• Packet Types: EV3 and 2-EV3

So, BTstack's requirement are even more relaxed, but result in the same connection settings if the connection gets established correctly.

[esp-lrh]

Hi, I have reproduced this issue in my local environment with two android phones too.I found some abnormal behavior in controller when doing eSCO parameter negotiation.
We will fix this issue as soon as possible, thanks for your feedback!

[esp-lrh]

HI, further analysis indicates that this issue is caused by a conflict between the interval events of the Sniff Mode and SCO, resulting in the inability to find a valid SCO offset. As a result, the controller rejected the request to establish an SCO connection.

As this issue involves some underlying logic, the solution is still under discussion. In the meantime, you can temporarily work around this issue by disabling Sniff Mode.

[Sherry616]

Thanks for reporting, we will close this issue. Feel free to reopen if have more updates.
Thanks for using our Espressif product!