Hi Frédéric, On Fri, Jun 27, 2025 at 10:52 AM Frédéric Danis <frederic.danis@xxxxxxxxxxxxx> wrote: > > This will introduce a new Telephony interface wich is intended to be > shared by the profiles able to control telephony calls. > > The idea is to split the call control interface from the audio streaming, > as it is done for AVRCP and A2DP. > As for A2DP, the audio part will be delegated to the audio daemon (like > PipeWire) by the creation of new endpoints for CVSD and mSBC, LC3 endpoint > already exists. > > The interface is mostly based on the one done for PipeWire's native > backend. > > This will simplify the qualification of the telephony related profiles as > the qualification will no more depend on external projects, and calls can > be controlled from bluetoothctl. > > A first implementation allows to dial or hangup a call using HFP. > > v1->v2: > - Rename org.bluez.TelephonyCall1 to org.bluez.Call1 > - Remove reference to profiles in org.bluez.TelephonyAg1 object path > - Add profile UUID property to org.bluez.TelephonyAg1 > - Add OperatorName property to org.bluez.TelephonyAg1 > - Rename telephony_set_call_state() to telephony_call_set_state() > - Use first available index of call for new call > - Fix DBus message memory leak in hfp_dial_cb() > - Display UUID and OperatorName in bluetoothctl telephony.show command > - Add hangup-active and hangup-held support > - Add SendTones support > - Remove HFP specific comments in documentation > - Add HFP HF server and related SDP record > - Add OperatorName support to HFP HF > - Add call line identification property support to HFP HF > - Disable NREC during HFP HF connection phase > - Enable Waiting call event to HFP HF > - Enable Extended error support in HFP HF > - Add telephony_call_set_multiparty() to telephony API > - Enable Enhanced call status support in HFP HF, and use it to update > calls status if available on both side > > Frédéric Danis (27): > doc: Add new telephony related profiles interfaces > audio/telephony: Add shared interfaces implementation > audio/telephony: Add skeleton for HFP profile > audio/hfp-hf: Add HFP SLC connection and event support > audio/hfp-hf: Add dial support > audio/hfp-hf: Add hangup all calls support > audio/hfp-hf: Add answer a specific call support > client/telephony: Add new submenu > audio/hfp-hf: Remove call interface during profile disconnection > audio/hfp-hf: Create existing call during SLC phase > audio/telephony: Add hangup_active and hangup_held functions > audio/hfp-hf: Add hangup_active and hangup_held support > client/telephony: Add hangup_active and hangup_held support > audio/hfp-hf: Add SendTones support > client/telephony: Add SendTones support > doc: Make telephony docs more generic > client/telephony: Remove IncomingLine > audio/telephony: Remove IncomingLine > audio/hfp-hf: Add HFP HF server and SDP record > audio/hfp-hf: Add operator name support > audio/telephony: Add call line identication property support > audio/hfp-hf: Add call line idenfication support > audio/hfp-hf: Disable NREC during connection setup > audio/hfp-hf: Enable waiting call if supported by remote AG > audio/hfp-hf: Enable extended error if supported by remote AG > audio/telephony: Add call multiparty property support > audio/hfp-hf: Enable enhanced call status if supported by remote AG This is sort of too big to review all at once, Id start just with documentation so we can nail down the interfaces first, then we can proceed to other details, anyway from the brief looking at it some things already show in the design: 1. The usage of glib function is not recommended on new code, things like g_new0/g_free, etc, shall be replaced with util helpers or just plain libc function. 2. There doesn't seem to be anything added to src/shared/hfp.h which will make it really tricky to do unit testing since a lot of things seems to be done in plugin, if the idea is to really have something that is qualifiable Id look into expanding test-hfp to handle HFP testing spec test cases which should enable us to determine what needs to be inside shared/hfp and what doesn't. -- Luiz Augusto von Dentz
