SOCKS प्रॉक्सी संदेश लोड कर सकता है पर कॉल पर विफल होता है
Dante और SOCKS5 की UDP आवश्यकताओं से समझाया गया है कि कार्यशील TCP पथ किसी ऐप के कॉल ट्रैफ़िक के लिए समर्थन क्यों सिद्ध नहीं करता।
टेक्स्ट संदेश SOCKS प्रॉक्सी से आते हैं, पर वॉइस कॉल कभी नहीं जुड़ती। प्रॉक्सी का पूरी तरह खराब होना ज़रूरी नहीं है। हो सकता है ऐप कॉल के लिए दूसरा ट्रांसपोर्ट इस्तेमाल करता हो।
सफल TCP अनुरोध उस क्रिया के लिए TCP पथ सिद्ध करता है। SOCKS5 भी UDP सहयोग परिभाषित करता है, पर क्लाइंट, SOCKS सेवा, नेटवर्क नियम और ऐप सेटिंग्स सभी को इच्छित UDP मार्ग का समर्थन करना होगा।
TCP श्रोता से अधिक कुछ है
Dante मैनुअल प्रोटोकॉल और कमांड नियमों को अलग करता है, जिनमें connect, udpassociate और udpreply शामिल हैं। जो नियम केवल पहले से परखे गए TCP कनेक्शन की अनुमति देता है, वह आवश्यक UDP अनुमतियाँ स्थापित नहीं करता।
UDP सहयोग में रिले एंडपॉइंट और वापसी ट्रैफ़िक भी शामिल है। फ़ायरवॉल और पता अनुवाद को उसी वास्तविक मार्ग की अनुमति देनी होगी। SOCKS के TCP श्रोता को खोलना उसके UDP रिले को पहुँच-योग्य बनाने के बराबर नहीं है।
ऐप के वर्तमान प्रॉक्सी दस्तावेज़ और सेटिंग्स जाँचें। अलग-अलग संस्करण संदेश, मीडिया और कॉल को अलग तरह से संभाल सकते हैं। पुराने क्लाइंट के लिए फ़ोरम की विधि को इस प्रमाण के रूप में प्रस्तुत नहीं करना चाहिए कि हर वर्तमान क्लाइंट कॉल SOCKS से भेजता है।
पहले निदान के रूप में हर UDP पोर्ट खोलने से बचें। रिले व्यवहार और इच्छित क्लाइंट दायरा निर्धारित करें, फिर उपयुक्त प्रतिबंधित नेटवर्क नीति लागू करें। इसी तरह, कॉल के लिए प्रॉक्सी सेटिंग बंद करने से कॉल सीधे भेजकर काम कर सकती है, जो प्रॉक्सी वाले मार्ग को ठीक करने के बजाय बाहरी मार्ग बदल देता है।
हर क्रिया के लिए सफलता दर्ज करें: संदेश, मीडिया स्थानांतरण और कॉल। एक कार्यशील अनुरोध या बदला हुआ ब्राउज़र IP यह सिद्ध नहीं कर सकता कि किसी दूसरे ऐप का हर हिस्सा वही प्रॉक्सी एग्ज़िट साझा करता है।