ਜਦੋਂ WebRTC ਟੈਸਟ ਪੇਜ 172.20.4.15 ਛਾਪਦਾ ਹੈ, ਤਾਂ ਉਸ ਨੇ ਜਾਣ ਲਿਆ ਹੈ ਕਿ ਉਸ ਨੈੱਟਵਰਕ ਉੱਤੇ ਇੱਕ ਸਥਾਨਕ ਇੰਟਰਫ਼ੇਸ ਮੌਜੂਦ ਹੈ। ਇਹ ਅਸਲੀ ਖੁਲਾਸਾ ਹੈ, ਅਤੇ ਇਹ «ਮੀਡੀਆ VPN ਐਗਜ਼ਿਟ ਰਾਹੀਂ ਬਾਹਰ ਗਿਆ» ਵਾਲਾ ਉਹੀ ਨਤੀਜਾ ਨਹੀਂ ਹੈ। ਉਮੀਦਵਾਰ ਖੋਜ ਅਤੇ ਪੈਕਟ ਰੂਟਿੰਗ ਵੱਖਰੇ ਤੰਤਰ ਹਨ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਲੀਕ ਰਿਪੋਰਟਾਂ ਉਹਨਾਂ ਨੂੰ ਇੱਕੋ ਫ਼ੈਸਲੇ ਵਿੱਚ ਮਿਲਾ ਦਿੰਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਕਿਹੜਾ ਵੇਖ ਰਹੇ ਹੋ, ਇਹੀ ਹੱਲ ਤੈਅ ਕਰਦਾ ਹੈ।

ਕੁਝ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਇਕੱਠਾ ਕਰਨਾ ਹੁੰਦਾ ਹੈ

ਬ੍ਰਾਊਜ਼ਰ ਸਥਾਨਕ ਇੰਟਰਫ਼ੇਸਾਂ ਦੀ ਸੂਚੀ ਬਣਾਉਂਦਾ ਹੈ, STUN ਸਰਵਰ ਨੂੰ ਬਾਈਂਡਿੰਗ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ ਅਤੇ TURN ਸਰਵਰ ਤੋਂ ਅਲਾਟਮੈਂਟ ਮੰਗਦਾ ਹੈ, ਫਿਰ ਨਤੀਜਿਆਂ ਨੂੰ ਸੈਸ਼ਨ ਵਰਣਨ ਵਿੱਚ ਉਮੀਦਵਾਰ ਲਾਈਨਾਂ ਵਜੋਂ ਲਿਖਦਾ ਹੈ। ਇਹ ਸਭ ਕਿਸੇ ਕਾਲ, ਮੀਡੀਆ ਅਤੇ ਸਾਮ੍ਹਣੇ ਧਿਰ ਤੋਂ ਬਿਨਾਂ ਪੂਰਾ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ ਉਮੀਦਵਾਰਾਂ ਦੀ ਸੂਚੀ ਖੋਜ ਦਾ ਰਿਕਾਰਡ ਹੈ, ਢੋਆ-ਢੁਆਈ ਦਾ ਨਹੀਂ।

ਆਧੁਨਿਕ ਬ੍ਰਾਊਜ਼ਰ ਹੋਸਟ ਉਮੀਦਵਾਰ ਦੇ ਸ਼ਬਦੀ ਪਤੇ ਨੂੰ mDNS ਨਾਂ .local ਨਾਲ ਬਦਲ ਸਕਦੇ ਹਨ, ਜਿਸ ਕਰਕੇ ਪੇਜ ਨਿੱਜੀ IP ਨਹੀਂ ਪੜ੍ਹ ਸਕਦਾ। ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਅਜੇ ਵੀ ਉਹ ਮਲਟੀਕਾਸਟ ਕਿਊਰੀਆਂ ਵੇਖਦਾ ਹੈ ਜੋ ਉਸ ਨਾਂ ਨੂੰ ਹੱਲ ਕਰਦੀਆਂ ਹਨ, ਯਾਨੀ ਪਤਾ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਲੁਕਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਰ ਤੋਂ ਹਟਾਇਆ ਨਹੀਂ ਜਾਂਦਾ।

ਕ੍ਰਮ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਨਵਾਂ ਪੇਜ ਲੋਡ ਨਵਾਂ ਸਮੂਹ ਇਕੱਠਾ ਕਰਦਾ ਹੈ, ਵੱਖਰੀ TURN ਅਲਾਟਮੈਂਟ ਅਤੇ ਸੰਭਵ ਤੌਰ ’ਤੇ ਵੱਖਰੀ ਰਿਫਲੈਕਸਿਵ ਮੈਪਿੰਗ ਨਾਲ। ਅਸਹਿਮਤ ਦੋ ਰਨ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਦੋ ਵੱਖਰੀਆਂ ਸੰਰਚਨਾਵਾਂ ਹੋਣ।

ਤਿੰਨ ਤਰ੍ਹਾਂ ਦੇ ਉਮੀਦਵਾਰ, ਤਿੰਨ ਤਰ੍ਹਾਂ ਦੇ ਸਬੂਤ

ਹਰ ਲਾਈਨ ਕਿਸੇ ਵੱਖਰੇ ਨਿਰੀਖਣ ਤੋਂ ਆਉਂਦੀ ਹੈ। ਹਰ ਕਿਸਮ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਸਾਰਣੀ ਉਹਨਾਂ ਨੂੰ ਇਸ ਆਧਾਰ ’ਤੇ ਵੱਖ ਕਰਦੀ ਹੈ ਕਿ ਉਹ ਕੀ ਸਥਾਪਿਤ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਕੀ ਨਹੀਂ।

CandidateDerived fromWhat it establishesWhat it cannot establish
HostAn interface on the deviceA local address exists in that networkThat the peer can reach it
Server-reflexiveA STUN binding responseHow a NAT mapped this sourceWhich exit the media will use
Peer-reflexiveA connectivity check that arrivedAn address seen by the far sideThat it was ever advertised
RelayA TURN allocationThe relay server accepted the sessionThat the relay carries the call

ਰਿਲੇ ਉਮੀਦਵਾਰ ਨੂੰ ਅਕਸਰ ਵਰਤੋਂਕਾਰ ਦੇ ਇੰਟਰਨੈੱਟ ਪਤੇ ਵਜੋਂ ਗਲਤ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ TURN ਸਰਵਰ ਦਾ ਹੈ, ਅਤੇ ਇਸ ਦੀ ਮੌਜੂਦਗੀ ਦੱਸਦੀ ਹੈ ਕਿ ਰਿਲੇ ਉਪਲਬਧ ਸੀ, ਇਹ ਨਹੀਂ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਨੇ ਇਸ ਨੂੰ ਚੁਣਿਆ। ਇਹੋ ਉਲਝਣ ਹੋਸਟ ਉਮੀਦਵਾਰਾਂ ਨਾਲ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਚੱਲਦੀ ਹੈ, ਜਿੱਥੇ mDNS ਨਾਂ ਪਤੇ ਨੂੰ ਪੇਜ ਤੋਂ ਲੁਕਾਉਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਨੈੱਟਵਰਕ ਅਜੇ ਵੀ ਕਿਊਰੀਆਂ ਢੋਂਦਾ ਹੈ। ਮੁੱਲ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸਮ ਪੜ੍ਹੋ।

ਚੁਣੀ ਗਈ ਜੋੜੀ ਰੂਟਿੰਗ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ

ICE ਹਰ ਸਥਾਨਕ ਉਮੀਦਵਾਰ ਨੂੰ ਹਰ ਦੂਰਲੇ ਉਮੀਦਵਾਰ ਨਾਲ ਜੋੜਦਾ ਹੈ, ਹਰ ਜੋੜੀ ਉੱਤੇ ਕਨੈਕਟੀਵਿਟੀ ਜਾਂਚਾਂ ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਜੇਤੂ ਨਾਮਜ਼ਦ ਕਰਦਾ ਹੈ। ਉਹੀ ਨਾਮਜ਼ਦ ਜੋੜੀ, ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਆਪਣੀ ਡਾਇਗਨੋਸਟਿਕਸ ਵਿੱਚ ਦਿਖਦੀ ਹੈ, ਮੀਡੀਆ ਢੋਂਦੀ ਹੈ। ਸੂਚੀ ਵਿੱਚ ਬਾਕੀ ਸਭ ਹਾਰੀ ਹੋਈ ਸੰਭਾਵਨਾ ਹੈ।

ਜੇਤੂ ਤੁਹਾਨੂੰ ਰਾਹ ਦੀ ਸ਼ਕਲ ਦੱਸਦਾ ਹੈ। ਰਿਲੇ-ਤੋਂ-ਰਿਲੇ TURN ਸਰਵਰ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ, ਹੋਸਟ ਜੋੜੀ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਉੱਤੇ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਸਰਵਰ-ਰਿਫਲੈਕਸਿਵ ਜੋੜੀ NAT ਰਾਹੀਂ ਸਿੱਧੀ ਜਾਂਦੀ ਹੈ। ਇਹੀ ਉਹ ਤੱਥ ਹੈ ਜੋ VPN ਜਾਂਚ ਨੂੰ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਪਤਾ ਸੂਚੀ ਤੋਂ ਵੱਖਰਾ ਤੱਥ ਹੈ। ਇੱਕੋ ਜਿਹੀਆਂ ਉਮੀਦਵਾਰ ਸੂਚੀਆਂ ਵਾਲੀਆਂ ਦੋ ਕਾਲਾਂ ਵੱਖਰੀਆਂ ਜੋੜੀਆਂ ਲੈ ਸਕਦੀਆਂ ਹਨ।

ਨਾ ਚੁਣੇ ਉਮੀਦਵਾਰ ਵੀ ਇਕੱਠੇ ਹੋਏ, ਅਤੇ ਇਕੱਠਾ ਕਰਨਾ ਉਹ ਨੈੱਟਵਰਕ ਟ੍ਰੈਫ਼ਿਕ ਹੈ ਜੋ ਮਸ਼ੀਨ ਛੱਡਦਾ ਹੈ। ਜਿਸ ਕਾਲ ਨੇ ਅੰਤ ਵਿੱਚ ਰਿਲੇ ਵਰਤਿਆ, ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਸੂਚੀ ਬਣਦਿਆਂ ਕੁਝ ਵੀ ਪ੍ਰਗਟ ਨਹੀਂ ਹੋਇਆ।

ਨਿਯੰਤਰਣ ਟੀਚਿਆਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਲੀਕ ਸਕੋਰ ਨਾਲ ਨਹੀਂ

WebRTC IP-ਸੰਭਾਲ ਵਿਸ਼ੇਸ਼ਤਾ ਕਈ ਨੀਤੀਆਂ ਦੱਸਦੀ ਹੈ: ਸਿਰਫ਼ ਉਹ ਇੰਟਰਫ਼ੇਸ ਵਰਤਣਾ ਜੋ ਡਿਫ਼ਾਲਟ ਰਾਹ ਢੋਂਦਾ ਹੈ, ਸਾਰੇ ਇੰਟਰਫ਼ੇਸ ਵਰਤਣੇ, ਅਤੇ ਪ੍ਰੌਕਸੀ-ਰਹਿਤ UDP ਬੰਦ ਕਰਨਾ ਤਾਂ ਜੋ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਰਿਲੇ ਜਾਂ ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਜਾਣਾ ਪਵੇ। ਹਰ ਇੱਕ ਕਨੈਕਟੀਵਿਟੀ ਅਤੇ ਦੇਰੀ ਦੀ ਅਦਲਾ-ਬਦਲੀ ਵੱਖਰੀ ਕਿਸਮ ਦੇ ਖੁਲਾਸੇ ਨਾਲ ਕਰਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਕਿਹੜੀ ਲਾਗੂ ਕਰਦਾ ਹੈ ਅਤੇ ਕਿਹੜੇ ਨਾਂ ਹੇਠ, ਇਹ ਪਲੇਟਫ਼ਾਰਮ ਅਤੇ ਸੰਸਕਰਣ ਅਨੁਸਾਰ ਬਦਲਦਾ ਹੈ।

ਨੀਤੀ ਟੀਚੇ ਤੋਂ ਚੁਣੋ। ਪੇਜ ਤੋਂ ਸਥਾਨਕ ਪਤੇ ਲੁਕਾਉਣਾ ਇੱਕ ਟੀਚਾ ਹੈ; ਸਿੱਧਾ ਪੀਅਰ-ਤੋਂ-ਪੀਅਰ ਟ੍ਰੈਫ਼ਿਕ ਰੋਕਣਾ ਦੂਜਾ ਹੈ; ਹਰ ਪੈਕਟ ਨੂੰ ਟਨਲ ਦੇ ਅੰਦਰ ਰੱਖਣਾ ਤੀਜਾ ਹੈ। ਪਹਿਲਾ ਮੁੱਖ ਤੌਰ ’ਤੇ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਕੀ ਸਿੱਖਦੀ ਹੈ, ਦੂਜਾ ਇਸ ਬਾਰੇ ਕਿ ਕਿਹੜਾ ਰਾਹ ਮਨਜ਼ੂਰ ਹੈ, ਅਤੇ ਤੀਜਾ ਪਲੇਟਫ਼ਾਰਮ ਜਾਂ VPN ਦੀ ਸੀਮਾ ’ਤੇ ਵੀ ਲਾਗੂ ਕਰਨਾ ਪਵੇਗਾ।

ਤੁਸੀਂ ਜੋ ਵੀ ਨਿਯੰਤਰਣ ਚੁਣੋ, ਦੋਵੇਂ ਅੱਧ ਜਾਂਚੋ: ਇਕੱਠਾ ਕਰਨ ਦਾ ਟੈਸਟ ਚਲਾਓ ਅਤੇ ਉਮੀਦਵਾਰ ਕਿਸਮਾਂ ਦਰਜ ਕਰੋ, ਫਿਰ ਅਸਲੀ ਸੈਸ਼ਨ ਦੌਰਾਨ ਚੁਣੀ ਗਈ ਜੋੜੀ ਦੀ ਜਾਂਚ ਕਰੋ। ਸਿੱਧੇ ਮੀਡੀਆ ਰਾਹ ਵਾਲੀ ਸਾਫ਼ ਪਤਾ ਸੂਚੀ ਵੀ ਉਹ ਰਾਹ ਹੈ ਜਿਸ ਦਾ ਤੁਸੀਂ ਇਰਾਦਾ ਨਹੀਂ ਕੀਤਾ ਸੀ।

ਸੰਬੰਧਿਤ ਲੇਖ