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 दूरचा पक्ष पोहोचू शकेल असा पत्ता घेऊन जाते, आणि मीडिया पोर्टवर पॅकेट दोन्ही दिशांनी वाहत आहेत। यापैकी काही खोटे असल्यास समस्या बोगद्यात नाही। जो मार्ग अपयशी झाला तो दुरुस्त करा, नंतर बदल पुष्टी करण्यासाठी तेच कॅप्चर पुन्हा चालवा। आधीची आणि नंतरची कॅप्चर ठेवल्यास पुढील एकदिशीय अहवाल संपूर्ण दुपारऐवजी पाच मिनिटांची तपासणी होतो।