Audiowechsel

Da die Nutzer immer häufiger mehrere Audioquellen für ihre Arbeit verwenden, bei alltäglichen Aufgaben wird immer öfter nach einer einfacheren Lösung für die Verwaltung des Headsets gesucht. geräteübergreifend nutzen. Beim Audio-Wechsel werden die Headset-Verbindungen nahtlos umgestellt zwischen Geräten basierend auf Nutzeraktivitäten (z.B. dem Start eines Films) und priorisierten Ereignisse (z. B. eingehende Anrufe)

UX-Prinzipien

1. Der Verbindungswechsel sollte schnell sein und sich an der Aktion des Nutzers orientieren.
2. Der Verbindungswechsel sollte für Nutzer transparent sein, wenn der Wechsel unerwünscht ist.
3. Beim Wechsel sollte der Datenschutz für Nutzer gewahrt bleiben.

Rollen

Audiowechsel-Seeker: Der Seeker ist ein Audioquellengerät, z. B. ein Smartphone oder Tablet) und suchen Sie nach einem Headset in der Nähe, mit dem Sie sich gegebenenfalls verbinden können.

Audiowechselanbieter: Der Anbieter ist normalerweise ein Headset, das für seine Anwesenheits- und Verbindungsstatus, sodass Nutzer Entscheidungen zum Wechsel treffen können.

Übersicht der Anforderungen

Für einen intelligenten Wechsel müssen Dienstleister die folgenden Anforderungen erfüllen:

Werbenutzlast

Der Anbieter muss seinen aktuellen Verbindungsstatus in der Anzeige angeben, basierend auf den Kontodaten für die Funktion „Schnelles Pairing“, Werbung: Wenn nicht sichtbar:

Die Version von Tabelle 4.2 ist 0x1.

Feld „Verbindungsstatus“

Empfiehl dem LE Audio Provider, alle angegebenen Kontexttypen zu verarbeiten. in Assigned Numbers 6.12.3 (es sei denn, der Anbieter unterstützt einen bestimmten Kontexttyp ausdrücklich nicht) und die Karte den Kontexttyp auf den Verbindungsstatus wie unten dargestellt.

• Dialogorientiert: 0 x 9
• Medien: 0 x 8
• Spiel: 0 x 7
• Anleitung: 0 x 7
• Sprachassistenten: 0x9
• Live: 0x9
• Soundeffekte: 0x2
• Benachrichtigungen: 0 x 2
• Klingelton: 0x9
• Benachrichtigungen: 0 x 7
• Notfallalarm: 0x9

Für den Kontexttyp „Gemischtes LE Audio“, z. B. das Abspielen von Medien während verwendet der Anbieter den Verbindungsstatus mit der höchsten Priorität, d.h. 0 x 9 (Aufruf) für das obige Szenario anstelle von 0 x 8 (Medien).

Bitmap der verbundenen Geräte

Um einen unerwünschten Verbindungswechsel zu vermeiden, muss der Seeker möglicherweise wissen, Gerät(en), mit dem/denen das Headset momentan verbunden ist. Wenn das Headset zum Beispiel mit dem Telefon verbunden ist, möchte der Nutzer nicht durch die die Verbindung wechselt, wenn eines der Familienmitglieder YouTube Tablet.

Beachten Sie, dass diese Bitmap anonym ist. Der Seeker kann nicht wissen, Geräte mit dem Anbieter verbunden sind. Beispiel: 5 gebundene Geräte:

• 0: Laptop (0bx0000000)
• 1: phoneA (0b0x000000)
• 2: phoneB (0b00x00000)
• 3: Tablet (0b000x0000)
• 4: Fernsehen (0b0000x000)

Wenn es sich bei den derzeit verbundenen Geräten um einen Laptop und ein Tablet handelt, Bitmap ist 0b10010000. Die Bestelländerung ist akzeptabel, wenn dies unvermeidbar ist, z.B. wenn Nutzer das Headset auf die Werkseinstellungen zurücksetzen oder wenn die Anzahl der verbundenen Geräte die Obergrenze erreicht.

Zufällig auflösbare Anzeige

Um Tracking zu vermeiden und die Privatsphäre der Nutzer zu respektieren, sollte der Dienstleister rotieren und Verschlüsseln Sie das Feld mithilfe des Kontoschlüssels mit AES-CTR:

 encrypted_connection_status_field = connection_status_raw_data ^ AES(Key, IV)

Bitte wo?

1. Der Schlüssel wird vom Kontoschlüssel in Verwendung abgeleitet, der wird im nächsten Abschnitt definiert.

   • Der Schlüssel wird von der HKDF-Funktion, IETF RFC 5869, unter Verwendung des SHA-256-Algorithmus generiert Hash-Funktion verwendet werden.

       Key = HKDF(account_key, NULL, UTF8("SASS-RRD-KEY"),16)
     

   • Der Anbieter muss hier den ursprünglichen Kontoschlüssel verwenden, d.h. das erste Byte des Schlüssels ist 0x04 und nicht im Verwendungsmuster enthalten.

2. IV (erster Vektor) ist das 2-Byte-Salz der Kontoschlüsseldaten mit Null. Padding, d.h. IV steht für concat(Salt, 14-Byte-NULL-Werte).

3. Die Rohdaten für den Verbindungsstatus sind in Tabelle 4.1 definiert, wenn der ändert sich der Verbindungsstatus, sollten Salt und RPA neu generiert werden. innerhalb desselben Werbezeitraums.

Dadurch wird das Feld für den Status der verschlüsselten Verbindung gleichzeitig mit der Kontoschlüsseldaten werden rotiert.

Die BLE-Anzeige ist so aufgebaut:

Wenn beispielsweise die zufällig auflösbaren Daten eine verschlüsselte Verbindung enthalten, Statusfeld enthält, ist das entschlüsselte Ergebnis die Feld für den Verbindungsstatus.

Um Manipulationen zu verhindern, sollten die Kontoschlüsseldaten oben leicht geändert werden wenn die Random Resolvable Data in der Anzeige enthalten ist. In der Regel geschieht Folgendes: der Kontoschlüsselfilter erstellt, wird ein Wert V erzeugt, indem das Konto mit einem Salt versehen. Wenn zufällige auflösbare Daten ebenfalls sollte der Wert V wie folgt konstruiert sein:

 V = concat(account_key, salt, random_resolvable_data)

Wenn sowohl Akkudaten als auch zufällig auflösbare Daten beworben werden, sollte V so aufgebaut sein:

 V = concat(account_key, salt, battery_data, random_resolvable_data)

Verwendeter Kontoschlüssel

Der Verbindungswechsel erfolgt kontobasiert, daher sollte der Anbieter die Kontoinformationen der aktuellen Verbindung im BLE-Advertising. Wenn die das aktuell verbundene Gerät einen Audio-Switcher ist, sollte der Anbieter um den mit diesem Seeker verknüpften Kontoschlüssel abzurufen und diesen Kontoschlüssel zu verwenden, und verschlüsseln Sie das Feld mit dem Verbindungsstatus. Wenn es sich bei der verbundenen Audioquelle nicht um Audio handelt Switch Seeker muss der Anbieter den zuletzt verwendeten Kontoschlüssel verwenden.

Vor der Berechnung des Filters für den Kontoschlüssel sollte der Anbieter die erste Byte der Kontoschlüssel so, dass eines der folgenden Verwendungsmuster enthalten ist:

1. 0b00000100
   Dieser Kontoschlüssel wird nicht verwendet.
   Dies ist die Standardeinstellung (siehe Kontoschlüssel).
2. 0b00000101
   Dieser Kontoschlüssel ist der zuletzt verwendete Kontoschlüssel.
   Das Feld für den Verbindungsstatus wird mit diesem Kontoschlüssel verschlüsselt. Es gibt keine Kontoschlüsselinformationen des aktuellen Verbindungsstatus anzeigt, verbundene Geräte oder das verbundene Gerät kein Audio-Wechsel-Seeker ist.
3. 0b00000110
   Dieser Kontoschlüssel ist der verwendete Kontoschlüssel.
   Das Feld für den Verbindungsstatus wird mit diesem Kontoschlüssel verschlüsselt und der aktuelle verbundenes Gerät ist mit diesem Kontoschlüssel verknüpft.

Schema für Audio-Wechsel-Nutzlast

Die folgende Abbildung zeigt das Schema für die Nutzlast des Audio-Wechsels.

Nachrichten

Wenn eine Verbindung besteht, können der Sucher und Anbieter den Nachrichtenstream verwenden, um Audio zu synchronisieren. Wechselfunktion, einen Verbindungswechsel auslösen, den Wechsel einstellen Benachrichtigungen über den Verbindungsstatus usw. Wir erstellen eine Nachrichtengruppe spezielle Nachrichtencodes für den Audio-Wechsel, wie unten beschrieben.

In den folgenden Abschnitten finden Sie weitere Informationen zu den einzelnen Nachrichtencodes.

Um die Nachrichtenauthentifizierung zu ermöglichen, enthalten alle Audio-Wechsel-Nachrichten zusätzliche Für Daten, die vom Seeker an den Anbieter gesendet werden, ist ein Nachrichtenauthentifizierungscode erforderlich. Wann? eine Nachricht mit MAC eingeht, sollte diese bestätigt werden, damit der Seeker weiß, ob der Provider auf die Nachricht reagiert hat oder nicht.

Wenn die Nachrichtenauthentifizierung erfolgreich ist, sendet der Anbieter eine Bestätigung für die Nachricht:

Wenn sie fehlschlägt, hat der Dienstleister die NAK für die Nachricht zu senden:

Wenn der Anbieter der Absender ist, ist keine MAC-Adresse erforderlich.

Funktion „Audio-Wechsel“ nutzen

Sowohl der Audio-Wechselanbieter als auch der Seeker können prüfen, ob das verbundene schnelle Pairing Der Sucher/Anbieter unterstützt den Audio-Wechsel oder nicht. Verwenden Sie dazu die folgende Nachricht:

Bei Erhalt der Nachricht Funktion „Audio-Wechsel“ Code eingeben, antwortet der Seeker/Anbieter für den Audiowechsel mit einer der folgenden Anfragen: Flags:

Nach Erhalt dieser Nachricht hat der Anbieter den Nachrichtencode 0x34, benachrichtigt den Verbindungsstatus.

Verbindungsstatus benachrichtigen

Wie in der BLE-Werbenutzlast definiert, Multipoint-Anbieter, wenn sich der Verbindungsstatus ändert, mit Ausnahme von sollte der Provider auch die verbundenen Seekers benachrichtigen, den gleichen Kontoschlüssel für die Änderung verwenden. Wenn der Anbieter verbunden ist mit einem Sucher mit Audio-Wechsel und einem Sucher ohne Audio-Wechsel, wenn der Switch Seeker aktiv ist, sollte der Provider auch das verbundene Audiosystem Wechseln Sie mit dem Kontoschlüssel des Seekers zum Verbindungsstatus.

 encrypted_connection_status = connection_status_raw_data ^ AES(Key, IV)

• Der Schlüssel wird vom verwendeten Kontoschlüssel abgeleitet, siehe Zufällig auflösbare Anzeige.

   Key = HKDF(account_key, NULL, UTF8("SASS-RRD-KEY"),16)
  

• IV ist concat(Session_nonce, Message_nonce)

• connection_status_raw_data = concat(connection_state, custom_data, verbundene_Geräte), die in BLE definiert sind, Werbenutzlast Beachten Sie, dass das Byte für Feldlänge und -typ nicht enthalten sein sollte, da Hier sehen Sie den Nachrichtencode und die Datenlänge.

Bei Audiowechsel-Verbindung benachrichtigen

Anbieter von Audio-Wechsel müssen möglicherweise wissen, ob der Verbindungswechsel ausgelöst wird über die Funktion „Audio-Wechsel“, um verschiedene Reaktionen zu erhalten, z.B. Earcons für Audio deaktivieren wechseln. Der Seeker sendet eine Nachricht, um den Anbieter darüber zu informieren, Verbindung war eine Verbindung, die vom Audio-Wechsel initiiert wurde.

Die Referenzimplementierung finden Sie in der Nearby Embedded SDK Library.