सफल दर्ताले अडियोबारे लगभग केही बताउँदैन। सफ्टफोन घण्टौंसम्म कार्यालयको 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 पछाडि मात्र रहेको ठेगानामा पठाउन भनिएको थियो।

PathWho picks the addressTypical failure
REGISTERSoftphone, rewritten by the registrar if configuredBinding expires or points at a private address
INVITE and SDPEach endpoint in its own offer or answerOffer names a media address nobody can route to
RTPPBX relay policy or the two endpointsPort 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 ले टाढाको पक्ष पुग्न सक्ने ठेगाना बोक्छ, र मिडिया पोर्टमा प्याकेट दुवै दिशामा बगिरहेका छन्। यीमध्ये कुनै झुटो भए समस्या सुरुङमा छैन। असफल भएको बाटो सुधार्नुहोस्, त्यसपछि परिवर्तन पुष्टि गर्न त्यही क्याप्चर फेरि चलाउनुहोस्। अघिल्लो र पछिल्लो क्याप्चर राख्दा अर्को एकतर्फी रिपोर्ट पूरा दिउँसोको सट्टा पाँच मिनेटको जाँच बन्छ।

सम्बन्धित लेखहरू