SIP कॉल VPN से रजिस्टर होती है पर ऑडियो क्यों नहीं भेजती
रजिस्ट्रेशन और ऑडियो अलग रास्ते लेते हैं। किसी एक कॉल को टनल से गुज़ारकर देखें कि PBX किन पतों का उपयोग कर सकता है और RTP वास्तव में कहाँ रुकता है।
सफल रजिस्ट्रेशन ऑडियो के बारे में लगभग कुछ नहीं बताता। एक सॉफ़्टफ़ोन घंटों तक दफ़्तर के PBX के साथ वैध बाइंडिंग रख सकता है और फिर भी ख़ामोशी ही भेज सकता है। टनल केवल वही पैकेट ले जाती है जो कोई जान-बूझकर उसमें भेजता है, और एक कॉल तीन अलग रास्ते इस्तेमाल करती है: बाइंडिंग, डायलॉग सेटअप और RTP स्ट्रीम। इन्हें अलग करते ही विफलता VPN शब्द पर नहीं, बल्कि एक रास्ते पर आ जाती है।
सोचिए, घर के Wi-Fi पर एक लैपटॉप मंज़ूरशुदा टनल से दफ़्तर का एक्सटेंशन डायल कर रहा है। PBX उपयोगकर्ता को प्रमाणित करता है, REGISTER स्वीकार करता है और एक्सटेंशन उपलब्ध दिखता है, फिर भी कॉल एक दिशा में पूरी ख़ामोशी के साथ जुड़ जाती है।
रजिस्ट्रेशन संपर्क बाँधता है, मीडिया रास्ता नहीं
REGISTER अनुरोध रजिस्ट्रार से कहता है कि वह एड्रेस-ऑफ़-रिकॉर्ड और एक या अधिक संपर्क URI के बीच मैपिंग रखे। वह मैपिंग इस संकीर्ण सवाल का जवाब देती है कि नया डायलॉग अभी कहाँ भेजा जाना चाहिए। यह मीडिया के स्थान के बारे में कुछ नहीं कहती, और स्वीकृत रजिस्ट्रेशन यह साबित नहीं करता कि बाद का INVITE कोई पहुँचने योग्य मीडिया पता ले जाता है। रजिस्ट्रेशन टाइमर पर समाप्त भी होते हैं, इसलिए जो फ़ोन रीफ़्रेश करना बंद कर देता है वह आने वाली कॉल खो देता है जबकि उसकी टनल अभी भी स्वस्थ दिखती है। टनल की स्थिति की जगह संपर्क की समाप्ति देखें।
जब सॉफ़्टफ़ोन टनल के पीछे होता है, तो संपर्क हेडर कोई निजी पता ले जा सकता है। जो PBX उसे किसी दूसरे एंडपॉइंट पर अग्रेषित करता है वह ऐसे नेटवर्क की ओर डायलॉग बनाता है जहाँ कॉल किया गया पक्ष पहुँच नहीं सकता। PJSIP एंडपॉइंट पर rewrite_contact=yes सेट करने से PBX अपने देखे गए स्रोत पते को बदल देता है, और अक्सर रिंग और टाइमआउट के बीच का फ़र्क़ यही होता है।
INVITE क्या प्रस्ताव देता है और कौन उसका उपयोग कर सकता है
SDP बॉडी वाला INVITE प्रस्तावित करता है कि कॉल करने वाला मीडिया कहाँ पाना चाहता है: एक पता, एक पोर्ट और कोडेक की सूची। कॉल किया गया पक्ष अपने पते और पोर्ट के साथ जवाब देता है, और फिर हर पक्ष दूसरे के प्रस्तावित स्थान पर RTP भेजता है। यदि कॉल करने वाले ने 192.168.x.x जैसा पता प्रस्तावित किया है जो केवल उसके घर के नेटवर्क में मौजूद है, तो सिग्नलिंग कितनी भी साफ़ हो, कॉल किए गए पक्ष के पास ऑडियो भेजने की जगह नहीं है। मास्करेडिंग राउटर छोड़ते समय पैकेट के IP हेडर फिर से लिखती है, पर SDP बॉडी के अंदर का पाठ कभी फिर से नहीं लिखती।
यही अंतराल पारंपरिक एकतरफ़ा कॉल समझाता है: सिग्नलिंग काम करती है क्योंकि दोनों एंडपॉइंट PBX तक पहुँचते हैं, और ऑडियो विफल होता है क्योंकि एक एंडपॉइंट को ऐसे पते पर भेजने को कहा गया था जो केवल किसी दूसरे NAT के पीछे मौजूद है।
| Path | Who picks the address | Typical failure |
|---|---|---|
| REGISTER | Softphone, rewritten by the registrar if configured | Binding expires or points at a private address |
| INVITE and SDP | Each endpoint in its own offer or answer | Offer names a media address nobody can route to |
| RTP | PBX relay policy or the two endpoints | Port range blocked, or no return path |
ऑडियो कौन ले जाता है, यह कॉन्फ़िगरेशन का चुनाव है
सिग्नलिंग और मीडिया अलग भूमिकाएँ हैं। एक प्रॉक्सी पूरी कॉल के दौरान सिग्नलिंग रास्ते पर रह सकता है और एक भी RTP पैकेट को नहीं छूता। PBX मीडिया रिले बनेगा या नहीं, यह टनल की मौजूदगी पर नहीं, कॉन्फ़िगरेशन पर निर्भर करता है।
सीधे मीडिया के साथ एंडपॉइंट स्वयं RTP का आदान-प्रदान करते हैं, जो एक LAN पर अच्छा काम करता है और तब ख़राब जब एक पक्ष सँकरी पोर्ट श्रेणी के पीछे हो।
direct_media=no सेट करने से PBX मीडिया रास्ते में आ जाता है ताकि दोनों टाँगें उसके नियंत्रित पते पर समाप्त हों, और यह अनुमानित एड्रेसिंग के बदले बैंडविड्थ व प्रोसेसर की अदला-बदली करता है। रिले करते समय PBX को फिर भी पहुँचने योग्य पता घोषित करना होता है। बहु-नेटवर्क होस्ट पर pjsip.conf में external_media_address और external_signaling_address तय करते हैं कि SDP में और Via हेडर में क्या दिखेगा। इन्हें अनसेट छोड़ें तो PBX अपना LAN पता ऐसे कॉल करने वाले को दे सकता है जिसका एकमात्र रास्ता टनल का दूर वाला सिरा है।
सेटिंग्स छूने से पहले हर दिशा को ट्रेस करें
कॉल चालू रहते PBX की सॉकेट तालिका से शुरू करें: ss -uanp | grep -E '5060|10000' दिखाता है कि RTP पोर्ट बँधे हैं या नहीं और कौन-सा स्थानीय पता इस्तेमाल करते हैं। यदि मीडिया श्रेणी में कुछ भी बँधा नहीं है, तो रिले सक्रिय नहीं है और एंडपॉइंट सीधे बात कर रहे हैं। फिर सॉफ़्टफ़ोन की ओर tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap से कैप्चर करें। आने वाले पैकेट बिना जाने वाले पैकेट समस्या को वापसी रास्ते तक या उस पते तक सीमित करते हैं जो दूर वाले पक्ष को इस्तेमाल करने को कहा गया था, और ख़ाली कैप्चर का अर्थ है कि मीडिया टनल इंटरफ़ेस तक कभी पहुँचा ही नहीं। sngrep से सिग्नलिंग कैप्चर दूसरे आधे का जवाब देता है और SDP कनेक्शन पंक्ति को भेजे गए रूप में दिखाता है।
उस कनेक्शन पंक्ति के पते की तुलना उस पते से करें जहाँ दूर वाला पक्ष वास्तव में रूट कर सकता है। यही एक तुलना अधिकांश एकतरफ़ा ऑडियो रिपोर्टों को किसी भी कॉन्फ़िगरेशन समीक्षा से तेज़ हल कर देती है।
एन्क्रिप्शन टनल के किनारे पर रुकता है
TLS पर SIP उस सिग्नलिंग हॉप की रक्षा करता है जिसके लिए वह कॉन्फ़िगर किया गया है, SRTP मीडिया की रक्षा करता है जब दोनों सिरे उस पर सहमत होते हैं, और टनल अपने एंडपॉइंट के बीच के ट्रैफ़िक की। इनमें से कोई भी बाक़ी की रक्षा नहीं देता। टनल के अंदर एन्क्रिप्टेड कॉल PBX की ओर गेटवे से सादे पाठ में निकल सकती है, और यह डिज़ाइन का निर्णय है, ख़राबी नहीं।
टिकट बंद करने से पहले तीन बातें क्रम से पुष्ट करें: रजिस्ट्रेशन ताज़ा है, SDP ऐसा पता ले जाता है जहाँ दूर वाला पक्ष पहुँच सके, और मीडिया पोर्ट पर पैकेट दोनों दिशाओं में बह रहे हैं। इनमें से कोई भी झूठा हो तो समस्या टनल में नहीं है। जो रास्ता विफल हुआ उसे ठीक करें, फिर बदलाव की पुष्टि के लिए वही कैप्चर दोबारा चलाएँ। पहले और बाद के कैप्चर रखने से अगली एकतरफ़ा रिपोर्ट पूरी दोपहर के बजाय पाँच मिनट की जाँच बन जाती है।