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 தொலைப் பக்கம் அடையக்கூடிய முகவரியைக் கொண்டுள்ளது, மீடியா துறைமுகங்களில் பாக்கெட்டுகள் இரு திசைகளிலும் பாய்கின்றன. இவற்றில் ஏதேனும் தவறானால் சிக்கல் சுரங்கப்பாதையில் இல்லை. தோல்வியடைந்த பாதையைச் சரிசெய்து, பின்னர் மாற்றத்தை உறுதிப்படுத்த அதே பிடிப்பை மீண்டும் இயக்குங்கள். முன் மற்றும் பின் பிடிப்புகளை வைத்திருந்தால் அடுத்த ஒரு-திசை அறிக்கை ஒரு முழு மதியத்திற்குப் பதிலாக ஐந்து நிமிட சரிபார்ப்பாகும்.