UselessPickles
Active Member
Call waiting can be confusing, even when it's working perfectly with a high quality display of a modern touch-screen phone that presents multiple options with descriptive labels, and can clearly show the status of multiple calls.
Try to implement support for call waiting on a vintage car phone with physical buttons never intended to intuitively support this functionality, and a display that can only show 2 lines of 7 characters each, while working with limited information about call state from the Bluetooth Hands-Free profile, and it gets way more confusing.
First, I'll describe the possible call statuses that can be reported by the Bluetooth module:
There are also many commands supported by Bluetooth HFP that affect the call status. There are raw AT commands for each of these, and the Bluetooth module exposes these as supported UART commands:
The only buttons on the car phone that can reasonably relate to any of these actions are:
I started with evaluating the original behavior of these buttons according to the car phone's owner's manual:
I think this results in a fairly easy-to-remember pattern of what the buttons do in all cases (even when call waiting is involved):
So that's one tough job done: simply understanding the possible call states and actions that can be taken in each state, and deciding how to use the buttons to perform those actions.
To be continued...
Try to implement support for call waiting on a vintage car phone with physical buttons never intended to intuitively support this functionality, and a display that can only show 2 lines of 7 characters each, while working with limited information about call state from the Bluetooth Hands-Free profile, and it gets way more confusing.
First, I'll describe the possible call statuses that can be reported by the Bluetooth module:
- IDLE: Not in a call, nothing happening.
- VOICE_DIAL: Not quite sure, because I'm not using this. I think when the phone's voice assistant is activated? (e.g., Siri for iPhone)
- INCOMING: Someone is calling you. You can answer the call, or reject it.
- OUTGOING: You initiated a call, and the recipient has not answered yet.
- ACTIVE: You're actively in a call.
- ACTIVE_WITH_CALL_WAITING: You're actively in a call, and someone else is calling you. This is when you see the terrifying options pictured above.
- ACTIVE_WITH_HOLD: You're actively in a call, and another call is on hold.
There are also many commands supported by Bluetooth HFP that affect the call status. There are raw AT commands for each of these, and the Bluetooth module exposes these as supported UART commands:
- Place an outgoing call to a specified number.
- Answer an incoming call.
- Reject an incoming call.
- End all calls.
- End the active call and accept the call waiting.
- Reject the call waiting call (send it to voicemail).
- Place the active call on hold and accept the call waiting.
- Swap the active call and on-hold call
- If only one call in progress, then it toggles that call between active and on hold.
- NOTE: There is no call status that corresponds to this idea of "only a single call, and it's on hold". There's no way detect this status or transition in status via the call status event. It's always simply "ACTIVE" regardless of whether the call is on hold or not.
- End all calls except for the active call.
- End the active call and swap to the on-hold call.
- Plus more that I'm not worrying about.
The only buttons on the car phone that can reasonably relate to any of these actions are:
- END
- SEND
- FCN (for modified/alternate action)
I started with evaluating the original behavior of these buttons according to the car phone's owner's manual:
- END:
- Rejects an incoming call.
- Ends an active call.
- SEND:
- Answers an incoming call.
- Sends a "flash" request while in an active call.
- NOTE: Equivalent to to quickly pressing the "hook" button on older analog land-line phones, which is how call-waiting calls were answered/swapped when call waiting was introduced to land-lines.
- FCN + SEND:
- While in an active call, sends the current digits on the screen as DTMF tones.
- END always ends the currently active call.
- SEND answers incoming calls, and can swap between multiple calls (but never ends any calls).
- FCN + SEND is off limits for call status management because it is already used for a specific different purpose.
- Avoid making use of other arbitrary buttons on the handset, because it would never be intuitive that RCL, CLR, or STO (for example) should be pressed when dealing with answering/ending/swapping calls.
- When there's a call waiting, SEND obviously should answer it (placing the active call on hold), END should end the active call (while accepting the call waiting), but how do we reject the call waiting and stay on the active call?
- When in an active call with another call on hold, SEND should swap the calls, END should end the active call and swap the on-hold call to active, but how do we end the on-hold call and stay on the active call?
I think this results in a fairly easy-to-remember pattern of what the buttons do in all cases (even when call waiting is involved):
- SEND:
- If there's an incoming call of any kind, it will accept that call.
- If a call was already active, then that call is placed on hold.
- If there is no incoming call of any kind, then it will swap the "active" and "on-hold" call.
- If there is only one call, it toggles it between "active" and "on-hold".
- If there's an incoming call of any kind, it will accept that call.
- END:
- Ends the active call.
- If there's an on-hold or waiting call, then that call will become active.
- Ends the active call.
- FCN + END:
- Ends the "other" call (on-hold or waiting).
- Irrelevant and does nothing if there is no "other" call.
So that's one tough job done: simply understanding the possible call states and actions that can be taken in each state, and deciding how to use the buttons to perform those actions.
To be continued...
Last edited: