phone call by linux<->phones bt-coupled and raw data

[enondiov]

Hi all,

I have been able to setup the following design:

{ LINUX_MACHINE_1 <bt_write/bt_read> PHONE } <---------------- TELEPHONY ---------------> { PHONE <bt_write/bt_read> LINUX_MACHINE_2 }

To explain a bit:
-> I bt-coupled 2 different linux machine with two different mobile phone.
-> Each linux machine is equipped with headset (jack, no bt).
-> I can perform normal calls hearing and speaking without any problem.

Now I was trying to get raw "sound data" from "linux_machine_1" to "linux_machine_2".
Let's say I activated one path only:

voice -> "mic" -> jack on linux_machine_1 -> bt_write -> phone -> telephony -> phone -> bt_read -> jack on linux_machine_2 -> headphone -> sound at ear.

In that test case, when I output raw data BT_WRITE versus BT_READ, I cannot see the same values (still hearing the voice).

Am I expecting something wrong or should be possible to get same BT packets?

Any help really appreciated guys

[borine]

The voice "telephony" link between mobile phones uses a "lossy" codec, meaning that it is impossible for the receiving device to precisely reconstruct the exact same data stream as was encoded by the sending device. Then add to that the 2 bluetooth links which also use "lossy" codecs (CVSD or mSBC) and you can see that there is always going to be significant differences in the data streams passing over the 2 HCI links. What matters is that the 2 different data streams produce audio streams that are similar enough to be recognized by the human ear as "the same".

[enondiov]

Hi @borine, did you have a chance to read my reply? thank you :-)

[borine]

@enondiov I cannot help. I know nothing about proprietary hw or data transfer solutions.

[enondiov]

Thank you very much. Just one point more: I have evidence that one company is able to perform call enc/dec with a very similar setup. They have a dedicated HW setup so probably solving the lossy stuff on one side (not using cvsd probably).But still, I could they solve the "telephony" side ?? Any help really appreciated

[enondiov]

thank you @arkq, that is what I was thinking about.

Regarding the point "2." I would like to avoid any sw/fw modification on the phone side in order to simplify my deployment, no sw/app to install for the final user (should work in any condition, with any phone...)

That said, in theory the "cvsd data" encryption may happen on the LINUX side just before [BT_I/O data write -> phone].
I tried to add that encryption at the very last stage into the bluealsa proj but still getting wrong data on the other side, may be:

1. I still have to find the correct point to add encryption/decryption stuff after/before "cvsd codec" take place.
2. The GSM transmission is adding those errors (I am not managing that). Nice hint on the GSM parity bit :-).... did not think to that....

Do you think make sense?

Again thank you for the support and please further comment if you can.

[arkq]

I think that without modification on the phone side it will be impossible. Either you will have to modify GSM stack, or use "custom" GSM chip which does not perform AMR encoding. I don't know how the GSM encoding is performed in Android, but I suspect that it is offloaded to dedicated modem chip - in a similar way CVSD is done in Bluetooth (at least in a default configuration).

[enondiov]

thank you @arkq ...

All off this because I read on a company website that they use AES256 for audio call (gsm, ...) encryption/decryption.
They plug headsets and mob phones into a custom HW device (2 setup of course).
So they overcome the BT CVSD part, but the GSM lossy stack is still in place, and with AES256 couldn't work...

They claim being able to litterally:
<< encrypts your voice [gsm...], before sending it to the phone. [...] By using militarly level AES 256bit encryption the voice can only be decrypted by the intended recipient.
NO apps + no internet needed. >>

I cannot exaplain this... damn :-(

[arkq]

encrypts your voice [gsm...], before sending it to the phone.

Hmm.... So, maybe my assumption about lossy GSM encoding is wrong. Maybe the PCM (encrypted one) which is going into the phone is prepared in a way that the GSM encoding is not lossy any more. I don't know. I've never been doing anything with GSM by myself. Everything what I say is based on my experience in other areas. I suggest you to read some specifications for GSM. Maybe you will find the answer there.

[enondiov]

I'll let you know as soon as I find the solution to this problem...
thank you again

[borine]

Here's a thought experiment:

sender : voice -> ADC -> encrypt -> modulate -> audio pulses -> GSM
receiver: GSM -> audio pulses -> demodulate -> decrypt -> DAC -> voice

Here the key is modulation: like in the old days with 56k modems for transferring data over analog phone lines. The encryped data stream is transformed into a stream of audio pulses which can be demodulated back to the original encrypted data stream even after transmission over a "lossy" network (provded it is not too lossy !!)

[arkq]

Yes, I was thinking exactly about the same, but I was not sure whether there will be enough GSM bandwidth for such modulation. Anyway I would say that this is the most probable solution for end-to-end encryption over standard voice link. However, I'm not sure whether GSM provider will be happy about that. For instance I know that here in Poland voice connection which are idle (no voice, just ambient noise) are dropped after some time. Similar thing might be if voice is not a voice but a digital noise :D