SMS

एक-तरफ़ा और दो-तरफ़ा SMS में क्या अंतर है?

एक-तरफ़ा SMS बिना जवाब स्वीकार किए संदेश भेजता है; दो-तरफ़ा SMS प्राप्तकर्ता से संदेश भी प्राप्त करता है।

सेंडर की बनावट तय करती है कि जवाबों के पास कोई पता है या नहीं। एक पात्र SMS नंबर संदेश प्राप्त कर सकता है; अल्फ़ान्यूमेरिक नाम नहीं कर सकता।

यह अंतर सुनने में ऐसा लगता है जैसे कोई फ़ीचर है जिसे आप चालू करते हैं। वास्तव में यह उस चीज़ की एक भौतिक विशेषता के करीब है जिससे आपने भेजा, और उस पर देश-विशिष्ट नीति की एक परत चढ़ी होती है।

सेंडर को एक-तरफ़ा क्या बनाता है?

उसके पीछे कोई पता न होना।

जवाब एक ऐसा संदेश है जो अंतिम भेजने वाले को संबोधित होता है। जहाँ सेंडर एक नंबर था, वह पता मौजूद है और हैंडसेट उसका उपयोग कर सकता है। जहाँ सेंडर एक अल्फ़ान्यूमेरिक सेंडर ID था, वहाँ संबोधित करने के लिए कोई नंबर नहीं है, और Bird का अपना मॉडल इस अनुपस्थिति को सीधे दर्ज करता है: ऐसे सेंडर का country code null होता है, जिसे "the country of the number this sender sends from" कहा गया है, और इसमें कोई number id नहीं होती क्योंकि "an alphanumeric sender has no number behind it"।

तो पहला विभाजन संरचनात्मक है। लॉन्ग कोड, टोल-फ़्री नंबर और शॉर्ट कोड प्राप्त कर सकते हैं। अल्फ़ान्यूमेरिक सेंडर नहीं कर सकता, किसी भी देश में, किसी भी रजिस्ट्रेशन के तहत।

दूसरा विभाजन देश के अनुसार होता है। किसी डेस्टिनेशन में उपलब्ध हर सेंडर टाइप one_way या two_way का एक direction रिपोर्ट करता है, इसलिए एक नंबर टाइप जो एक डेस्टिनेशन में जवाब ले सकता है, दूसरे में केवल-भेजने वाला हो सकता है। देश की SMS पॉलिसी का अपना is_two_way_supported फ़्लैग भी होता है। दोनों प्रति-डेस्टिनेशन मान हैं जो बदलते रहते हैं, इसलिए ये यहाँ सूचीबद्ध करने के बजाय SMS destinations पर प्रकाशित किए जाते हैं; हर डेस्टिनेशन पेज बताता है कि दो-तरफ़ा मैसेजिंग समर्थित है या नहीं।

जवाब मेरे ऐप्लिकेशन तक कैसे पहुँचता है?

एक इवेंट के रूप में, आपको पुश किया जाता है, और संदेश पहले से स्टोर हो चुका होता है।

जब कोई सब्सक्राइबर आपके किसी नंबर पर मैसेज करता है, तो Bird संदेश को आपके भेजे गए संदेशों के साथ स्टोर करता है और sms.received इमिट करता है। पेलोड में बॉडी, सेगमेंट ब्रेकडाउन, दोनों नंबर और ऑपरेटर शामिल होता है जहाँ कैरियर उसे रिपोर्ट करता है। पोल करने की कोई ज़रूरत नहीं है।

वह इवेंट आप तक पहुँचने से पहले एक चीज़ होती है, और यह बदलता है कि आपको हैंडलर में क्या करना चाहिए। Bird पहले उस नंबर के लिए कीवर्ड नियमों के अनुसार जवाब का मूल्यांकन करता है। एक समर्थित stop कीवर्ड एक सेंडर-और-सब्सक्राइबर सप्रेशन दर्ज करता है और ऑप्ट-आउट पुष्टि भेजता है, और फिर भी sms.received इमिट करता है। इसलिए एक इनबाउंड संदेश जो ऑप्ट-आउट था, आपके एंडपॉइंट पर किसी भी अन्य इनबाउंड संदेश जैसा ही दिखता है, लेकिन उस पर कार्रवाई पहले ही हो चुकी होती है।

आपके कोड के लिए इसका परिणाम: हर sms.received को बातचीत की एक बारी न मानें। उनमें से कुछ ऑप्ट-आउट हैं जिन्हें Bird पहले ही स्वीकार कर चुका है, और उनमें से किसी के जवाब में कुछ भी दोबारा भेजना वही गलती है जो यह पैटर्न आमंत्रित करता है। STOP कीवर्ड क्या है में बताया गया है कि कौन से कीवर्ड पहचाने जाते हैं, कहाँ, और कैटलॉग से बाहर के देश में क्या होता है।

मुझे किस सेंडर से जवाब देना चाहिए?

जिस नंबर पर व्यक्ति ने संपर्क किया उसे इस्तेमाल करें जब तक वह पात्र है, ताकि जवाब पहचानने योग्य रहे। आपका ऐप्लिकेशन सार्वजनिक SMS एंडपॉइंट के ज़रिए सामान्य सेंडर, डेस्टिनेशन और प्राप्तकर्ता जाँचों के साथ भेजता है।

Bird की बिल्ट-इन कीवर्ड पावतियों का एक अलग आंतरिक रिप्लाई कॉन्टेक्स्ट होता है। वह कॉन्टेक्स्ट ऐसा फ़ील्ड नहीं है जिस पर आपका API अनुरोध दावा कर सके। यह किसी बातचीत-आधारित प्रतिक्रिया या किसी कैंपेन को रजिस्ट्रेशन, डेस्टिनेशन एक्सेस या किसी व्यक्ति के ऑप्ट-आउट को बायपास करने की अनुमति नहीं देता।

जवाब देने से पहले, आने वाले संदेश को वर्गीकृत करें। STOP या सहायता अनुरोध को अपने लागू हैंडलिंग फ़्लो का पालन करना चाहिए, न कि किसी असंबंधित स्वचालित प्रतिक्रिया को ट्रिगर करना चाहिए। सेंडर आवश्यकताएँ और कीवर्ड हैंडलिंग संबंधित जाँचों का वर्णन करते हैं।

दो-तरफ़ा मैसेजिंग में ऐसा क्या खर्च होता है जो एक-तरफ़ा में नहीं?

चार चीज़ें, और जवाब स्वीकार करने के बाद इनमें से कोई भी वैकल्पिक नहीं है।

  1. एक ऐसा एंडपॉइंट जो इवेंट्स को विश्वसनीय रूप से सत्यापित और प्रोसेस करे। इनबाउंड पुश किया जाता है; फिर से प्रयास और डुप्लिकेट डिलीवरी को ध्यान में रखें। Webhook हैंडलिंग सिग्नेचर, फिर से प्रयास और रीप्ले को कवर करता है। इवेंट की पहचान webhook-id हेडर में होती है, बॉडी के बाहर। इसके मान को अपनी डीडुप्लिकेशन कुंजी के रूप में इस्तेमाल करें।
  2. हर उस डेस्टिनेशन में एक नंबर जहाँ ज़रूरत हो। अल्फ़ान्यूमेरिक सेंडर दो-तरफ़ा प्रोग्राम का हिस्सा नहीं हो सकता, इसलिए जो कैंपेन इन्हें मिलाता है उसे उन डेस्टिनेशन के लिए एक योजना चाहिए जहाँ केवल नाम उपलब्ध है। एक-तरफ़ा जाना भी दायित्व से बचने का रास्ता नहीं है: जो नियामक ढाँचा ऑप्ट-आउट का अधिकार देता है, वह एक-तरफ़ा सेंडर से यह बताने की माँग कर सकता है कि जवाब काम नहीं करते और एक वैकल्पिक रास्ता पेश करना होगा, जिसे TCPA क्या है में विस्तार से बताया गया है।
  3. उन संदेशों को संभालना जिनके लिए आपने डिज़ाइन नहीं किया। लोग नोटिफ़िकेशन का जवाब देते हैं। इनमें से कुछ जवाब सवाल होते हैं, कुछ ऑप्ट-आउट होते हैं, और कुछ इनमें से कुछ भी नहीं।
  4. अपने नंबरों की इनबाउंड साइड पढ़ना। Bird इनबाउंड वॉल्यूम को आउटबाउंड से अलग रिपोर्ट करता है, इसलिए दो-तरफ़ा प्रोग्राम में निगरानी के लिए नंबरों का एक दूसरा सेट होता है।

अगर इनमें से कुछ भी लागू नहीं होता, तो एक-तरफ़ा कोई डाउनग्रेड नहीं है। यह छोटी प्रतिबद्धता है, और अल्फ़ान्यूमेरिक सेंडर आपको उन डेस्टिनेशन में from फ़ील्ड में एक पहचानने योग्य नाम देता है जो इसे सपोर्ट करते हैं। मुझे कौन सा सेंडर टाइप इस्तेमाल करना चाहिए में पूरा तुलनात्मक विवरण है, और दो-तरफ़ा SMS में बताया गया है कि Bird रिप्लाई साइड के लिए क्या प्रदान करता है।

संक्षेप में

  1. एक-तरफ़ा सेंडर की एक विशेषता है, कोई सेटिंग नहीं।

    नाम के पीछे कोई पता नहीं होता, इसलिए उस पर कुछ वापस नहीं भेजा जा सकता। न्यूमेरिक सेंडर को फिर भी SMS क्षमता और एक इनबाउंड रूट चाहिए; अल्फ़ान्यूमेरिक सेंडर जवाब प्राप्त नहीं कर सकता।

  2. कोई गंतव्य किसी ऐसे प्रकार के लिए एक-तरफ़ा हो सकता है जिसे वह अन्यथा सपोर्ट करता है।

    हर सेंडर प्रकार जो किसी देश में उपलब्ध है, अपनी दिशा अलग से रिपोर्ट करता है, इसलिए एक ही नंबर प्रकार एक गंतव्य में दो-तरफ़ा और दूसरे में एक-तरफ़ा हो सकता है।

  3. जवाब एक इवेंट के रूप में आता है, पोल के रूप में नहीं।

    Bird इनबाउंड संदेश को स्टोर करता है और sms.received इमिट करता है जिसमें बॉडी, सेगमेंट ब्रेकडाउन, दोनों नंबर और ऑपरेटर शामिल होता है जब कैरियर उसे रिपोर्ट करता है।

  4. आपका API जवाब अपनी जाँच के साथ एक सेंड है।

    एक पात्र सेंडर का उपयोग करें और प्राप्तकर्ता के अनुरोध का सम्मान करें। आंतरिक कीवर्ड पावती आपके ऐप्लिकेशन को रजिस्ट्रेशन या सप्रेशन छूट नहीं देती।

व्यवहार में लाएँ।

इस विषय के लिए डॉक्यूमेंटेशन, गाइड और उदाहरणों के साथ आगे बढ़ें। संसाधन अंग्रेज़ी में हैं।

इम्प्लीमेंटेशन ब्रीफ़ पाएँ

उसी नेटवर्क पर बनाएँ।

एक टेस्ट API key आपको तुरंत मिल जाती है। भुगतान विधि जोड़ने और सेंडर सत्यापित करने पर प्रोडक्शन अनलॉक होता है।

आपका अगला आइडिया।
जुड़ने के लिए तैयार।