Multiple HFP connections / single call, callsetup, callheld status

[amorniroli]

Describe the bug

Inside hfp_hf.c I've noticed these three variables which are declared as "singleton".

static hfp_call_status_t      hfp_hf_call_status;
static hfp_callsetup_status_t hfp_hf_callsetup_status;
static hfp_callheld_status_t  hfp_hf_callheld_status;

Some BT stack events (e.g. HFP_SUBEVENT_START_RINGING) are not triggered if, for example, we have two mobile phones connected to the controller, and 1 call is already ringing.

To Reproduce

If needed, I'll provide example in the form of 'btstack_main' to reproduce the issue.

As pseudo code:

• configure btstack as audio gateway, to support at least 2 connections;
• pair two mobile and establish SLC with them;
• call phone number 1 -> START_RINGING routed correctly;
• keep call phone number 1 ringing active and call phone number 2 -> START_RINGING is not routed

Expected behavior I'd expect that both START_RINGING would have been routed correctly.

HCI Packet Logs I can produce it if needed.

Environment: (please complete the following information):

• btstack branch develop (44ce5de30f3de9a42b0a94ec3bd8c1c3418ed9d6 )
• CYW20706
• Android/iPhone

Additional context I think the problem is that the check is done on "singleton" variable and not real HFP context status

e.g.

                bool ringing_old = hfp_is_ringing(hfp_hf_callsetup_status);
                bool ringing_new = hfp_is_ringing(new_hf_callsetup_status);
                if (ringing_old != ringing_new){
                    if (ringing_new){
                        hfp_emit_simple_event(hfp_connection, HFP_SUBEVENT_START_RINGING);
                    } else {
                        hfp_emit_simple_event(hfp_connection, HFP_SUBEVENT_STOP_RINGING);
                    } 
                }     

[mringwal]

You're definitely right about the problem of tracking the call state of multiple mobile phones in a single variable. On a first glance, moving these into the per connection state might already be sufficient. We'll give it a try next week.

[mringwal]

Hi @amorniroli Could you try our changes on develop. We merely moved the globals into the per connection struct and initialized them on connect. Please let me know how this works for two phones, thanks!

[amorniroli]

Hi @amorniroli Could you try our changes on develop. We merely moved the globals into the per connection struct and initialized them on connect. Please let me know how this works for two phones, thanks!

Hi @mringwal , thanks for the fix: it's working as expected.

[mringwal]

Great. Thanks for validating the fix.