IP पर वॉइस कॉल एक चीज़ के प्रति सबसे ज़्यादा सेंसिटिव होती हैं: लेटेंसी। 200ms की देरी और आपकी बातचीत एक अजीब आगे-पीछे में बदल जाती है जहाँ दोनों लोग एक-दूसरे के ऊपर बोलते रहते हैं। इसीलिए SIP ट्रैफ़िक के लिए सही प्रॉक्सी चुनना लगभग किसी भी अन्य यूज़ केस से ज़्यादा ज़रूरी है।
सामान्य प्रॉक्सी क्यों काम नहीं करती
SIP कॉल्स में दो अलग-अलग स्ट्रीम शामिल होती हैं। सिग्नलिंग (कॉल सेटअप, रिंगिंग, हैंगअप) पोर्ट 5060 पर TCP या UDP के ज़रिए जाती है। असली वॉइस — वह ऑडियो जो आप सुनते हैं — डायनामिकली असाइन किए गए पोर्ट्स पर UDP के ज़रिए RTP पैकेट्स के रूप में ट्रैवल करती है।
HTTP या HTTPS प्रॉक्सी वेब ट्रैफ़िक हैंडल करती है। यह UDP को नहीं समझती और वॉइस पैकेट्स रिले नहीं कर सकती। अगर आप Zoiper या Linphone जैसे VoIP सॉफ़्टफ़ोन को HTTP प्रॉक्सी के ज़रिए रूट करने की कोशिश करते हैं, तो सिग्नलिंग आंशिक रूप से काम कर सकती है, लेकिन ऑडियो नहीं आएगा। कॉल कागज़ पर कनेक्ट होती है लेकिन साइलेंट रहती है।
SIP कॉल्स के लिए आपको ऐसा SIP प्रॉक्सी सर्वर चाहिए जो UDP रिले के साथ SOCKS5 सपोर्ट करता हो। यह प्रोटोकॉल सिग्नलिंग और वॉइस स्ट्रीम दोनों को प्रॉक्सी के ज़रिए टनल करता है, जिससे पूरी कॉल बरकरार रहती है।
UDP रिले के साथ SOCKS5 असल में क्या करता है
जब आपका सॉफ़्टफ़ोन या PBX — चाहे वह Asterisk हो, FreePBX हो, या Zoiper जैसा डेस्कटॉप क्लाइंट — UDP सपोर्ट वाली SOCKS5 प्रॉक्सी से रूट होता है, तो प्रॉक्सी दोनों लेयर्स हैंडल करती है:
- SIP सिग्नलिंग: INVITE, ACK, BYE — वे सभी मैसेज जो कॉल्स को सेटअप और टियर डाउन करते हैं
- RTP मीडिया: असली ऑडियो पैकेट जो दोनों दिशाओं में ट्रैवल करते हैं
प्रॉक्सी NAT की समस्याएँ भी हल करती है। SIP डायरेक्ट पीयर-टू-पीयर कम्युनिकेशन के लिए डिज़ाइन किया गया था, और यह सिग्नलिंग मैसेज में प्राइवेट IP एड्रेस एम्बेड करता है। NAT के पीछे ये एड्रेस बाहर से रीचेबल नहीं होते। SIP आउटबाउंड प्रॉक्सी कनेक्शन को रीराइट कर देती है ताकि दोनों साइड सामान्य रूप से ऑडियो एक्सचेंज कर सकें — कोई STUN सर्वर नहीं, कोई जटिल फ़ायरवॉल रूल नहीं।
यह कहाँ काम आता है
बॉर्डर पार ऑपरेट करने वाले कॉल सेंटर सबसे आम केस हैं। आपके एजेंट्स एक देश में हैं, आपके फ़ोन नंबर और SIP ट्रंक दूसरे देश में। नंबर के रीजन में प्रॉक्सी के ज़रिए कॉल रूट करने से लेटेंसी कम रहती है और ट्रैफ़िक प्रोवाइडर को लोकल दिखता है।
कई SIP ट्रंक चलाने वाले बिज़नेस को कभी-कभी प्रति ट्रंक एक अलग IP चाहिए — प्रोवाइडर ट्रैक करते हैं कि कौन से IP उनके सिस्टम से कनेक्ट होते हैं, और एक एड्रेस को कई ट्रंक में शेयर करना फ़्रॉड अलर्ट ट्रिगर कर सकता है। प्रति ट्रंक एक डेडिकेटेड प्रॉक्सी सब कुछ क्लीन रखती है।
VoIP ब्लॉक एक और केस है। कुछ नेटवर्क और देश SIP ट्रैफ़िक को पूरी तरह थ्रॉटल या ब्लॉक कर देते हैं। किसी अनरिस्ट्रिक्टेड लोकेशन पर प्रॉक्सी के ज़रिए रूट करने से यह बायपास हो जाता है — नेटवर्क को SIP पैकेट्स की जगह सामान्य एन्क्रिप्टेड ट्रैफ़िक दिखता है।
कॉल्स के लिए प्रॉक्सी में क्या देखें
लेटेंसी सबसे ज़रूरी है। वेब स्क्रैपिंग के लिए 500ms प्रति रिक्वेस्ट ठीक है। फ़ोन कॉल के लिए 150ms से ज़्यादा one-way डिले नोटिस होने लगती है। डेटासेंटर प्रॉक्सी यहाँ जीतती हैं — ये डेटा सेंटर्स में बैठती हैं जहाँ डायरेक्ट रूट्स और मिनिमम हॉप्स होते हैं। रेजिडेंशियल या मोबाइल प्रॉक्सी एक्स्ट्रा रिले पॉइंट्स जोड़ती हैं जिससे डिले बढ़ती है।
स्टेबिलिटी भी उतनी ही मायने रखती है। स्क्रैपिंग के दौरान आधे सेकंड के लिए कनेक्शन ड्रॉप होना कोई बड़ी बात नहीं — स्क्रिप्ट रिट्राई कर लेगी। कॉल के बीच में, यह एक ड्रॉप्ड कॉल है। रिलायबल इंफ्रास्ट्रक्चर पर स्टेटिक IP इससे बचाते हैं।
FineProxy पूर्ण SOCKS5 विद UDP रिले ऑफ़र करता है — सिग्नलिंग और वॉइस दोनों एक ही कनेक्शन से गुज़रते हैं। डेटासेंटर इंफ्रास्ट्रक्चर का मतलब है कम लेटेंसी, और स्टेटिक IP पूरे रेंटल पीरियड भर एक जैसा बना रहता है। जिन सेटअप्स को सिग्नलिंग लेयर पर एन्क्रिप्शन चाहिए, उनके लिए हमारी HTTPS प्रॉक्सी प्रति IP अलग SSL सर्टिफ़िकेट के साथ यह काम भी संभालती हैं।