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 ದೂರದ ಪಕ್ಷ ತಲುಪಬಹುದಾದ ವಿಳಾಸವನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಮಾಧ್ಯಮ ಪೋರ್ಟ್‌ಗಳಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳು ಎರಡೂ ದಿಕ್ಕಿನಲ್ಲಿ ಹರಿಯುತ್ತಿವೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಸುಳ್ಳಾಗಿದ್ದರೆ, ಸಮಸ್ಯೆ ಸುರಂಗದಲ್ಲಿಲ್ಲ. ವಿಫಲವಾದ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಿ, ನಂತರ ಬದಲಾವಣೆಯನ್ನು ದೃಢೀಕರಿಸಲು ಅದೇ ಸೆರೆಯನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ. ಹಿಂದಿನ ಮತ್ತು ನಂತರದ ಸೆರೆಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುವುದು ಮುಂದಿನ ಏಕಮುಖ ವರದಿಯನ್ನು ಪೂರ್ತಿ ಮಧ್ಯಾಹ್ನದ ಬದಲು ಐದು ನಿಮಿಷಗಳ ಪರಿಶೀಲನೆಯಾಗಿ ಮಾಡುತ್ತದೆ.