Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [pulseaudio-discuss] Proposal for a new API and usage of
 Bluetooth HSP and HFP profiles on Linux
To:     =?UTF-8?Q?Pali_Roh=c3=a1r?= <pali.rohar@gmail.com>
Cc:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        Tanu Kaskinen <tanuk@iki.fi>,
        General PulseAudio Discussion 
        <pulseaudio-discuss@lists.freedesktop.org>, ofono@ofono.org,
        devkit-devel@lists.freedesktop.org,
        Bastien Nocera <hadess@hadess.net>,
        Georg Chini <georg@chini.tk>,
        Russell Treleaven <rtreleaven@bunnykick.ca>,
        Arun Raghavan <arun@arunraghavan.net>,
        Marcel Holtmann <marcel@holtmann.org>,
        Sebastian Reichel <sre@ring0.de>, Pavel Machek <pavel@ucw.cz>
References: <3ca53c66-1df0-41bf-710e-dea709906234@gmail.com>
 <20191218172828.vfie4su2whts2fqh@pali> <20191218173632.aqdmdhutu3ruezck@pali>
 <06eb7e98-1357-afd1-40a5-2ccb139d8dec@gmail.com>
 <20191218213349.2ksew2wnhgu3peub@pali>
 <0cfbe253-417c-e7c0-553a-abf360a80c9f@gmail.com>
 <20191219095132.blj3oyyrlfowv5ik@pali>
 <90261b42-1048-370f-7680-acd9f7e754ed@gmail.com>
 <20191219153344.hxnoa3idqvgdwrp2@pali>
 <76f1cb25-b608-e4e9-6fd9-8da932c56a15@gmail.com>
 <20191220224657.n4m6qkxa4sceau3l@pali>
From:   Denis Kenzior <denkenz@gmail.com>
Message-ID: <1eeea3f8-d06b-f774-c01d-1c7dbdb71c32@gmail.com>
Date:   Tue, 7 Jan 2020 11:35:48 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20191220224657.n4m6qkxa4sceau3l@pali>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Pali,

<snip>

>> I think you will need to do this regardless.  Otherwise I fail to see how
>> you prevent one 'agent' from consuming AT commands it shouldn't be. This is
>> a possibility you need to consider, whether it happens by accident or
>> maliciously.
> 
> Some subset of AT commands are needed to parse and interpret. But not
> telephony commands and having up-to-date internal telephony state.

Please think some more about what I said.  You will need to parse every 
AT command in your daemon, no way around that.  You are right that you 
do not need to keep track of the telephony state, but that is besides 
the point.  So if you need an AT parser anyway, the whole reasoning for 
the proposed architecture starts to look shaky.

<snip>

> 
>> - The other example is more practical. HFP Service Level Connection (SLC)
>> establishment is actually quite tricky.  There are certain limitations on
>> what can and cannot be done prior to SLC establishment, including how audio
>> handling is done.
> 
> I know :-) I already implemented prototype implementation to check and
> see how complicated it is and if API make sense and how hard it is for
> agents (audio - pulseaudio) implement and maintain it.
> 
>> Unfortunately, codec negotiation, indicator negotiation,
>> and feature negotiation are part of the SLC. oFono already solves all of
>> this and handles all of it nicely.
> 
> CSR codecs are not supported nor implemented in ofono. It is more
> complicated as HFP codecs... and needs a new API for audio application.
> Another value which brings my hsphfpd is that it handles these CSR
> codecs and provide API for audio application to use them.
> 

Again, you're not addressing my main point.  Codec negotiation is part 
of SLC establishment.  SLC has both telephony and audio aspects. 
They're inseparable.  Your architecture fails to address this...

CSR codecs are not part of SLC and can be bolted on later.  I already 
told you that oFono can easily be changed to support this.

>> We have passed all relevant
>> certification testing.  It is very unclear how you plan to handle this (or
>> whether you realistically even can) in your architecture when the
>> responsibilities are split between the various daemons.  So again, oFono has
>> nothing to gain here...
> 
> I was not thinking about certification. It is not something which I
> could do.... And also pulseaudio itself do not have certifications.

So again, no reason for us to get involved :)

Bottom line is there's no value for us in this architecture.  If you 
want to use the existing oFono APIs, that's fine.  But we're not adding 
a plugin for taking arbitrary AT commands from some other daemon :)

<snip>

>> Perhaps this can even be solved in oFono itself (since it already does 90%
>> of what you want) by making the modem requirement optional.  What we could
>> do for example is to create a dummy modem if an AG connection is requested
>> and no other suitable modems are detected in the system.  The resultant AG
>> wouldn't have any call control capability, it could still be used for
>> transferring audio data, battery, etc.  If you want to pursue this, we can
>> brainstorm further.
> 
> Well, if this would work automatically without any user interaction or
> without special setup, it seems to be usable.
> 
> But what is needed from this implementation in ofono? Basically API for
> each functionality designed in hsphfod daemon. And one of it is also
> support for HSP profile (with CSR and Apple extensions).

Start a separate thread on ofono for this.  I already gave you hints on 
how to solve the 'AG without a real modem' use case.  That would seem to 
be the biggest 'win' and it should be fairly easy to make this work.

> 
> I'm not against for it, but I thought that having functionality which is
> not related to telephony / modem you would not want to see in ofono
> project (like linux uinput layer for button events or API for displaying
> raw text on embedded display; or CSR audio codec negotiation).
> 
> So how do you see possibility to have also HSP profile in ofono? So have
> one place which would provide audio API for SCO? Because this is a big
> requirements from audio software side, to not use 4 different APIs to
> access SCO sockets (and its rfcomm / SLC configuration) in HSP and HFP
> profiles.
> 

HSP is a separate issue.  Maybe we can handle it like the 'dundee' 
daemon inside oFono (which handles Bluetooth DUN profile).  In other 
words have a dedicated daemon for hsp support that reuses the relevant 
bits of oFono and maybe exposes the same APIs (i.e the ones documented 
in doc/handsfree-audio-api.txt).  That would make life for PulseAudio 
pretty easy.

Regards,
-Denis