SIP ट्रंक क्या है, और क्या मुझे इसकी ज़रूरत है?

ट्रंक वह सीमा है जहाँ कैरियर तय करता है कि आपका उपकरण कौन-सी कॉल भेज और प्राप्त कर सकता है। अगर आपके पास PBX (आपकी कॉल रूट करने वाला बिज़नेस फ़ोन सिस्टम), सेशन बॉर्डर कंट्रोलर, कॉन्टैक्ट-सेंटर प्लेटफ़ॉर्म या कोई अन्य SIP क्लाइंट है, तो ट्रंक के ज़रिए ही उसकी कॉल बाहरी दुनिया तक पहुँचती हैं और बाहर की कॉल उस तक आती हैं। सेशन बॉर्डर कंट्रोलर वह उपकरण है जो वॉइस नेटवर्क के किनारे की सुरक्षा करता है।

पहला सवाल अक्सर यही होता है कि क्या आपको ट्रंक की ज़रूरत है भी, और इसका जवाब है हाँ। फ़र्क इस बात में होता है कि आप उसके पीछे क्या रखते हैं।

क्या मुझे सच में ट्रंक की ज़रूरत है?

हाँ। अलग-अलग सेटअप में फ़र्क आपकी ओर के क्लाइंट का होता है, ट्रंक के होने या न होने का नहीं।

टेलीफ़ोन नेटवर्क पर जाने वाली या वहाँ से आने वाली हर कॉल एक ट्रंक से होकर गुज़रती है, क्योंकि ट्रंक पर ही प्लैटफ़ॉर्म तय करता है कि कॉल स्वीकार की जाए या नहीं। दो रूप आम हैं:

• आपके पास फ़ोन सिस्टम है। PBX, सॉफ़्टस्विच या कॉन्टैक्ट-सेंटर प्लैटफ़ॉर्म, जो पहले से कॉल संभालता है और जिसे सार्वजनिक नेटवर्क तक रास्ता चाहिए। यह पीयर के रूप में जुड़ता है, आमतौर पर एक तय पते से, और कॉल नियंत्रण उसका अपना डायल प्लान करता है, यानी वे नियम जो उसकी कॉल रूट करते हैं।
• आपके पास ऐप्लिकेशन कोड है। आप चाहते हैं कि आपका सॉफ़्टवेयर टेलीफ़ोनी इन्फ़्रास्ट्रक्चर चलाए बिना कॉल करे या प्राप्त करे। तब भी आपको ट्रंक चाहिए, लेकिन उससे बात करने वाला हिस्सा छोटा हो सकता है: सॉफ़्टफ़ोन, ब्राउज़र, CLI या वॉइस एजेंट रनटाइम। यह किसी ज्ञात पते पर मौजूद उपकरण के बजाय कम समय तक मान्य सेशन क्रेडेंशियल से प्रमाणीकरण करता है, जो SIP क्लाइंट के लिए एक अस्थायी यूज़रनेम और पासवर्ड है।

यह फ़र्क इस बात का है कि कॉल नियंत्रण कहाँ होता है, पैमाने का नहीं, और कोई भी रूप ट्रंक को नहीं छोड़ता। हल्का क्लाइंट आपको फ़ोन सिस्टम चलाने से बचाता है, कनेक्शन से नहीं। Bird के अपने टूल भी यही दिखाते हैं: डैशबोर्ड का फ़ोन और CLI की टेस्ट कॉल, दोनों SIP क्लाइंट हैं जो आपके किसी ट्रंक से असली कॉल करते हैं।

ट्रंक API का विकल्प भी नहीं है, क्योंकि कोई भी एंडपॉइंट आपके चुने हुए गंतव्य पर कॉल नहीं करता। कॉन्फ़िगर करने वाला हिस्सा और सिग्नलिंग वाला हिस्सा काम कैसे बाँटते हैं, यह वॉइस API क्या है में बताया गया है।

ट्रंक असल में क्या करता है?

यह आपके उपकरण को कॉल भेजने के लिए एक पता देता है और तय करता है कि कौन-सी कॉल स्वीकार होंगी।

Bird हर ट्रंक को एक तय SIP डोमेन देता है। इसे आप अपने फ़ोन सिस्टम में दर्ज करते हैं, ताकि कॉल उस ट्रंक से जोड़ी जा सकें। आपका उपकरण इस डोमेन पर तीन में से किसी एक ट्रांसपोर्ट से भेजता है: 5060 पर UDP या TCP, या सिग्नलिंग को ट्रांज़िट में एन्क्रिप्ट करना हो तो 5061 पर TLS।

नया ट्रंक हर कॉल लौटा देता है। दोनों दिशाएँ बंद होती हैं और कोई भी भेजने वाला अधिकृत नहीं होता। यह जानबूझकर रखा गया डिफ़ॉल्ट है, अधूरा सेटअप नहीं। बनते ही कॉल स्वीकार करने वाला ट्रंक सबके लिए खुला न्योता होता, और टोल फ़्रॉड की वजह से यह जल्दी महँगा पड़ता है।

आउटबाउंड और इनबाउंड को अलग-अलग कॉन्फ़िगर क्यों किया जाता है?

क्योंकि ये दो अलग समस्याएँ हैं जो अलग-अलग तरह से विफल होती हैं, और ट्रंक हर दिशा को स्वतंत्र रूप से संभालता है।

आउटबाउंड का मतलब है कि आपका फ़ोन सिस्टम Bird के ज़रिए कॉल करता है। जब तक आप इसे चालू नहीं करते, ट्रंक क्रेडेंशियल की परवाह किए बिना हर आउटबाउंड प्रयास अस्वीकार करता है। इसलिए दिशा बंद हो, तो सही तरह से प्रमाणित कॉल भी विफल होती है।

इनबाउंड का मतलब है कि Bird ट्रंक की ओर पॉइंट किए गए नंबरों की कॉल आपके फ़ोन सिस्टम तक पहुँचाता है। सिर्फ़ इसे चालू करना काफ़ी नहीं है: जिस ट्रंक पर इनबाउंड चालू है पर कोई डिलीवरी गेटवे नहीं है, वह उसके नंबरों पर आने वाली हर कॉल अस्वीकार करता है। किसी नंबर को ट्रंक की ओर पॉइंट करने की सेटिंग ट्रंक पर नहीं, नंबर पर होती है। यही दूसरा हिस्सा अक्सर छूट जाता है।

इनबाउंड कॉलिंग बंद करने पर इस ट्रंक की ओर पॉइंट किया गया हर नंबर फिर से अस्वीकार पर चला जाता है, और इसे दोबारा चालू करने से वे बहाल नहीं होते। ट्रंक हटाने पर भी यही होता है। यानी इस बदलाव को उलटना सममित नहीं है: अगर आप कुछ जाँचने के लिए इनबाउंड बंद करते हैं, तो बाद में हर नंबर को फिर से पॉइंट करने की योजना बनाएँ। यह मानकर न चलें कि टॉगल ने उन्हें बहाल कर दिया है, नंबरों की जाँच करें।

ट्रंक कैसे तय करता है कि उसे कौन कॉल भेज सकता है?

यह IP अनुमति सूची, API कुंजी प्रमाणीकरण और सेशन क्रेडेंशियल तय करते हैं। इन्हें साथ में इस्तेमाल किया जा सकता है, और हर एक में पहली प्रविष्टि जुड़ते ही वह सक्रिय हो जाता है।

IP अनुमति सूची। वे सार्वजनिक पते जोड़ें जिनसे आपके उपकरण SIP भेजते हैं। सूची में एक प्रविष्टि आते ही फ़िल्टरिंग शुरू हो जाती है, और उसके बाद सिर्फ़ सूचीबद्ध रेंज से कॉल भेजी जा सकती हैं। NAT के पीछे वाले उपकरणों के लिए यह राउटर का सार्वजनिक पता है, फ़ोन सिस्टम का निजी पता नहीं। असूचीबद्ध पतों से आई कॉल SIP लेयर पर ही अस्वीकार हो जाती हैं और आमतौर पर कॉल लॉग तक नहीं पहुँचतीं। इसलिए खाली लॉग इसी का लक्षण है, इस बात का सबूत नहीं कि कोई प्रयास नहीं हुआ।

API कुंजी प्रमाणीकरण। Bird कॉल को चुनौती देता है, और आपका सिस्टम पासवर्ड के बजाय उसके हैश से जवाब देता है। यह हैश ऐसी Bird API कुंजी से सत्यापित होता है जिसके पास राइट स्तर पर वॉइस एक्सेस हो। आपके PBX में यूज़रनेम हमेशा bird होता है और पासवर्ड कुंजी का सीक्रेट होता है। IP सूची की तरह, एक कुंजी को अनुमति मिलते ही यह तरीका विशिष्ट हो जाता है।

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

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

सेशन क्रेडेंशियल चालू करने से अनुमति सूची वाले उपकरणों के कनेक्ट होने का तरीका नहीं बदलता। जिस ट्रंक पर कोई API कुंजी अनुमत नहीं है, उस पर सूचीबद्ध पते से आई कॉल अब भी बिना किसी पासवर्ड चुनौती के स्वीकार हो जाती है। अगर आप क्रेडेंशियल को ही रोक बनाना चाहते थे, तो असल में रोक अब भी चुपचाप IP सूची ही है।

मेरा ब्राउज़र या सॉफ्टफ़ोन ऑथेंटिकेट क्यों नहीं हो पाता?

लगभग हमेशा इसकी वजह डाइजेस्ट एल्गोरिदम होता है। यही एक सेटिंग है जिसकी विफलता क्रेडेंशियल की समस्या जैसी दिखती है।

डिफ़ॉल्ट रूप से Bird पहले SHA-256 और फिर MD5 ऑफ़र करता है, और आपका उपकरण इनमें से पहले समर्थित एल्गोरिदम से जवाब देता है। ट्रंक केवल वही एल्गोरिदम स्वीकार करता है जो वह ऑफ़र करता है, इसलिए ऑफ़र सीमित करने पर कनेक्ट हो सकने वाले क्लाइंट भी सीमित हो जाते हैं।

असली अड़चन ब्राउज़र हैं: ब्राउज़र केवल MD5 से जवाब देता है। केवल SHA-256 ऑफ़र करने वाला ट्रंक हर ब्राउज़र कॉल अस्वीकार करता है, जिसमें डैशबोर्ड का अपना फ़ोन भी शामिल है। इसलिए जिस भी ट्रंक पर आप ब्राउज़र से कॉल करना चाहते हैं, उसके ऑफ़र में MD5 रखें, और केवल-MD5 तभी चुनें जब कोई PBX SHA-256 से शुरू होने वाले चैलेंज को ठीक से न संभाल पाए। API कुंजियाँ दोनों एल्गोरिदम के साथ काम करती हैं, और ऑफ़र बदलने पर उन्हें दोबारा जारी करने की ज़रूरत नहीं होती।

तो मुझे क्या सेट अप करना चाहिए?

1. एक ट्रंक, आपका सेटअप जो भी हो। हर कॉल किसी ट्रंक से होकर गुज़रती है, इसलिए यह चरण वैकल्पिक नहीं है।
2. एक पीयर, अगर आप फ़ोन सिस्टम चलाते हैं। PBX या कॉन्टैक्ट-सेंटर प्लेटफ़ॉर्म को किसी निश्चित पते से कनेक्ट करें, और कॉल का नियंत्रण उसके डायल प्लान पर छोड़ें।
3. एक हल्का क्लाइंट, अगर आपके पास एप्लिकेशन कोड है। सॉफ्टफ़ोन, ब्राउज़र, CLI या एजेंट रनटाइम, जो किसी ज्ञात पते के बजाय अल्पकालिक सेशन क्रेडेंशियल से ऑथेंटिकेट होता है।
4. भेजने वाले के लिए एक नियम, आपने जो भी विकल्प चुना हो। IP अनुमति सूची, अनुमति प्राप्त API कुंजी या सेशन क्रेडेंशियल, यह ध्यान रखते हुए कि इनमें से हर एक में पहली प्रविष्टि जुड़ते ही वह विशिष्ट नियम बन जाता है।
5. डाइजेस्ट ऑफ़र में MD5 बनाए रखें, हर उस ट्रंक पर जिस पर आप ब्राउज़र से कॉल करना चाहते हैं।

SIP ट्रंक में हर सेटिंग और उसे ढूँढने की जगह बताई गई है। SIP क्लाइंट में फ़ोन सिस्टम के बजाय एक अकेले क्लाइंट को कनेक्ट करने का तरीका बताया गया है, और वॉइस समस्या निवारण में न पहुँचने वाली कॉल की जाँच चरण-दर-चरण की गई है।