Switch audio
Les utilisateurs se servent de plus en plus de plusieurs sources audio les tâches quotidiennes, il y a de plus en plus de demandes pour une solution plus simple sur plusieurs appareils. Le switch audio bascule automatiquement sur la connexion du casque entre les appareils en fonction de l'activité de l'utilisateur (par exemple, lancer un film) et des priorités (un appel entrant, par exemple).
Principes de l'expérience utilisateur
- Le changement de connexion doit être rapide et dépendre de l'action de l'utilisateur.
- Le changement de connexion doit être transparent pour les utilisateurs, ce qui leur permet de ou l'inverser si l'interrupteur n'est pas souhaitable.
- Le passage au Pixel doit respecter la confidentialité des utilisateurs.
Rôles
Audio Switch Seeker: il s'agit d'un appareil source audio (par exemple, téléphone ou tablette), à la recherche d'un casque à proximité, le cas échéant.
Audio Switch Provider: le fournisseur est normalement un casque faisant la promotion de son et l'état de la connexion pour permettre aux utilisateurs de passer au Pixel.
Présentation des conditions requises
Pour mettre en place la transition intelligente, les fournisseurs doivent respecter les exigences suivantes:
Nom | Description | Conditions requises | Obligatoire ? |
---|---|---|---|
Analyse de la page | Pour accepter une nouvelle demande de connexion d'un autre Seeker lorsqu'une connexion existe déjà. Pour les fournisseurs à point unique:
|
Un mode d'analyse des pages à faible latence (l'intervalle d'analyse ne doit pas dépasser 640 ms) est requis pour améliorer les performances. Pour faire un compromis entre l'autonomie de la batterie et les performances de changement, le fournisseur peut définir un mode d'analyse de pages par défaut dans la plupart des cas (mode à faible consommation d'énergie, l'intervalle d'analyse ne doit pas dépasser 1 280 ms). Toutefois, le mode à faible latence doit être utilisé dans les situations suivantes:
|
Obligatoire |
Historique des connexions | Pour revenir à la connexion précédente et reprendre la lecture le cas échéant. Le retour à la lecture sera déclenché par des communications via les API Message Stream. L'événement de mise en pause audio doit être inclus dans l'enregistrement pour reprendre la lecture, le cas échéant. |
Gérez l'historique des connexions et implémentez les API Message Stream. | Obligatoire |
État de la connexion | Pour que les demandeurs puissent juger de la commutation de connexion, l'état de la connexion inclut les éléments suivants:
|
Inclure l'état de la connexion dans les annonces et le flux de messages BLE | Obligatoire |
Modification des fonctionnalités d'exécution | Le switch audio peut être activé en mettant à niveau le micrologiciel sur le fournisseur. Les fonctionnalités doivent donc être synchronisées entre Seeker et le fournisseur au moment de l'exécution. | Implémentez des API de flux de messages pour accéder aux fonctionnalités d'exécution. | Obligatoire |
Règles de transition configurables | Laissez Seeker configurer la priorité entre le streaming audio actif existant et les nouvelles requêtes de streaming audio à l'aide des paramètres de préférences de l'utilisateur. Par exemple, le Seeker peut fournir des paramètres d'interface utilisateur pour permettre aux utilisateurs d'activer ou de désactiver le basculement automatique entre le streaming multimédia et les appels. L'utilisateur du switch audio définit et obtient la règle de basculement via le flux de messages. |
Fournisseurs multipoints uniquement. Implémentez les API de flux de messages pour configurer les règles de basculement entre les appareils connectés. |
Facultatif |
Changement d'appareil actif | Autorisez l'assistant de switch audio à simuler un basculement audio entre les appareils connectés. Du côté du demandeur du switch audio, une UI permettant aux utilisateurs de basculer facilement d'un appareil connecté à l'autre peut être proposée. |
Fournisseurs multipoints uniquement. Implémentez les API de flux de messages pour l'application de recherche de switch audio afin de déterminer la source audio active entre les appareils connectés. |
Obligatoire |
Notification de basculement multipoint | Autorisez l'outil de recherche de switch audio à afficher la notification de changement d'appareil. | Fournisseurs multipoints uniquement. Implémentez les API de flux de messages pour avertir les utilisateurs de switch audio connectés lorsqu'une commutation multipoint est en cours. |
Obligatoire |
Charge utile publicitaire
Le Fournisseur doit indiquer l'état actuel de sa connexion dans l'annonce, basée sur les données du compte Association express décrites dans la section Publicité : lorsqu'elle n'est pas visible :
Notez que la version du tableau 4.2 est 0x1.
Champ "État de la connexion"
Octet | Type de données | Description | Valeur | Obligatoire ? |
---|---|---|---|---|
0 | uint8 |
Longueur et type de champ 0bLLLLTTTT
|
0bLLLL0101
|
Obligatoire |
1 | uint8 |
État de la connexion 0bHAFRSSSS
|
0bHAFRSSSS
|
Obligatoire |
2 | uint8 |
Données personnalisées Actuellement, elles ne contiennent que le type de contenu qui est utilisé pour décrire l'utilisation du streaming audio en cours. Le demandeur l'envoie au Fournisseur. |
La valeur est envoyée par le demandeur du flux actif en cours au fournisseur via un flux de messages. 0 si le streaming actif en cours ne provient pas de Seeker. | Obligatoire |
3 – var | Bitmap des appareils connectés Bitmap indiquant les appareils actuellement connectés au fournisseur. Tous les dispositifs liés sont disposés dans l’ordre, un bit pour un appareil lié. La longueur dépend du nombre d'appareils associés au fournisseur. |
Bit mappé défini sur 1 si l'appareil est actuellement connecté au fournisseur, 0 dans le cas contraire. Pour en savoir plus, consultez le bitmap de l'appareil connecté. |
Facultatif |
Tableau 4.1:Données brutes du champ d'état de la connexion
Indicateurs de connexion
0bH = détection des mouvements de la tête
- 1, à venir
- 0, sinon pas sur la tête ou aucun capteur OHD n'est présent
0bA = disponibilité de la connexion
- 1, une connexion est disponible
- 0, sinon
0bF = mode formulaire
- 1, en mode Sans distractions, le changement de connexion n'est pas autorisé pour les contenus multimédias Utilisation, c'est-à-dire pas de basculement entre A2DP et A2DP
- 0, sinon
0bR = reconnexion automatique
- 1, si la connexion actuelle est automatiquement reconnectée par le fournisseur, c'est-à-dire il n'est pas connecté par les utilisateurs (pour le multipoint, si l'un des est reconnectée automatiquement, elle doit être définie sur 1).
- 0, sinon
État de la connexion
- 0x0: aucune connexion
- 0x1: pagination
- 0x2: connecté, mais aucun transfert de données
- 0x3: transfert de données non audio (uniquement en cas de commutation, si ce n'est pas le cas, en utilisant 0xF)
- 0x4: streaming A2DP, AVRCP non applicable
- 0x5: streaming A2DP et lecture AVRCP
- 0x6: streaming HFP (appel téléphonique/voip), y compris les sonneries hors bande
- 0x7: LE Audio – Streaming multimédia sans contrôle
- 0x8: LE Audio – Streaming multimédia avec commande
- 0x9: LE Audio – Appel en streaming
- 0xA: LE Audio – broadcast
- 0xF: désactiver temporairement le bouton de connexion (par exemple, mise à jour du micrologiciel)
Type de contexte LE Audio et état de la connexion
Il est recommandé que le fournisseur LE Audio gère tous les types de contextes spécifiés dans Assigned Numbers 6.12.3 (sauf si le fournisseur n'accepte pas explicitement un type de contexte donné) et mappez le type de contexte à l'état de connexion, comme ci-dessous.
- Conversationnelle: 0 x 9
- Contenu multimédia: 0 x 8
- Jeu: 0 x 7
- Pédagogique: 0 x 7
- Assistants vocaux: 0 x 9
- En direct: 0 x 9
- Effets sonores: 0 x 2
- Notifications: 0x2
- Sonnerie: 0 x 9
- Alertes: 0 x 7
- Alerte d'urgence: 0x9
Pour les contextes de type LE Audio mixte, par exemple pour lire des contenus multimédias pendant le fournisseur doit utiliser l'état de connexion ayant la priorité la plus élevée, c'est-à-dire 0x9 (appel) pour le scénario ci-dessus au lieu de 0x8 (média).
Bitmap de l'appareil connecté
Pour éviter tout basculement indésirable entre les connexions, il peut avoir besoin de savoir quel le ou les appareils auxquels le casque est actuellement connecté. Par exemple, lorsque le casque est connecté au téléphone, l'utilisateur ne veut pas être interrompu par changement de connexion quand l'un des membres de sa famille lance YouTube sur le tablette.
Notez que ce bitmap est anonyme. Il ne peut donc pas savoir appareils sont liés au Fournisseur. Prenons l'exemple de cinq appareils associés:
- 0: ordinateur portable (0bx0000000)
- 1: phoneA (0b0x000000)
- 2: téléphoneB (0b00x00000)
- 3: tablette (0b000x0000)
- 4: Télévision (0b0000x000)
Si les appareils actuellement connectés sont un ordinateur portable et une tablette, la valeur du le bitmap est 0b10010000. Le changement de commande est acceptable si elle est inévitable. Ex. : Lorsque les utilisateurs rétablissent la configuration d'usine du casque ou lorsque le nombre d'appareils associés atteint la limite supérieure.
Annonce pouvant être résolue de manière aléatoire
Pour éviter le suivi et respecter la confidentialité des utilisateurs, le Fournisseur doit alterner et chiffrez le champ par la clé de compte à l'aide d'AES-CTR:
encrypted_connection_status_field = connection_status_raw_data ^ AES(Key, IV)
où
La clé est dérivée de la clé de compte en cours d'utilisation, est défini dans la section suivante.
La clé est générée par la fonction HKDF, IETF RFC 5869, à l'aide de l'algorithme SHA-256 de hachage.
Key = HKDF(account_key, NULL, UTF8("SASS-RRD-KEY"),16)
Le fournisseur doit utiliser ici la clé de compte d'origine, c'est-à-dire le premier octet de la clé est 0x04. Elle n'est pas incluse dans le modèle d'utilisation.
IV (vecteur initial) correspond à la valeur de salage de 2 octets des données de clé de compte avec zéro une marge intérieure, c'est-à-dire que IV est concat(salt, Zéro sur 14 octets).
Les données brutes sur l'état de la connexion sont définies dans le tableau 4.1, si les les changements d'état de la connexion, le salage et le RPA doivent être régénérés au la même période publicitaire.
Ainsi, le champ d'état de la connexion chiffrée est alterné en même temps que le champ Les données de clé de compte sont alternées.
La publicité BLE sera structurée comme suit:
Octet | Type de données | Description | Valeur | Obligatoire ? |
---|---|---|---|---|
0 | uint8 |
Version et options | 0x10 | Obligatoire |
1 - t | Données de la clé du compte | varie | Obligatoire | |
t+1 – s | Données relatives à la batterie | varie | Facultatif | |
s+1 – var | Données aléatoires pouvant être résolues | varie | Obligatoire si la liste des clés de compte n'est pas vide. Sinon,elle est exclue. |
Tableau 4.2:Annonce BLE avec des données pouvant être résolues de manière aléatoire
Random Resolvable Data contient:
Octet | Type de données | Description | Valeur | Obligatoire ? |
---|---|---|---|---|
0 | uint8 |
Longueur et type de champ 0bLLLLTTTT
|
0bLLLL0110
|
Obligatoire |
1 – var | Données chiffrées | varie | Obligatoire |
Tableau 4.2.1:Données aléatoires pouvant être résolues
Par exemple, si l'élément Random Resolvable Data contient une connexion chiffrée, "status", le résultat déchiffré est le résultat champ d'état de la connexion.
Pour éviter toute falsification, les données de la clé de compte ci-dessus doivent être légèrement modifiées. lorsque les données aléatoires pouvant être résolues sont incluses dans l'annonce. Normalement, lorsque création du filtre de clé de compte, une valeur V est générée en combinant les variables de compte un filtre de clé avec un salage. Au lieu de cela, lorsque des données aléatoires résolubles sont également la valeur V doit être définie comme suit:
V = concat(account_key, salt, random_resolvable_data)
Si des données de batterie et des données pouvant être résolues de manière aléatoire sont annoncées, V doit se présenter comme suit:
V = concat(account_key, salt, battery_data, random_resolvable_data)
Clé de compte en cours d'utilisation
Le changement de connexion s'effectue en fonction du compte. Le fournisseur doit donc inclure le les informations de compte de la connexion actuelle dans l’annonce BLE. Si le l'appareil connecté actuel est un chercheur de switch audio, le fournisseur doit être en mesure pour obtenir la clé de compte associée à ce Seeker et utiliser cette clé de compte pour chiffrer le champ d’état de la connexion. Si la source audio connectée n'est pas de type audio switch Seeker, le fournisseur doit utiliser la dernière clé de compte utilisée.
Avant de calculer le filtre de clé de compte, le fournisseur doit modifier la première des clés de compte pour inclure l'un des formats d'utilisation suivants:
- 0b00000100
Cette clé de compte n'est pas utilisée.
Il s'agit de la clé par défaut (voir Clé de compte). - 0b00000101
Cette clé de compte est la dernière utilisée.
Le champ d'état de la connexion est chiffré par cette clé de compte. Il n'y a aucun des informations clés de votre compte sur l'état actuel de la connexion, cela peut signifier appareils connectés ou l'appareil connecté n'est pas un chercheur de switch audio. - 0b00000110
Cette clé de compte est la clé de compte en cours d'utilisation.
Le champ d'état de la connexion est chiffré par cette clé de compte, et la valeur actuelle l'appareil connecté est associé à cette clé de compte.
Schéma de la charge utile du switch audio
La figure ci-dessous illustre le schéma de la charge utile du switch audio.
![](https://google-developers.gonglchuangl.net/nearby/fast-pair/images/SASS-ble-payload-schematic.png?authuser=1&hl=fr)
Messages
Une fois connectés, le demandeur et le fournisseur peuvent synchroniser l'audio à l'aide du flux de messages déclencher un commutateur de connexion, configurer et obtenir le basculement l'état de la connexion, etc. Nous créons un groupe de messages et codes de message spécifiques au switch audio, comme indiqué ci-dessous.
Nom du groupe de messages | Valeur |
---|---|
Switch audio | 0x07 |
Vous trouverez des informations supplémentaires sur chaque code de message dans les sections suivantes.
Nom du code du message | Valeur | Multipoint uniquement | Expéditeur | Répondant | Chiffrer | Mac | CONFIRMATION |
---|---|---|---|---|---|---|---|
Exploitez le potentiel du switch audio | 0x10 | N | Les deux | Les deux, via le code 0x11 | N | N | N |
Capacité de notification du switch audio | 0x11 | N | Les deux | Les deux | N | O | O |
Définir l'état multipoint | 0x12 | O | Chercheur | Fournisseur | N | O | O |
Définir les préférences de migration | 0x20 | O | Chercheur | Fournisseur | N | O | O |
Préférence pour le passage au Pixel | 0x21 | O | Chercheur | Fournisseur, via le code 0x22 | N | N | N |
Envoyer les préférences concernant le passage au Pixel | 0x22 | O | Fournisseur | Chercheur | N | N | N |
Changer la source audio active(vers l'appareil connecté) | 0x30 | O | Chercheur | Fournisseur | N | O | O |
Revenir à l'ancienne version | 0x31 | N | Chercheur | Fournisseur | N | O | O |
Notifier l'événement de commutateur multipoint | 0x32 | O | Fournisseur | Chercheur | N | N | N |
Obtenir l'état de la connexion | 0x33 | O | Chercheur | Fournisseur, avec le code 0x34 | N | N | N |
Notifier l'état de la connexion | 0x34 | O | Fournisseur | Chercheur | O | N | N |
Informer que le switch audio a initié la connexion | 0x40 | N | Chercheur | Fournisseur | N | O | O |
Indiquer une clé de compte en cours d'utilisation | 0x41 | N | Chercheur | Fournisseur | N | O | O |
Envoyer des données personnalisées | 0x42 | N | Chercheur | Fournisseur | N | O | O |
Définir la cible de suppression de la connexion | 0x43 | O | Chercheur | Fournisseur | N | O | O |
Tableau 4.3:Messages de switch audio
MAC des messages de switch audio
Pour assurer l'authentification des messages, tous les messages de switch audio avec des les données envoyées du demandeur au fournisseur nécessitent un code d'authentification de message. Quand ? un message avec MAC est reçu, il doit être confirmé afin que le demandeur sait si le fournisseur a réagi ou non au message.
Si l'authentification du message réussit, le fournisseur envoie l'ACK pour message:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Acceptation | 0xFF |
1 | uint8 | CONFIRMATION | 0x01 |
2 à 3 | uint16 | Longueur de données supplémentaire | varie |
4 | uint8 | Switch audio | 0x07 |
5 | uint8 | Code du message de switch audio | varie |
6 – s | Données supplémentaires | varie |
En cas d'échec, le Fournisseur envoie la clé NAK pour le message:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Acceptation | 0xFF |
1 | uint8 | N/A | 0x02 |
2 à 3 | uint16 | Longueur de données supplémentaire | 0x0003 |
4 | uint8 | Motif de l'erreur | varie |
5 | uint8 | Switch audio | 0x07 |
6 | uint8 | Code du message de switch audio | varie |
Notez que si l'expéditeur est le fournisseur, l'adresse MAC n'est pas requise.
Exploitez les fonctionnalités du switch audio
Le fournisseur de switch audio et le demandeur peuvent vérifier si l'Association express est connectée Le demandeur/fournisseur prend ou non en charge le switch audio à l'aide du message ci-dessous:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Exploitez les fonctionnalités du switch audio | 0x10 |
2 à 3 | uint16 | Longueur de données supplémentaire | 0 |
Tableau 4.3.1.0:Capacité du switch audio
Notification de la fonctionnalité de switch audio
À la réception de messages de switch audio , le demandeur/fournisseur de commutateurs audio répond avec l'un des éléments suivants : options:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Notification de la fonctionnalité de switch audio | 0x11 |
2 à 3 | uint16 | Longueur de données supplémentaire | 20 si cette valeur est envoyée par le demandeur 4 si elle est envoyée par le fournisseur |
4 – 5 | uint16 | Code de version du switch audio | Une valeur différente de zéro signifie qu'il est compatible avec le switch audio. Le code de la version actuelle (avec l'amélioration de la sécurité) est 0x0102. 0 x 0000 ou aucune réponse en 1 seconde signifie que le switch audio n'est pas compatible avec cet appareil |
6 – 7 | flags | Indicateurs de capacité de switch audio du fournisseur. Si cette valeur est envoyée par Seeker, ces deux octets doivent être ignorés. |
varie Reportez-vous à la section Indicateurs de fonctionnalité de switch audio. |
8 – 15 | Nonce du message Requis uniquement lorsque celui-ci est envoyé par Seeker |
varie | |
16 – 23 | Code d'authentification des messages Requis uniquement lorsque celui-ci est envoyé par Seeker |
varie |
Tableau 4.3.1.1:Capacité de notification du switch audio
Indicateurs de la fonctionnalité de switch audio
Bit 0 (octet 6, MSB): état du commutateur audio
- 1, si l'état du switch audio est activé
- 0, sinon
Bit 1: configurabilité multipoint
- 1, si l'appareil est compatible avec la connectivité multipoint et qu'il peut être activé ou désactivé désactivé
- 0, sinon (non compatible avec la connectivité multipoint ou la fonctionnalité multipoint est toujours activée)
Bit 2: état actuel multipoint
- 1, si la connectivité multipoint est activée
- 0, sinon
Bit 3: détection on-head
- 1, si cet appareil prend en charge la détection frontale (même si la détection dans la tête est désactivée actuellement)
- 0, sinon
Bit 4: état actuel de la détection on-head
- 1, si la détection frontale est activée
- 0, sinon (n'est pas compatible avec la détection on-head ou la détection on-head est désactivée)
Tous les autres bits sont réservés et sont définis sur 0 par défaut.
Définir l'état multipoint
Nous proposons aux utilisateurs qui recherchent un switch audio un paramètre permettant d'activer ou de désactiver ce paramètre. la fonctionnalité multipoint. Le Seeker définit l'état multipoint sur la Fournisseur utilisant le message ci-dessous:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Définir l'état multipoint | 0x12 |
2 à 3 | uint16 | Longueur de données supplémentaire | 17 |
4 | uint8 | État multipoint | 0: désactiver le multipoint 1: activer le multipoint |
5 – 12 | Nonce du message | varie | |
13 – 20 | Code d'authentification du message | varie |
Tableau 4.3.1.2:Définir l'état multipoint
Définir les préférences de transfert
Les utilisateurs en quête de switch audio peuvent modifier les préférences de commutation de la connectivité multipoint et définir au fournisseur en utilisant le message ci-dessous:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Définir les préférences de transfert | 0x20 |
2 à 3 | uint16 | Longueur de données supplémentaire | 18 |
4 | flags | Préférence pour passer au Pixel | varies Voir indicateur de préférence de commutation multipoint |
5 | Paramètres de transition avancés Cet octet est réservé, la valeur par défaut est de 0 |
varie | |
6 – 13 | Nonce du message | varie | |
14 – 21 | Code d'authentification du message | varie |
Tableau 4.3.2.0:Définir les préférences de transition
Indicateur de préférence de commutation multipoint
- Bit 0 (MSB): A2DP vs A2DP (0 par défaut)
- Bit 1: HFP vs HFP (0 par défaut)
- Bit 2: A2DP vs HFP (0 par défaut)
- Bit 3: HFP vs A2DP (par défaut 1)
- Bits 4 à 7: réservé
- Ci-dessus correspond à une "nouvelle demande de profil". par rapport au "profil actif actuel"
<ph type="x-smartling-placeholder">
- </ph>
- 0 correspond à une erreur
- 1 correspond à un changement
Préférence pour passer au Pixel
Les utilisateurs de switch audio peuvent interroger la préférence de basculement du multipoint à partir de Fournisseur utilisant le message ci-dessous:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Obtenir la configuration de la transition | 0x21 |
2 à 3 | uint16 | Longueur de données supplémentaire | 0 |
Tableau 4.3.2.1:Préférence pour le passage au Pixel
Notification de la préférence concernant le passage au Pixel
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Notification de la préférence concernant le passage au Pixel | 0x22 |
2 à 3 | uint16 | Longueur de données supplémentaire | 2 |
4 | flags | Changer d'indicateur de préférence | varies Voir indicateur de préférence de commutation multipoint |
5 | Paramètres de basculement avancés Cet octet est réservé, la valeur par défaut doit être de 0 |
varie |
Tableau 4.3.2.2:Préférence pour le changement de notification
Changer la source audio active (vers l'appareil connecté)
Les demandeurs de switch audio peuvent demander au fournisseur multipoint de changer le source audio entre les appareils connectés avec le message ci-dessous:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Changer la source audio active (vers l'appareil connecté) | 0x30 |
2 à 3 | uint16 | Longueur de données supplémentaire | 17 |
4 | flags | Changer les indicateurs d'événement de la source audio active | varie Voir Changement d'événement de source audio active |
5 – 12 | Nonce du message | varie | |
13 – 20 | Code d'authentification du message | varie |
Tableau 4.3.3.0:Changer la source audio active (vers l'appareil connecté)
Changement de source audio active
- Bit 0 (MSB): un commutateur pour cet appareil, 0 pour le deuxième appareil connecté
- Bit 1: 1 reprise de la lecture sur le commutateur sur l'appareil après le basculement, 0 dans le cas contraire. La reprise de la lecture signifie que le fournisseur envoie une notification de LECTURE au demandeur via le profil AVRCP. Si l'état précédent (avant la désactivation) n'était pas PLAY, le fournisseur doit ignorer cet indicateur.
- Bit 2: 1 rejette le SCO sur l'appareil éteint, 0 dans le cas contraire
- Bit 3: 1 déconnecte le Bluetooth sur l'appareil éteindre l'appareil, 0 dans le cas contraire.
- Bits 4 à 7: réservés.
Les utilisateurs en quête de switch audio ne connaissent pas toujours leur état correctement. Il est donc possible pour que le fournisseur reçoive un "basculement vers cet appareil" lorsque l'observateur est déjà l’appareil actif. Dans ce cas, pour afficher la bonne UI sur Seeker, Le fournisseur peut envoyer un NAK avec le motif de l'erreur, 0x4 – Action redondante sur l'appareil.
Dans le cas d'un fournisseur LE Audio disposant de plusieurs membres, il doit déconnecter tous les membres du Seeker, sinon la pile Bluetooth du L'utilisateur se reconnecte au fournisseur.
Rétablir l'appareil (sur l'appareil déconnecté)
Si le changement de connexion n'est pas souhaitable, les utilisateurs peuvent l'annuler. Dans certains cas, il est judicieux de restaurer la connexion audio pour réduire perturbation de la sécurité. Celui-ci utilisera le message ci-dessous pour déclencher le basculement:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Rétablir l'appareil (sur l'appareil déconnecté) | 0x31 |
2 à 3 | uint16 | Longueur de données supplémentaire | 17 |
4 | uint8 | Événement de retour à la version précédente | varie 0x01: revenir en arrière 0x02: revenir en arrière et reprendre la lecture |
5 – 12 | Nonce du message | varie | |
13 – 20 | Code d'authentification du message | varie |
Tableau 4.3.3.1:Revenir à l'appareil déconnecté
Pour les fournisseurs multipoints, pour effectuer un changement de connexion, un fournisseur peut supprimer la Connexion à un appareil source audio et mise en pause de la session audio sur l'autre source audio. Par exemple, supposons que le casque multipoint est connecté à un tablette et un troisième appareil de switch audio compatible. L'utilisateur regarde la vidéo sur la tablette en cas d'appel entrant sur son téléphone. Le téléphone se déclenche un bouton de connexion sur le casque, qui doit couper le micro pour se connecter au téléphone, tout en mettant le contenu multimédia en pause sur la tablette pour écouter la sonnerie du téléphone. Si l'utilisateur refuse l'appel, le téléphone peut demander au casque "de revenir en arrière et de reprendre la lecture". À la réception de cette demande, le casque doit se reconnecter au 3e appareil, et reprendre la lecture de la vidéo mise en pause sur la tablette.
Notifier l'événement de commutateur multipoint
Pour informer les utilisateurs qu'un événement de commutateur multipoint a lieu, le switch audio Il peut afficher une notification aux utilisateurs. Le fournisseur doit envoyer une notification Chercheurs de switch audio à propos de l'événement de changement de son.
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Notification d'un événement de commutateur multipoint Le fournisseur doit l'envoyer à chaque commutateur, y compris : "Demandeur de switch audio" vers "Informateur de switch audio", "Demandeur de switch audio" vers "Demandeur de switch audio" et "Utilisateur de switch audio" vers "Demandeur de switch audio" dans une recherche de switch audio, etc.) |
0x32 |
2 à 3 | uint16 | Longueur de données supplémentaire | varie |
4 | uint8 | Raison du changement Cette valeur doit être déterminée en fonction de l'état de la connexion. Pour les cas d'utilisation de LE Audio, il peut être utile d'examiner le mappage entre le type de contexte audio LE et l'état de la connexion. Par exemple, l'état de la connexion correspondant aux assistants vocaux est 0x9(LE audio - appel en streaming). Par conséquent, le motif du changement initié par les assistants vocaux doit être 0x02. |
varie 0x00: Non spécifié 0x01: Média (par exemple, streaming A2DP, streaming multimédia LEA) 0x02: appel (par exemple, streaming HFP, appel LEA) |
5 | uint8 | Appareil cible | varie 0x01: cet appareil 0x02: un autre appareil connecté |
6 - n | utf8 | Nom de l'appareil cible si l'appareil cible est Chercheur de switch audio, avec le nom auquel le demandeur a été envoyé. Sinon, utilisez le nom BT (si non applicable) en utilisant les deux derniers octets de son adresse. |
varie |
Tableau 4.3.3.2:Notifier l'événement de commutateur multipoint
Obtenir l'état de la connexion
Le Seeker peut obtenir l'état actuel de la connexion auprès du fournisseur:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Obtenir l'état de la connexion | 0x33 |
2 à 3 | uint16 | Longueur de données supplémentaire | 0 |
Tableau 4.3.3.3:Obtenir l'état de la connexion
À la réception de ce message, le Fournisseur doit répondre par le code de message 0x34, notifier l'état de la connexion.
Informer l'état de la connexion
Comme défini dans la charge utile publicitaire BLE, par les fournisseurs multipoints, si l'état de la connexion change, sauf en cas de modification le paquet publicitaire, le Fournisseur doit également informer les demandeurs connectés qui utilisent la même clé de compte pour la modification. Si le fournisseur est connecté avec un demandeur de switch audio et un demandeur de switch audio non audio, si Switch Seeker est actif, le fournisseur doit également en informer l'utilisateur basculez l'utilisateur sur l'état de la connexion (à l'aide de sa clé de compte).
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Informer l'état de la connexion | 0x34 |
2 à 3 | uint16 | Longueur de données supplémentaire | varie |
4 | uint8 | Indicateur d'appareil actif | varie 0x00: ce Seeker est passif et l'appareil actif utilise la même clé de compte 0x01: ce Seeker est l'appareil actif 0x02: ce Seeker est passif, tandis que l'appareil actif est un demandeur de switch audio. |
5 - n | État de la connexion chiffrée | varie | |
n+1 - n+8 | Nonce du message | varie |
Tableau 4.3.3.4:Notifier l'état de la connexion
Message d'état de la connexion chiffrée
encrypted_connection_status = connection_status_raw_data ^ AES(Key, IV)
où :
La clé est dérivée de la clé du compte en cours d'utilisation. Random Resolvable Publicité.
Key = HKDF(account_key, NULL, UTF8("SASS-RRD-KEY"),16)
IV est concat(Session_nonce, Message_nonce)
connection_status_raw_data = concat(connection_state, custom_data, Connected_devices), ce qui est défini en BLE charge utile publicitaire Notez que l'octet de longueur et de type de champ ne doit pas être inclus, car nous avons ici le code du message et la longueur des données.
Envoyer une notification pour l'établissement d'une connexion avec le switch audio
Les fournisseurs de switch audio peuvent avoir besoin de savoir si le changement de connexion est déclenché. par le switch audio pour avoir des réactions différentes, par exemple désactiver les icônes sonores pour l'audio les événements de commutateur. Le demandeur envoie un message pour avertir le fournisseur que était une connexion initiée par le commutateur audio.
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Envoyer une notification pour l'établissement d'une connexion avec le switch audio | 0x40 |
2 à 3 | uint16 | Longueur de données supplémentaire | 17 |
4 | uint8 | Indication de connexion déclenchée par le commutateur audio | varie 0: cette connexion n'a pas été déclenchée par le switch audio 1: il s'agissait d'une connexion initiée par le switch audio |
5 – 12 | Nonce du message | varie | |
13 – 20 | Code d'authentification du message | varie |
Tableau 4.3.4.0:Notification de connexion initiée par le commutateur audio
Indiquer la clé de compte en cours d'utilisation
Si plusieurs clés de compte sur le Seeker (par exemple, multi-utilisateurs) sont associées à le Fournisseur, le demandeur utilisera le message ci-dessous pour indiquer le compte est utilisée.
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Indiquer la clé de compte en cours d'utilisation | 0x41 |
2 à 3 | uint16 | Longueur de données supplémentaire | 22 |
4 – 9 | utf8 | Chaîne utilisée | UTF8 ("en cours d'utilisation") |
10 – 17 | Nonce du message | varie | |
18–25 | Code d'authentification du message | varie |
Tableau 4.3.4.1:Indiquer la clé de compte utilisée
À la réception de ce message, le fournisseur peut savoir quelle clé de compte est utilisée. en vérifiant le code d'authentification du message.
Envoyer des données personnalisées
L'utilisateur actif peut encapsuler l'information (par exemple, des fichiers audio utilisation) du flux audio dans un octet de données personnalisé, puis l'envoyer au fournisseur en utilisant le message ci-dessous:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Envoyer des données personnalisées | 0x42 |
2 à 3 | uint16 | Longueur de données supplémentaire | 17 |
4 | uint8 | Données personnalisées | varie |
5 – 12 | Nonce du message | varie | |
13 – 20 | Code d'authentification du message | varie |
Tableau 4.3.4.2:Envoyer des données personnalisées
À réception des données personnalisées, le Fournisseur mettra à jour le dossier publicitaire. pour inclure les données personnalisées. Pour un fournisseur multipoint, il doit également avertir l'état de la connexion passe à un autre Seeker connecté à l'aide de la même clé de compte.
Définir l'objectif de suppression de la connexion
Sur les casques multipoints, si la connexion à interrompre n'est pas la moins récente, les utilisateurs qui recherchent un switch audio peuvent indiquer au fournisseur quel appareil à ignorer à l'aide du message ci-dessous:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Switch audio | 0x07 |
1 | uint8 | Définir l'objectif de suppression de la connexion | 0x43 |
2 à 3 | uint16 | Longueur de données supplémentaire | 17 |
4 | uint8 | Cible de l'appareil connecté à supprimer | varie 1: cet appareil |
5 – 12 | Nonce du message | varie | |
13 – 20 | Code d'authentification du message | varie |
Tableau 4.3.4.3:Définir la cible de suppression de connexion
Implémentation de référence
Reportez-vous à la bibliothèque de SDK intégrés Nearby pour l'implémentation de référence.