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 ਦੂਰਲੇ ਪੱਖ ਦੀ ਪਹੁੰਚ ਵਾਲਾ ਪਤਾ ਲੈ ਕੇ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਮੀਡੀਆ ਪੋਰਟਾਂ 'ਤੇ ਪੈਕਟ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਵਹਿ ਰਹੇ ਹਨ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਝੂਠਾ ਹੋਵੇ ਤਾਂ ਸਮੱਸਿਆ ਸੁਰੰਗ ਵਿੱਚ ਨਹੀਂ। ਜੋ ਰਾਹ ਨਾਕਾਮ ਹੋਇਆ ਉਸਨੂੰ ਠੀਕ ਕਰੋ, ਫਿਰ ਬਦਲਾਅ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਉਹੀ ਕੈਪਚਰ ਦੁਬਾਰਾ ਚਲਾਓ। ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੇ ਕੈਪਚਰ ਰੱਖਣ ਨਾਲ ਅਗਲੀ ਇੱਕ-ਦਿਸ਼ਾਵੀ ਰਿਪੋਰਟ ਪੂਰੀ ਦੁਪਹਿਰ ਦੀ ਥਾਂ ਪੰਜ ਮਿੰਟ ਦੀ ਜਾਂਚ ਬਣ ਜਾਂਦੀ ਹੈ।