Fast Pair | Google for Developers

इस पेज का अनुवाद Cloud Translation API से किया गया है.

ऑडियो स्विच

उपयोगकर्ता अपने रोज़मर्रा के कामों के लिए, ऑडियो सोर्स वाले कई डिवाइसों का इस्तेमाल कर रहे हैं. इसलिए, सभी डिवाइसों पर हेडसेट के इस्तेमाल को मैनेज करने के लिए, आसान समाधान की मांग बढ़ रही है. ऑडियो स्विच की सुविधा, उपयोगकर्ता की गतिविधि (जैसे, कोई फ़िल्म शुरू करना) और प्राथमिकता वाले इवेंट (जैसे, कोई इनकमिंग कॉल) के आधार पर, डिवाइसों के बीच हेडसेट के कनेक्शन को आसानी से ट्रांसफ़र करती है.

यूएक्स के सिद्धांत

कनेक्शन स्विच करने की प्रोसेस तेज़ होनी चाहिए और यह उपयोगकर्ता की कार्रवाई पर आधारित होनी चाहिए.
कनेक्शन स्विच करने की जानकारी उपयोगकर्ताओं को साफ़ तौर पर दी जानी चाहिए, ताकि वे स्विच करने की प्रक्रिया को कंट्रोल कर सकें या उसे पहले जैसा कर सकें.
खाता स्विच करने की सुविधा, उपयोगकर्ता की निजता का ध्यान रखनी चाहिए.

भूमिकाएं

ऑडियो स्विच करने वाला डिवाइस: यह डिवाइस, ऑडियो सोर्स डिवाइस (उदाहरण के लिए, फ़ोन या टैबलेट) होता है. यह आस-पास मौजूद हेडसेट को कनेक्ट करने की कोशिश करता है.

ऑडियो स्विच करने की सुविधा देने वाली कंपनी: आम तौर पर, यह सुविधा देने वाली कंपनी हेडसेट होती है. यह हेडसेट, सर्च करने वाले लोगों को अपनी मौजूदगी और कनेक्शन की स्थिति के बारे में बताता है, ताकि वे स्विच करने का फ़ैसला ले सकें.

ज़रूरी शर्तों के बारे में खास जानकारी

स्मार्ट स्विचिंग की सुविधा पाने के लिए, सेवा देने वाली कंपनियों को ये शर्तें पूरी करनी होंगी:

नाम	ब्यौरा	ज़रूरी शर्तें	क्या यह ज़रूरी है?
पेज स्कैन करना	किसी मौजूदा कनेक्शन के होने पर, किसी दूसरे सर्चर से नए कनेक्शन का अनुरोध स्वीकार करने के लिए. एक ही पॉइंट पर सेवा देने वाली कंपनियों के लिए: जब सेवा देने वाली कंपनी का कनेक्शन बंद हो रहा होगा, तब ओरिजनल सोर्स डिवाइस पर ऑडियो अपने-आप रुक जाएगा. मल्टीपॉइंट सेवा देने वाली कंपनियों के लिए: अगर कोई कनेक्शन उपलब्ध है, तो वह कनेक्शन का अनुरोध स्वीकार कर लेगा. अगर कनेक्शन की बैंडविड्थ पूरी हो गई है, तो हाल ही में इस्तेमाल नहीं किए गए कनेक्शन को डिसकनेक्ट करें.उदाहरण के लिए, लंबे समय से कोई ऑडियो इवेंट न होना. इसके बाद, आने वाले नए अनुरोध को स्वीकार करें.	परफ़ॉर्मेंस को बेहतर बनाने के लिए, कम इंतज़ार वाला पेज स्कैन मोड (स्कैन इंटरवल 640 एमएस से ज़्यादा नहीं होना चाहिए) ज़रूरी है. बैटरी लाइफ़ और स्विच करने की परफ़ॉर्मेंस के बीच समझौता करने के लिए, प्रोवाइडर के पास ज़्यादातर मामलों में डिफ़ॉल्ट पेज स्कैन मोड (कम पावर मोड, स्कैन इंटरवल 1280 एमएस से ज़्यादा नहीं होना चाहिए) हो सकता है. हालांकि, लो-लेटेंसी मोड का इस्तेमाल इन स्थितियों में किया जाना चाहिए: डिवाइस चालू होने के शुरुआती 30 सेकंड शुरुआती 30 सेकंड में कोई कनेक्शन या पेजिंग नहीं डिवाइस के कुछ समय के लिए इस्तेमाल न होने के शुरुआती 30 सेकंड	ज़रूरी है
कनेक्शन का इतिहास	पिछले कनेक्शन पर वापस स्विच करने और लागू होने पर, वीडियो चलाना फिर से शुरू करने के लिए. Message Stream API के ज़रिए होने वाली कम्यूनिकेशन से, पिछले कनेक्शन पर स्विच करने की सुविधा ट्रिगर होगी. अगर लागू हो, तो वीडियो चलाना फिर से शुरू करने के लिए, ऑडियो को रोकने वाले इवेंट को रिकॉर्ड में शामिल करना चाहिए.	कनेक्शन का इतिहास बनाए रखना और Message Stream API लागू करना.	ज़रूरी है
कनेक्शन स्थिति	कनेक्शन स्विच करने का फ़ैसला लेने के लिए, खोज करने वाले लोगों के लिए.कनेक्शन की स्थिति में ये शामिल हैं: कनेक्शन की स्थिति चालू कनेक्शन का ऑडियो टाइप ऐक्टिव कनेक्शन का खाता कनेक्ट किए गए डिवाइस	BLE विज्ञापन और मैसेज स्ट्रीम में कनेक्शन की स्थिति शामिल करें.	ज़रूरी है
रनटाइम की सुविधाओं में बदलाव	ऑडियो स्विच को चालू करने के लिए, प्रोवाइडर पर फ़र्मवेयर को अपग्रेड करना होगा. इसलिए, रनटाइम के दौरान, रिकवरी के लिए इस्तेमाल होने वाले डिवाइस और प्रोवाइडर के बीच सुविधाओं को सिंक करना ज़रूरी है.	रनटाइम की सुविधाओं को ऐक्सेस करने के लिए, Message Stream API लागू करें.	ज़रूरी है
स्विच करने के लिए कॉन्फ़िगर किए जा सकने वाले नियम	उपयोगकर्ता की प्राथमिकता सेटिंग की मदद से, Seeker को मौजूदा ऑडियो स्ट्रीमिंग और नए ऑडियो स्ट्रीमिंग अनुरोधों के बीच प्राथमिकता कॉन्फ़िगर करने दें. उदाहरण के लिए, ऑडियो स्विच करने वाला Seeker, यूज़र इंटरफ़ेस (यूआई) सेटिंग दे सकता है, ताकि उपयोगकर्ता मीडिया स्ट्रीमिंग और कॉल करने के बीच अपने-आप स्विच करने की सुविधा को चालू/बंद कर सकें. ऑडियो स्विच करने की सुविधा, मैसेज स्ट्रीम की मदद से स्विच करने का नियम सेट करेगी और उसे लागू करेगी.	सिर्फ़ एक से ज़्यादा पॉइंट की सेवा देने वाली कंपनियों के लिए. कनेक्ट किए गए डिवाइसों के बीच स्विच करने के नियमों को कॉन्फ़िगर करने के लिए, Message Stream API लागू करें.	वैकल्पिक
ऐक्टिव डिवाइस स्विच करना	ऑडियो स्विच करने वाले डिवाइसों के बीच ऑडियो स्विच करने की सुविधा को सिम्युलेट करने दें. ऑडियो स्विच करने वाले डिवाइसों के लिए, उपयोगकर्ताओं के पास कनेक्ट किए गए डिवाइसों के बीच आसानी से स्विच करने के लिए यूज़र इंटरफ़ेस (यूआई) हो सकता है.	सिर्फ़ एक से ज़्यादा डिवाइसों को कनेक्ट करने की सुविधा देने वाली कंपनियों के लिए. कनेक्ट किए गए डिवाइसों में से चालू ऑडियो सोर्स का पता लगाने के लिए, ऑडियो स्विच करने वाले डिवाइस के लिए Message Stream API लागू करें.	ज़रूरी है
मल्टीपॉइंट स्विच करने की सूचना	ऑडियो स्विच करने की सुविधा, स्विच करने की सूचना दिखाए.	सिर्फ़ मल्टीपॉइंट सेवा देने वाली कंपनियों के लिए. मल्टीपॉइंट स्विचिंग के दौरान, कनेक्ट किए गए ऑडियो स्विच करने वाले डिवाइसों को सूचना देने के लिए, मैसेज स्ट्रीम एपीआई लागू करें.	ज़रूरी है

विज्ञापन पेलोड

सेवा देने वाली कंपनी, विज्ञापन में अपने कनेक्शन की मौजूदा स्थिति शामिल करेगी. यह जानकारी, विज्ञापन: जब डिवाइस ढूंढा न जा सके में बताए गए फ़ास्ट पेयर खाते के डेटा के आधार पर दी जाएगी.

ध्यान दें कि टेबल 4.2 का वर्शन 0x1 है.

कनेक्शन स्टेटस फ़ील्ड

ऑक्टेट	डेटा टाइप	ब्यौरा	मान	क्या यह ज़रूरी है?
0	`uint8`	फ़ील्ड की लंबाई और टाइप 0bLLLLTTTT L = कनेक्शन स्टेटस की लंबाई, बाइट में T = टाइप	0bLLLL0101 लंबाई: अलग-अलग होती है type = 0b0101	ज़रूरी है
1	`uint8`	कनेक्शन की स्थिति 0bHAFRSSSS H = सिर की पहचान करने की सुविधा A = कनेक्शन की उपलब्धता F = फ़ोकस मोड R = अपने-आप कनेक्ट हो गया S = कनेक्शन की स्थिति	0bHAFRSSSS 0bHAFR के लिए, कनेक्शन फ़्लैग देखें 0bSSSS के लिए, कनेक्शन का स्टेटस देखें	ज़रूरी है
2	`uint8`	कस्टम डेटा फ़िलहाल, इसमें सिर्फ़ कॉन्टेंट टाइप शामिल होता है. इसका इस्तेमाल, मौजूदा ऑडियो स्ट्रीमिंग के इस्तेमाल के बारे में बताने के लिए किया जाता है. इसके बाद, खोज करने वाला व्यक्ति इसे सेवा देने वाली कंपनी को भेजेगा.	यह वैल्यू, मौजूदा स्ट्रीमिंग के सीकर से मैसेज स्ट्रीम के ज़रिए प्रोवाइडर को भेजी जाती है. अगर मौजूदा स्ट्रीमिंग, Seeker से नहीं की जा रही है, तो 0.	ज़रूरी है
3 - var		कनेक्ट किए गए डिवाइसों का बिटमैप यह बिटमैप दिखाता है कि फ़िलहाल कौनसे डिवाइस, सेवा देने वाली कंपनी से कनेक्ट हैं. सभी बॉन्डेड डिवाइसों को क्रम से लगाया जाता है. एक बॉन्डेड डिवाइस के लिए एक बिट. यह अवधि इस बात पर निर्भर करेगी कि सेवा देने वाली कंपनी के कितने बॉन्डेड डिवाइस हैं.	अगर डिवाइस फ़िलहाल सेवा देने वाली कंपनी से कनेक्ट है, तो मैप किया गया बिट 1 पर सेट होता है. अगर डिवाइस सेवा देने वाली कंपनी से कनेक्ट नहीं है, तो यह बिट 0 पर सेट होता है. ज़्यादा जानकारी के लिए, कनेक्ट किए गए डिवाइस का बिटमैप देखें	वैकल्पिक

टेबल 4.1: कनेक्शन स्टेटस फ़ील्ड का रॉ डेटा

कनेक्शन के फ़्लैग

0bH = स्मार्टवॉच के सिर पर होने का पता लगाने की सुविधा
- 1, अब हेड पर
- 0, अगर हेड पर नहीं है या ओएचडी सेंसर नहीं है
0bA = कनेक्शन की उपलब्धता
- 1, कोई कनेक्शन उपलब्ध है
- 0, अन्य मामलों में
0bF = फ़ोकस मोड
- 1, फ़ोकस मोड में अब मीडिया इस्तेमाल करने के लिए, कनेक्शन स्विच करने की अनुमति नहीं है. इसका मतलब है कि A2DP से A2DP पर स्विच नहीं किया जा सकता
- 0, अन्य मामलों में
0bR = अपने-आप कनेक्ट हो गया
- 1, अगर मौजूदा कनेक्शन को सेवा देने वाली कंपनी अपने-आप फिर से कनेक्ट करती है, इसका मतलब है कि इसे उपयोगकर्ताओं ने कनेक्ट नहीं किया है. मल्टीपॉइंट के लिए, अगर मौजूदा कनेक्शन में से कोई एक कनेक्शन अपने-आप फिर से कनेक्ट होता है, तो उसे 1 पर सेट किया जाना चाहिए
- 0, अन्य मामलों में

कनेक्शन की स्थिति

0x0: कोई कनेक्शन नहीं है
0x1: पेजिंग
0x2: कनेक्ट है, लेकिन डेटा ट्रांसफ़र नहीं हो रहा
0x3: ऑडियो के अलावा अन्य डेटा ट्रांसफ़र करना (सिर्फ़ तब जब स्विच किया जा सकता हो. अगर नहीं, तो 0xF का इस्तेमाल करें)
0x4: A2DP स्ट्रीमिंग, AVRCP लागू नहीं
0x5: A2DP स्ट्रीमिंग और AVRCP प्लेबैक
0x6: HFP (फ़ोन/वीओआईपी कॉल) स्ट्रीमिंग. इसमें इनबैंड और नॉन-इनबैंड रिंगटोन भी शामिल हैं
0x7: LE ऑडियो - कंट्रोल के बिना मीडिया स्ट्रीमिंग
0x8: LE audio - कंट्रोल के साथ मीडिया स्ट्रीमिंग
0x9: LE audio - कॉल स्ट्रीमिंग
0xA: LE audio - ब्रॉडकास्ट
0xF: कनेक्शन स्विच को कुछ समय के लिए बंद करना (जैसे, फ़र्मवेयर अपडेट)

LE Audio कॉन्टेक्स्ट टाइप और कनेक्शन की स्थिति

सुझाव दें कि LE Audio की सेवा देने वाली कंपनी, असाइन किए गए नंबर 6.12.3 में बताए गए सभी कॉन्टेक्स्ट टाइप को मैनेज करे. ऐसा तब तक करना चाहिए, जब तक कि कंपनी साफ़ तौर पर किसी कॉन्टेक्स्ट टाइप के साथ काम नहीं करती. साथ ही, कॉन्टेक्स्ट टाइप को कनेक्शन की स्थिति के साथ मैप करें, जैसा कि यहां बताया गया है.

बातचीत वाली सुविधा: 0x9
मीडिया: 0x8
गेम: 0x7
निर्देश देने वाले वीडियो: 0x7
वॉइस असिस्टेंट: 0x9
लाइव: 0x9
साउंड इफ़ेक्ट: 0x2
सूचनाएं: 0x2
रिंगटोन: 0x9
सूचनाएं: 0x7
आपातकालीन अलार्म: 0x9

कॉल के दौरान मीडिया चलाने जैसे, LE Audio के अलग-अलग कॉन्टेक्स्ट टाइप के लिए, प्रोवाइडर को कनेक्शन की स्थिति का इस्तेमाल सबसे ज़्यादा प्राथमिकता के साथ करना चाहिए. इसका मतलब है कि ऊपर बताई गई स्थिति के लिए, 0x8 (मीडिया) के बजाय 0x9 (कॉल) का इस्तेमाल करना चाहिए.

कनेक्ट किए गए डिवाइस का बिटमैप

अनचाहे कनेक्शन स्विच करने से बचने के लिए, हो सकता है कि खोजने वाले को यह पता हो कि हैडसेट फ़िलहाल किस डिवाइस से कनेक्ट है. उदाहरण के लिए, जब हेडसेट फ़ोन से कनेक्ट होता है, तो उपयोगकर्ता को अपने फ़ैमिली ग्रुप के किसी सदस्य के टैबलेट पर YouTube चलाने पर, कनेक्टिविटी स्विच होने से रुकावट नहीं चाहिए.

ध्यान दें कि यह बिटमैप बिना नाम वाला होता है. इससे, खोज करने वाले को यह पता नहीं चलता कि सेवा देने वाली कंपनी के साथ कौनसे अन्य डिवाइस बंधे हुए हैं. उदाहरण के लिए, पांच बॉन्डेड डिवाइसों के लिए:

0: लैपटॉप (0bx0000000)
1: phoneA (0b0x000000)
2: phoneB (0b00x00000)
3: टैबलेट (0b000x0000)
4: टीवी (0b0000x000)

अगर कनेक्ट किए गए मौजूदा डिवाइसों में एक लैपटॉप और एक टैबलेट है, तो बिटमैप की वैल्यू 0b10010000 होगी. क्रम में बदलाव तब किया जा सकता है, जब ऐसा करना ज़रूरी हो. उदाहरण के लिए, जब उपयोगकर्ता हेडसेट को फ़ैक्ट्री रीसेट करते हैं या जब बंधे हुए डिवाइसों की संख्या तय सीमा तक पहुंच जाती है.

रैंडम रीज़ॉल्वेबल विज्ञापन

उपयोगकर्ता की निजता को सुरक्षित रखने और उसे ट्रैक होने से बचाने के लिए, प्रोवाइडर को एईएस-सीटीआर का इस्तेमाल करके, खाते की कुंजी के हिसाब से फ़ील्ड को घुमाना और एन्क्रिप्ट करना चाहिए:

 encrypted_connection_status_field = connection_status_raw_data ^ AES(Key, IV)

कहां

कुंजी, इस्तेमाल में मौजूद खाता कुंजी से ली जाती है, जिसे अगले सेक्शन में बताया गया है.
- कुंजी, HKDF फ़ंक्शन, IETF RFC 5869 की मदद से जनरेट की जाती है. इसके लिए, SHA-256 हैश फ़ंक्शन का इस्तेमाल किया जाता है.
```
  Key = HKDF(account_key, NULL, UTF8("SASS-RRD-KEY"),16)
```
- यहां प्रोवाइडर, खाते की मूल कुंजी का इस्तेमाल करेगा. इसका मतलब है कि कुंजी का पहला बाइट 0x04 है, जिसे इस्तेमाल पैटर्न में शामिल नहीं किया गया है.
IV (शुरुआती वेक्टर), खाता कुंजी डेटा का दो बाइट का सॉल्ट होता है.इसमें शून्य पैडिंग होती है. इसका मतलब है कि IV, concat(salt, 14-byte ZEROs) होता है.
कनेक्शन स्टेटस का रॉ डेटा टेबल 4.1 में बताया गया है. अगर कनेक्शन स्टेटस बदलता है, तो विज्ञापन के लिए तय की गई समयसीमा के दौरान, नमक और आरपीए को फिर से जनरेट किया जाना चाहिए.

इससे, एन्क्रिप्ट (सुरक्षित) किए गए कनेक्शन का स्टेटस फ़ील्ड, खाता कुंजी के डेटा के साथ ही घूमता है.

बीएलई विज्ञापन इस तरह से तैयार किया जाएगा:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान	क्या यह ज़रूरी है?
0	`uint8`	वर्शन और फ़्लैग	0x10	ज़रूरी है
1 - t		खाता कुंजी का डेटा	अलग-अलग होता है	ज़रूरी है
t+1 - s		बैटरी का डेटा	अलग-अलग होता है	वैकल्पिक
s+1 - var		रैंडम डेटा, जिसे हल किया जा सकता है	अलग-अलग होता है	अगर खाता कुंजी की सूची खाली नहीं है, तो यह एट्रिब्यूट ज़रूरी है. अन्यथा, इसे बाहर रखा जाता है.

टेबल 4.2: रैंडम रीज़ॉल्व किए जा सकने वाले डेटा के साथ BLE विज्ञापन

रैंडम रीज़ॉल्व किए जा सकने वाले डेटा में ये शामिल हैं:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान	क्या यह ज़रूरी है?
0	`uint8`	फ़ील्ड की लंबाई और टाइप 0bLLLLTTTT L = एन्क्रिप्ट (सुरक्षित) किए गए डेटा की लंबाई T = टाइप	0bLLLL0110 length: अलग-अलग होती है type = 0b0110	ज़रूरी है
1 - var		एन्क्रिप्ट (सुरक्षित) किया गया डेटा	अलग-अलग होता है	ज़रूरी है

टेबल 4.2.1: ऐसा डेटा जिसे अलग-अलग उपयोगकर्ताओं के लिए अलग-अलग तरीके से दिखाया जा सकता है

उदाहरण के लिए, अगर रैंडम रीज़ॉल्व किए जा सकने वाले डेटा में एन्क्रिप्ट किया गया कनेक्शन स्टेटस फ़ील्ड शामिल है, तो डिक्रिप्ट किया गया नतीजा, कनेक्शन स्टेटस फ़ील्ड होगा.

छेड़छाड़ को रोकने के लिए, विज्ञापन में रैंडम तरीके से हल किया जा सकने वाला डेटा शामिल करने पर, ऊपर दिए गए खाता कुंजी डेटा में थोड़ा बदलाव किया जाना चाहिए. आम तौर पर, खाता कुंजी फ़िल्टर बनाते समय, खाता कुंजी फ़िल्टर को सॉल्ट के साथ जोड़कर वैल्यू V बनाई जाती है. इसके बजाय, जब रैंडम रीज़ॉल्व किए जा सकने वाले डेटा का भी विज्ञापन किया जा रहा हो, तो वैल्यू V को इस तरह बनाया जाना चाहिए:

 V = concat(account_key, salt, random_resolvable_data)

अगर बैटरी डेटा और रैंडम रीज़ॉल्व किए जा सकने वाले डेटा, दोनों का विज्ञापन किया जा रहा है, तो V को इस तरह से बनाया जाना चाहिए:

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

इस्तेमाल में है खाता कुंजी

कनेक्शन स्विच करने की सुविधा, खाते पर आधारित होती है. इसलिए, सेवा देने वाली कंपनी को बीएलई विज्ञापन में मौजूदा कनेक्शन के खाते की जानकारी शामिल करनी चाहिए. अगर कनेक्ट किया गया मौजूदा डिवाइस, ऑडियो स्विच करने वाला सीकर है, तो सेवा देने वाली कंपनी के पास इस सीकर से जुड़ी खाता कुंजी होनी चाहिए. साथ ही, कनेक्शन की स्थिति वाले फ़ील्ड को एन्क्रिप्ट करने के लिए, इस खाता कुंजी का इस्तेमाल करना चाहिए. अगर कनेक्ट किया गया ऑडियो सोर्स, ऑडियो स्विच करने वाला सर्च इंजन नहीं है, तो प्रोवाइडर को हाल ही में इस्तेमाल की गई खाता कुंजी का इस्तेमाल करना चाहिए.

खाता कुंजी फ़िल्टर का हिसाब लगाने से पहले, प्रोवाइडर को खाता कुंजियों के पहले बाइट में बदलाव करना चाहिए, ताकि इस्तेमाल के पैटर्न में इनमें से कोई एक शामिल किया जा सके:

0b00000100
यह खाता कुंजी इस्तेमाल में नहीं है.
यह डिफ़ॉल्ट तौर पर सेट होता है (खाता कुंजी देखें).
0b00000101
यह खाता कुंजी, हाल ही में इस्तेमाल की गई खाता कुंजी है.
कनेक्शन स्टेटस फ़ील्ड को इस खाता कुंजी से एन्क्रिप्ट किया जाता है. मौजूदा कनेक्शन की स्थिति के बारे में खाता कुंजी की कोई जानकारी नहीं है. इसका मतलब यह हो सकता है कि कोई डिवाइस कनेक्ट न हो या कनेक्ट किया गया डिवाइस, ऑडियो स्विच करने वाला डिवाइस न हो.
0b00000110
यह खाता कुंजी, इस्तेमाल में मौजूद खाता कुंजी है.
कनेक्शन की स्थिति वाले फ़ील्ड को इस खाता कुंजी से एन्क्रिप्ट किया जाता है. साथ ही, फ़िलहाल जो डिवाइस कनेक्ट है वह इस खाता कुंजी से जुड़ा होता है.

ऑडियो स्विच पेलोड के लिए स्कीमैटिक

नीचे दिए गए इलस्ट्रेशन में, ऑडियो स्विच पेलोड का स्कीमैटिक दिखाया गया है.

मैसेज

कनेक्ट होने पर, सर्च करने वाला और प्रोवाइडर, ऑडियो स्विच करने की सुविधा को सिंक करने, कनेक्शन स्विच करने की सुविधा को ट्रिगर करने, स्विच करने की प्राथमिकता सेट करने और पाने, कनेक्शन की स्थिति की सूचना देने वगैरह के लिए, मैसेज स्ट्रीम का इस्तेमाल कर सकते हैं. हम ऑडियो स्विच के लिए, मैसेज ग्रुप और मैसेज कोड बनाते हैं. इनकी जानकारी यहां दी गई है.

मैसेज ग्रुप का नाम	मान
ऑडियो स्विच	0x07

हर मैसेज कोड के बारे में ज़्यादा जानकारी, यहां दिए गए सेक्शन में दी गई है.

मैसेज कोड का नाम	मान	सिर्फ़ मल्टीपॉइंट	प्रेषक	Responder	एन्क्रिप्ट करें	MAC	ACK
ऑडियो स्विच करने की सुविधा पाना	0x10	नहीं	दोनों	दोनों, कोड 0x11 के ज़रिए	नहीं	नहीं	नहीं
ऑडियो स्विच करने की सुविधा के बारे में सूचना पाने की सुविधा	0x11	नहीं	दोनों	दोनों	नहीं	हां	Y
मल्टीपॉइंट स्टेटस सेट करना	0x12	Y	सीकर	सेवा देने वाली कंपनी	नहीं	हां	Y
स्विच करने की प्राथमिकता सेट करना	0x20	Y	सीकर	सेवा देने वाली कंपनी	नहीं	हां	Y
स्विच करने की प्राथमिकता पाना	0x21	Y	सीकर	सेवा देने वाली कंपनी, कोड 0x22 के ज़रिए	नहीं	नहीं	नहीं
सूचना पाने की प्राथमिकता बदलने पर सूचना पाना	0x22	Y	सेवा देने वाली कंपनी	सीकर	नहीं	नहीं	नहीं
ऑडियो के चालू स्रोत को कनेक्ट किए गए डिवाइस पर स्विच करना	0x30	Y	सीकर	सेवा देने वाली कंपनी	नहीं	हां	Y
वापस स्विच करना	0x31	नहीं	सीकर	सेवा देने वाली कंपनी	नहीं	हां	Y
मल्टीपॉइंट स्विच इवेंट की सूचना देना	0x32	Y	सेवा देने वाली कंपनी	सीकर	नहीं	नहीं	नहीं
कनेक्शन की स्थिति पाना	0x33	Y	सीकर	सेवा देने वाली कंपनी, कोड 0x34 के ज़रिए	नहीं	नहीं	नहीं
कनेक्शन की स्थिति की सूचना पाना	0x34	Y	सेवा देने वाली कंपनी	सीकर	Y	नहीं	नहीं
ऑडियो स्विच करने की सुविधा से कनेक्ट होने की सूचना पाना	0x40	नहीं	सीकर	सेवा देने वाली कंपनी	नहीं	हां	Y
इस्तेमाल में है खाता कुंजी की जानकारी देना	0x41	नहीं	सीकर	सेवा देने वाली कंपनी	नहीं	हां	Y
कस्टम डेटा भेजना	0x42	नहीं	सीकर	सेवा देने वाली कंपनी	नहीं	हां	Y
कनेक्शन ड्रॉप होने का टारगेट सेट करना	0x43	Y	सीकर	सेवा देने वाली कंपनी	नहीं	हां	Y

टेबल 4.3: ऑडियो स्विच करने के मैसेज

ऑडियो स्विच मैसेज का एमएसी

मैसेज की पुष्टि करने के लिए, मैसेज की पुष्टि करने वाले कोड की ज़रूरत होती है. यह कोड, सर्च करने वाले से सेवा देने वाले को भेजे गए अतिरिक्त डेटा वाले सभी ऑडियो स्विच मैसेज के लिए ज़रूरी है. जब मैसेज के साथ एमएसी मिलता है, तो उसे स्वीकार किया जाना चाहिए, ताकि खोज करने वाले को पता चल सके कि सेवा देने वाली कंपनी ने मैसेज पर प्रतिक्रिया दी है या नहीं.

अगर मैसेज की पुष्टि हो जाती है, तो सेवा देने वाली कंपनी मैसेज के लिए ACK भेजेगी:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	स्वीकार है	0xFF
1	uint8	ACK	0x01
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	अलग-अलग होता है
4	uint8	ऑडियो स्विच	0x07
5	uint8	ऑडियो स्विच करने के लिए मैसेज का कोड	अलग-अलग होता है
6 - s		अतिरिक्त डेटा	अलग-अलग होता है

अगर ऐसा नहीं होता है, तो सेवा देने वाली कंपनी उस मैसेज के लिए एनएके भेजेगी:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	स्वीकार है	0xFF
1	uint8	NAK	0x02
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	0x0003
4	uint8	गड़बड़ी का कारण	अलग-अलग होता है
5	uint8	ऑडियो स्विच	0x07
6	uint8	ऑडियो स्विच करने के लिए मैसेज का कोड	अलग-अलग होता है

ध्यान दें कि अगर सेवा देने वाली कंपनी ही मैसेज भेजने वाली है, तो एमएसी की ज़रूरत नहीं है.

ऑडियो स्विच करने की सुविधा पाना

ऑडियो स्विच की सुविधा देने वाली कंपनी और Seeker, दोनों यह देख सकते हैं कि कनेक्ट किया गया Fast Pair Seeker/Provider, ऑडियो स्विच की सुविधा के साथ काम करता है या नहीं. इसके लिए, वे नीचे दिए गए मैसेज का इस्तेमाल कर सकते हैं:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	ऑडियो स्विच करने की सुविधा पाना	0x10
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	0

टेबल 4.3.1.0: ऑडियो स्विच करने की सुविधा पाना

ऑडियो स्विच करने की सुविधा के बारे में सूचना देने की सुविधा

ऑडियो स्विच की सुविधा पाएं मैसेज कोड पाने पर, ऑडियो स्विच के लिए अनुरोध करने वाला/देने वाला, इनमें से किसी एक फ़्लैग के साथ जवाब देगा:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	ऑडियो स्विच करने की सुविधा के बारे में सूचना देने की सुविधा	0x11
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	अगर यह अनुरोध, खोज करने वाले ने भेजा है, तो 20 अगर यह अनुरोध, सेवा देने वाली कंपनी ने भेजा है, तो 4
4 - 5	uint16	ऑडियो स्विच के वर्शन का कोड	शून्य से ज़्यादा वैल्यू का मतलब है कि यह ऑडियो स्विच की सुविधा के साथ काम करती है. सुरक्षा को बेहतर बनाने के लिए किए गए बदलावों के साथ, मौजूदा वर्शन का कोड 0x0102 है. 0x0000 या एक सेकंड में कोई जवाब न मिलने का मतलब है कि इस डिवाइस पर ऑडियो स्विच की सुविधा काम नहीं करती
6 - 7	फ़्लैग	सेवा देने वाली कंपनी के ऑडियो स्विच करने की सुविधा के फ़्लैग अगर यह जानकारी, दर्शक से भेजी जाती है, तो इन दो बाइट को अनदेखा किया जाना चाहिए.	अलग-अलग होता है ऑडियो स्विच करने की सुविधा के फ़्लैग देखें
8 - 15		मैसेज का नॉन्स इसकी ज़रूरत सिर्फ़ तब होती है, जब यह अनुरोध करने वाले व्यक्ति से भेजा गया हो	अलग-अलग होता है
16 से 23		मैसेज की पुष्टि करने वाला कोड यह सिर्फ़ तब ज़रूरी है, जब यह अनुरोध करने वाले व्यक्ति ने भेजा हो	अलग-अलग होता है

टेबल 4.3.1.1: ऑडियो स्विच की सूचना देने की सुविधा

ऑडियो स्विच करने की सुविधा के फ़्लैग

बिट 0 (ऑक्टेट 6, एमएसबी): ऑडियो स्विच की स्थिति
- 1, अगर ऑडियो स्विच की सुविधा चालू है
- 0, अन्य मामलों में
बिट 1: मल्टीपॉइंट कॉन्फ़िगरेशन
- 1, अगर डिवाइस में मल्टीपॉइंट की सुविधा काम करती है और इसे चालू और बंद किया जा सकता है
- 0, इसके अलावा (मल्टीपॉइंट की सुविधा काम नहीं करती या मल्टीपॉइंट हमेशा चालू रहता है)
बिट 2: मल्टीपॉइंट की मौजूदा स्थिति
- 1, अगर मल्टीपॉइंट की सुविधा चालू है
- 0, अन्य मामलों में
तीसरा बिट: स्मार्टवॉच के पहने होने का पता लगाना
- 1, अगर इस डिवाइस पर हेडफ़ोन पहने होने का पता लगाने की सुविधा काम करती है (भले ही, हेडफ़ोन पहने होने का पता लगाने की सुविधा अब बंद हो)
- 0, अन्य मामलों में
चौथा बिट: हेड पर डिवाइस होने का पता चलने की सुविधा की मौजूदा स्थिति
- 1, अगर हेडफ़ोन पहने होने का पता लगाने की सुविधा चालू है
- 0, अगर ऐसा नहीं है, तो (सिर पर हेडसेट होने का पता लगाने की सुविधा काम नहीं करती या यह सुविधा बंद है)
बाकी सभी बिट रिज़र्व हैं और डिफ़ॉल्ट रूप से 0 पर सेट होते हैं.

मल्टीपॉइंट की स्थिति सेट करना

ऑडियो स्विच करने वाले डिवाइसों पर, हम उपयोगकर्ताओं को मल्टीपॉइंट की सुविधा को चालू/बंद करने की सेटिंग दे सकते हैं. सीकर, नीचे दिए गए मैसेज का इस्तेमाल करके, प्रोवाइडर के लिए मल्टीपॉइंट स्टेटस सेट करेगा:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	मल्टीपॉइंट की स्थिति सेट करना	0x12
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	17
4	uint8	मल्टीपॉइंट की स्थिति	0: मल्टीपॉइंट की सुविधा बंद करें 1: मल्टीपॉइंट की सुविधा चालू करें
5 से 12		मैसेज का नॉन्स	अलग-अलग होता है
13 से 20		मैसेज की पुष्टि करने वाला कोड	अलग-अलग होता है

टेबल 4.3.1.2: मल्टीपॉइंट स्टेटस सेट करना

स्विच करने की प्राथमिकता सेट करना

ऑडियो स्विच करने वाले लोग, मल्टीपॉइंट की स्विच करने की प्राथमिकता में बदलाव कर सकते हैं. साथ ही, नीचे दिए गए मैसेज का इस्तेमाल करके, इसे प्रोवाइडर पर सेट कर सकते हैं:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	स्विच करने की प्राथमिकता सेट करना	0x20
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	18
4	फ़्लैग	प्राथमिकता बदलना	अलग-अलग होता है मल्टीपॉइंट स्विच करने की प्राथमिकता का फ़्लैग देखें
5		स्विच करने की बेहतर सेटिंग यह बाइट रिज़र्व है, डिफ़ॉल्ट वैल्यू 0 है	अलग-अलग होता है
6 से 13		मैसेज का नॉन्स	अलग-अलग होता है
14 से 21		मैसेज की पुष्टि करने वाला कोड	अलग-अलग होता है

टेबल 4.3.2.0: स्विच करने की प्राथमिकता सेट करना

मल्टीपॉइंट स्विचिंग की प्राथमिकता का फ़्लैग

बिट 0 (एमएसबी): A2DP बनाम A2DP (डिफ़ॉल्ट 0)
बिट 1: HFP बनाम HFP (डिफ़ॉल्ट 0)
बिट 2: A2DP बनाम HFP (डिफ़ॉल्ट 0)
तीसरा बिट: एचएफ़पी बनाम ए2डीपी (डिफ़ॉल्ट तौर पर 1)
बिट 4 से 7: रिज़र्व किए गए
ऊपर "नई प्रोफ़ाइल का अनुरोध" बनाम "मौजूदा चालू प्रोफ़ाइल" के तौर पर दिखाया गया है
- स्विच न करने के लिए 0
- स्विच करने के लिए 1

स्विच करने की प्राथमिकता पाना

ऑडियो स्विच करने की सुविधा पाने वाले लोग, नीचे दिए गए मैसेज का इस्तेमाल करके, प्रोवाइडर से मल्टीपॉइंट स्विच करने की प्राथमिकता के बारे में क्वेरी कर सकते हैं:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	स्विच करने का कॉन्फ़िगरेशन पाना	0x21
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	0

टेबल 4.3.2.1: स्विच करने की प्राथमिकता पाना

स्विच करने की प्राथमिकता की सूचना देना

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	स्विच करने की प्राथमिकता की सूचना देना	0x22
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	2
4	फ़्लैग	प्राथमिकता फ़्लैग स्विच करना	अलग-अलग होता है मल्टीपॉइंट स्विच करने की प्राथमिकता का फ़्लैग देखें
5		स्विच करने की बेहतर सेटिंग यह बाइट रिज़र्व है, डिफ़ॉल्ट वैल्यू 0 होनी चाहिए	अलग-अलग होता है

टेबल 4.3.2.2: स्विच करने की प्राथमिकता की सूचना दें

चालू ऑडियो सोर्स को कनेक्ट किए गए डिवाइस पर स्विच करना

ऑडियो स्विच करने की सुविधा पाने वाले लोग, मल्टीपॉइंट सेवा देने वाली कंपनी से, कनेक्ट किए गए डिवाइसों के बीच चालू ऑडियो सोर्स को स्विच करने का अनुरोध कर सकते हैं. इसके लिए, उन्हें नीचे दिए गए मैसेज का इस्तेमाल करना होगा:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	चालू ऑडियो सोर्स को कनेक्ट किए गए डिवाइस पर स्विच करना	0x30
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	17
4	फ़्लैग	ऑडियो सोर्स के चालू होने के इवेंट फ़्लैग स्विच करना	अलग-अलग होता है चालू ऑडियो सोर्स को स्विच करने का इवेंट देखें
5 से 12		मैसेज का नॉन्स	अलग-अलग होता है
13 से 20		मैसेज की पुष्टि करने वाला कोड	अलग-अलग होता है

टेबल 4.3.3.0: ऑडियो का चालू स्रोत (कनेक्ट किए गए डिवाइस पर) स्विच करना

ऑडियो के चालू सोर्स को स्विच करने का इवेंट

बिट 0 (एमएसबी): 1 इस डिवाइस पर स्विच करें, 0 दूसरे कनेक्ट किए गए डिवाइस पर स्विच करें
बिट 1: 1 का मतलब है कि डिवाइस बदलने के बाद, वीडियो चलाना जारी रहेगा. 0 का मतलब है कि वीडियो नहीं चलेगा. वीडियो चलाना फिर से शुरू करने का मतलब है कि प्रोवाइडर, AVRCP प्रोफ़ाइल के ज़रिए, खोज करने वाले को 'चलाएं' सूचना भेजता है. अगर स्विच करने से पहले, डिवाइस की पिछली स्थिति 'चल रहा है' नहीं थी, तो सेवा देने वाली कंपनी को इस फ़्लैग को अनदेखा करना चाहिए.
बिट 2: 1 का मतलब है कि डिवाइस से कनेक्ट हटाने पर एससीओ को अस्वीकार किया गया है. 0 का मतलब है कि ऐसा नहीं किया गया
तीसरा बिट: 1 का मतलब है कि स्विच किए गए डिवाइस से ब्लूटूथ डिसकनेक्ट हो जाएगा. 0 का मतलब है कि ऐसा नहीं होगा.
बिट 4 से 7: रिज़र्व.

हो सकता है कि ऑडियो स्विच करने वाले लोग हमेशा अपनी स्थिति के बारे में सही से न जानते हों. इसलिए, हो सकता है कि डिवाइस उपलब्ध कराने वाले व्यक्ति को "इस डिवाइस पर स्विच करें" मैसेज तब मिले, जब डिवाइस उपलब्ध कराने वाले व्यक्ति का डिवाइस पहले से ही ऐक्टिव हो. इस मामले में, Seeker पर सही यूज़र इंटरफ़ेस (यूआई) दिखाने के लिए, प्रोवाइडर गड़बड़ी की वजह के साथ NAK भेज सकता है. गड़बड़ी की वजह 0x4 - डिवाइस की ग़ैर-ज़रूरी कार्रवाई है.

अगर LE Audio की सुविधा देने वाली कंपनी के पास एक से ज़्यादा सेट में शामिल डिवाइस हैं, तो उसे सभी डिवाइसों को Seeker से डिसकनेक्ट करना चाहिए. ऐसा न करने पर, Seeker का ब्लूटूथ स्टैक, सेवा देने वाली कंपनी के डिवाइस से फिर से कनेक्ट हो जाएगा.

डिसकनेक्ट किए गए डिवाइस पर वापस स्विच करना

अगर कनेक्शन स्विच करना ज़रूरी नहीं है, तो उपयोगकर्ता इसे पहले जैसा कर सकते हैं. साथ ही, कुछ मामलों में, रुकावट को कम करने के लिए ऑडियो कनेक्शन को पहले जैसा करना सही होता है. खोजने वाला व्यक्ति, स्विच करने की सुविधा को ट्रिगर करने के लिए, नीचे दिए गए मैसेज का इस्तेमाल करेगा:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	डिसकनेक्ट किए गए डिवाइस पर वापस स्विच करना	0x31
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	17
4	uint8	इवेंट पर वापस जाना	अलग-अलग होता है 0x01: वापस स्विच करें 0x02: वापस स्विच करें और वीडियो चलाना फिर से शुरू करें
5 से 12		मैसेज का नॉन्स	अलग-अलग होता है
13 से 20		मैसेज की पुष्टि करने वाला कोड	अलग-अलग होता है

टेबल 4.3.3.1: डिसकनेक्ट किए गए डिवाइस पर वापस स्विच करना

मल्टीपॉइंट सेवा देने वाली कंपनियों के लिए, कनेक्शन स्विच करने के लिए, सेवा देने वाली कंपनी किसी एक ऑडियो सोर्स डिवाइस से कनेक्शन हटा सकती है और दूसरे ऑडियो सोर्स पर ऑडियो सेशन रोक सकती है. उदाहरण के लिए, मान लें कि मल्टीपॉइंट हेडसेट, टैबलेट और ऑडियो स्विच करने की सुविधा वाले तीसरे डिवाइस से कनेक्ट है. उपयोगकर्ता टैबलेट पर वीडियो देख रहा है, तभी उसके फ़ोन पर कॉल आता है. फ़ोन, हेडसेट पर कनेक्शन स्विच को ट्रिगर करेगा. फ़ोन से कनेक्ट करने के लिए, हेडसेट को तीसरे डिवाइस से डिसकनेक्ट करना होगा. साथ ही, फ़ोन से रिंगटोन पाने के लिए, टैबलेट पर मीडिया सेशन को रोकना होगा. अगर उपयोगकर्ता कॉल स्वीकार नहीं करता है, तो फ़ोन हेडसेट से "वापस स्विच करें और चलाना फिर से शुरू करें" कह सकता है. यह अनुरोध मिलने पर, हेडसेट को तीसरे डिवाइस से फिर से कनेक्ट करना होगा और टैबलेट पर रोके गए वीडियो को फिर से चलाना होगा.

मल्टीपॉइंट स्विच करने के इवेंट की सूचना देना

ऑडियो स्विच करने वाले डिवाइस के बीच स्विच करने के इवेंट के बारे में उपयोगकर्ताओं को बताने के लिए, ऑडियो स्विच करने वाला डिवाइस, उपयोगकर्ताओं को सूचना दिखा सकता है. प्रोवाइडर को कनेक्ट किए गए ऑडियो स्विच करने वाले डिवाइसों को, स्विच करने के इवेंट के बारे में सूचना देनी चाहिए.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	मल्टीपॉइंट-स्विच इवेंट की सूचना दें प्रोवाइडर को इसे हर स्विच पर भेजना चाहिए. इसमें, ऑडियो स्विच करने वाले डिवाइस से न करने वाले डिवाइस पर स्विच करने, न करने वाले डिवाइस से ऑडियो स्विच करने वाले डिवाइस पर स्विच करने, और ऑडियो स्विच करने वाले डिवाइस से ऑडियो स्विच करने वाले डिवाइस पर स्विच करने की जानकारी शामिल है	0x32
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	अलग-अलग होता है
4	uint8	स्विच करने की वजह यह वैल्यू, कनेक्शन की स्थिति के आधार पर तय की जानी चाहिए. LE Audio के इस्तेमाल के उदाहरणों के लिए, LE Audio कॉन्टेक्स्ट टाइप और कनेक्शन की स्थिति के बीच की मैपिंग देखना मददगार हो सकता है. उदाहरण के लिए, वॉइस असिस्टेंट की कनेक्शन की स्थिति 0x9(LE ऑडियो - कॉल स्ट्रीमिंग) है. इसलिए, वॉइस असिस्टेंट की मदद से स्विच करने की वजह 0x02 होनी चाहिए.	अलग-अलग 0x00: कोई जानकारी नहीं दी गई 0x01: मीडिया (उदाहरण के लिए, A2DP स्ट्रीमिंग, LEA मीडिया स्ट्रीमिंग) 0x02: कॉल (उदाहरण के लिए, एचएफ़पी स्ट्रीमिंग, LEA कॉल स्ट्रीमिंग)
5	uint8	टारगेट किया गया डिवाइस	अलग-अलग होता है 0x01: यह डिवाइस 0x02: कनेक्ट किया गया कोई दूसरा डिवाइस
6 - n	utf8	टारगेट डिवाइस का नाम अगर टारगेट डिवाइस ऑडियो स्विच सर्चर है, तो उस नाम का इस्तेमाल करें जिसे सर्चर ने भेजा है. अगर ऐसा नहीं है, तो बीटी नाम का इस्तेमाल करें. अगर यह भी लागू नहीं होता है, तो उसके पते के आखिरी दो बाइट का इस्तेमाल करें	अलग-अलग होता है

टेबल 4.3.3.2: मल्टीपॉइंट-स्विच इवेंट की सूचना देना

कनेक्शन की स्थिति देखना

सेवा देने वाली कंपनी से, सेवा पाने वाला व्यक्ति कनेक्शन की मौजूदा स्थिति जान सकता है:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	कनेक्शन की स्थिति देखना	0x33
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	0

टेबल 4.3.3.3: कनेक्शन की स्थिति पाना

यह मैसेज मिलने पर, सेवा देने वाली कंपनी को मैसेज कोड 0x34 से जवाब देना होगा. इसमें कनेक्शन की स्थिति की सूचना दी जाएगी.

कनेक्शन की स्थिति की सूचना देना

BLE विज्ञापन पेलोड में बताए गए मुताबिक, अगर कई पॉइंट वाले प्रोवाइडर के लिए, विज्ञापन पैकेट में बदलाव के अलावा कनेक्शन की स्थिति में बदलाव होता है, तो प्रोवाइडर को उसी खाता कुंजी का इस्तेमाल करने वाले कनेक्ट किए गए सीकर को भी इस बदलाव की सूचना देनी चाहिए. अगर सेवा देने वाली कंपनी, ऑडियो स्विच करने वाले और न करने वाले दोनों तरह के सीकर से कनेक्ट है और न करने वाले सीकर चालू है, तो सेवा देने वाली कंपनी को कनेक्ट किए गए ऑडियो स्विच करने वाले सीकर को भी कनेक्शन की स्थिति की सूचना देनी चाहिए. इसके लिए, उसे सीकर की खाता कुंजी का इस्तेमाल करना होगा.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	कनेक्शन की स्थिति की सूचना देना	0x34
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	अलग-अलग होता है
4	uint8	ऐक्टिव डिवाइस फ़्लैग	अलग-अलग होता है 0x00: यह Seeker पैसिव है और ऐक्टिव डिवाइस, उसी खाता कुंजी का इस्तेमाल कर रहा है 0x01: यह Seeker ऐक्टिव डिवाइस है 0x02: यह Seeker पैसिव है और ऐक्टिव डिवाइस, ऑडियो स्विच करने वाला Seeker नहीं है.
5 - n		एन्क्रिप्ट किए गए कनेक्शन की स्थिति	अलग-अलग होता है
n+1 - n+8		मैसेज का नॉन्स	अलग-अलग होता है

टेबल 4.3.3.4: कनेक्शन की स्थिति की सूचना देना

एन्क्रिप्ट किए गए कनेक्शन की स्थिति का मैसेज

 encrypted_connection_status = connection_status_raw_data ^ AES(Key, IV)

कहां:

यह कुंजी, इस्तेमाल में मौजूद खाते की कुंजी से ली जाती है. ज़्यादा जानकारी के लिए, रैंडम रीज़ॉल्व किए जा सकने वाले विज्ञापन देखें.
```
 Key = HKDF(account_key, NULL, UTF8("SASS-RRD-KEY"),16)
```
IV is concat(Session_nonce, Message_nonce)
connection_status_raw_data = concat(connection_state, custom_data, connected_devices), जिसे BLE में परिभाषित किया गया है विज्ञापन पेलोड ध्यान दें कि फ़ील्ड की लंबाई और टाइप के लिए बाइट शामिल नहीं किया जाना चाहिए, क्योंकि हमारे पास मैसेज कोड और डेटा की लंबाई है.

ऑडियो स्विच करने की सुविधा से कनेक्ट होने की सूचना

ऑडियो स्विच करने की सुविधा देने वाली कंपनियों को यह जानना पड़ सकता है कि कनेक्शन स्विच करने की सुविधा, ऑडियो स्विच करने की वजह से ट्रिगर हुई है या नहीं.इससे उन्हें अलग-अलग प्रतिक्रियाएं देने में मदद मिलती है. जैसे, ऑडियो स्विच करने के इवेंट के लिए, ईयरकंस बंद करना. सीकर, सेवा देने वाली कंपनी को यह सूचना देने के लिए मैसेज भेजता है कि यह कनेक्टिविटी, ऑडियो स्विच की वजह से शुरू हुई थी.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	ऑडियो स्विच करने की सुविधा से कनेक्ट होने की सूचना पाना	0x40
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	17
4	uint8	ऑडियो स्विच करने पर, कनेक्शन के शुरू होने का संकेत	अलग-अलग होता है 0: यह कनेक्शन, ऑडियो स्विच की वजह से ट्रिगर नहीं हुआ था 1: यह कनेक्शन, ऑडियो स्विच की वजह से शुरू हुआ था
5 से 12		मैसेज का नॉन्स	अलग-अलग होता है
13 से 20		मैसेज की पुष्टि करने वाला कोड	अलग-अलग होता है

टेबल 4.3.4.0: ऑडियो स्विच की सुविधा से शुरू किए गए कनेक्शन की सूचना देना

खाते की कुंजी के इस्तेमाल की जानकारी

अगर खोज करने वाले व्यक्ति के पास एक से ज़्यादा खाता कुंजियां (उदाहरण के लिए, कई उपयोगकर्ता) हैं, तो वे कुंजियां, सेवा देने वाली कंपनी से जुड़ी होंगी. ऐसे में, खोज करने वाला व्यक्ति नीचे दिए गए मैसेज का इस्तेमाल करके यह बताएगा कि कौनसी खाता कुंजी इस्तेमाल की जा रही है.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	खाते की कुंजी के इस्तेमाल की जानकारी	0x41
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	22
4 - 9	utf8	इस्तेमाल में है स्ट्रिंग	UTF8 ("इस्तेमाल में है")
10 - 17		मैसेज का नॉन्स	अलग-अलग होता है
18 से 25 साल		मैसेज की पुष्टि करने वाला कोड	अलग-अलग होता है

टेबल 4.3.4.1: खाते की कुंजी के इस्तेमाल की जानकारी

यह मैसेज मिलने पर, पुष्टि करने वाले मैसेज के कोड की पुष्टि करके, सेवा देने वाली कंपनी यह जान सकती है कि कौनसी खाता कुंजी इस्तेमाल की जा रही है.

कस्टम डेटा भेजना

ऑडियो स्विच करने वाला सक्रिय सर्च इंजन, ऑडियो स्ट्रीम की जानकारी (जैसे, ऑडियो का इस्तेमाल) को कस्टम डेटा बाइट में शामिल कर सकता है. साथ ही, नीचे दिए गए मैसेज का इस्तेमाल करके, उसे प्रोवाइडर को भेज सकता है:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	कस्टम डेटा भेजना	0x42
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	17
4	uint8	कस्टम डेटा	अलग-अलग होता है
5 से 12		मैसेज का नॉन्स	अलग-अलग होता है
13 से 20		मैसेज की पुष्टि करने वाला कोड	अलग-अलग होता है

टेबल 4.3.4.2: कस्टम डेटा भेजना

कस्टम डेटा मिलने के बाद, डेटा उपलब्ध कराने वाली कंपनी, कस्टम डेटा को शामिल करने के लिए विज्ञापन पैकेट को अपडेट करेगी. मल्टीपॉइंट प्रोवाइडर के लिए, यह उसी खाता कुंजी का इस्तेमाल करके, कनेक्ट किए गए किसी दूसरे सीकर को कनेक्टिविटी की स्थिति में हुए बदलाव की सूचना भी देनी चाहिए.

ड्रॉप कनेक्शन टारगेट सेट करना

मल्टीपॉइंट हेडसेट पर, अगर सबसे हाल ही में इस्तेमाल किया गया कनेक्टिविटी डिवाइस नहीं छोड़ा जाना है, तो ऑडियो स्विच करने वाले लोग, सेवा देने वाली कंपनी को बता सकते हैं कि किस डिवाइस को छोड़ना है. इसके लिए, उन्हें नीचे दिए गए मैसेज का इस्तेमाल करना होगा:

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
0	uint8	ऑडियो स्विच	0x07
1	uint8	ड्रॉप कनेक्शन टारगेट सेट करना	0x43
2 - 3	uint16	अतिरिक्त डेटा की लंबाई	17
4	uint8	टारगेट किया गया कनेक्ट किया गया डिवाइस हटाया जाएगा	अलग-अलग 1: यह डिवाइस
5 से 12		मैसेज का नॉन्स	अलग-अलग होता है
13 से 20		मैसेज की पुष्टि करने वाला कोड	अलग-अलग होता है

टेबल 4.3.4.3: ड्रॉप कनेक्शन टारगेट सेट करना