ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਦੀ ਕਹਾਣੀ ਜਾਂ ਕਿਵੇਂ ਮੈਂ Asterisk ਅਤੇ Php 'ਤੇ ਅਧਾਰਤ PBX ਬਣਾਉਣ ਵਿੱਚ 7 ​​ਸਾਲ ਬਿਤਾਏ

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

ਵਿਚਾਰ ਅਤੇ ਮੁੱਖ ਲੋੜਾਂ

ਅਤੇ ਇਹ ਸਭ ਸਿਰਫ਼ ਪਿਆਰ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ ਤਾਰੇ (ਸੰਚਾਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਣ ਲਈ ਫਰੇਮਵਰਕ), ਟੈਲੀਫੋਨੀ ਅਤੇ ਸਥਾਪਨਾਵਾਂ ਦਾ ਆਟੋਮੇਸ਼ਨ ਫ੍ਰੀਪੀਬੀਐਕਸ (ਲਈ ਵੈੱਬ ਇੰਟਰਫੇਸ ਤਾਰੇ). ਜੇ ਕੰਪਨੀ ਦੀਆਂ ਲੋੜਾਂ ਬਿਨਾਂ ਵਿਸ਼ਿਸ਼ਟ ਸਨ ਅਤੇ ਸਮਰੱਥਾਵਾਂ ਦੇ ਅੰਦਰ ਆਉਂਦੀਆਂ ਸਨ ਫ੍ਰੀਪੀਬੀਐਕਸ - ਸਭ ਕੁਝ ਬਹੁਤ ਵਧੀਆ ਹੈ. ਪੂਰੀ ਸਥਾਪਨਾ XNUMX ਘੰਟਿਆਂ ਦੇ ਅੰਦਰ ਹੋ ਗਈ, ਕੰਪਨੀ ਨੂੰ ਇੱਕ ਸੰਰਚਿਤ PBX, ਇੱਕ ਉਪਭੋਗਤਾ-ਅਨੁਕੂਲ ਇੰਟਰਫੇਸ ਅਤੇ ਛੋਟੀ ਸਿਖਲਾਈ ਅਤੇ ਜੇਕਰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸਹਾਇਤਾ ਪ੍ਰਾਪਤ ਹੋਈ।

ਪਰ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਕੰਮ ਗੈਰ-ਮਿਆਰੀ ਸਨ ਅਤੇ ਫਿਰ ਇਹ ਇੰਨਾ ਸ਼ਾਨਦਾਰ ਨਹੀਂ ਸੀ. ਤਾਰੇ ਬਹੁਤ ਕੁਝ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਵੈੱਬ ਇੰਟਰਫੇਸ ਨੂੰ ਕੰਮ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖਣ ਲਈ, ਕਈ ਗੁਣਾ ਜ਼ਿਆਦਾ ਸਮਾਂ ਬਿਤਾਉਣਾ ਜ਼ਰੂਰੀ ਸੀ। ਇਸ ਲਈ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਵੇਰਵਾ ਬਾਕੀ ਪੀਬੀਐਕਸ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈ ਸਕਦਾ ਹੈ। ਅਤੇ ਬਿੰਦੂ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਵੈੱਬ ਇੰਟਰਫੇਸ ਨੂੰ ਲਿਖਣ ਵਿੱਚ ਲੰਬਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਸਗੋਂ ਬਿੰਦੂ ਆਰਕੀਟੈਕਚਰਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਹੈ ਫ੍ਰੀਪੀਬੀਐਕਸ. ਆਰਕੀਟੈਕਚਰ ਪਹੁੰਚ ਅਤੇ ਢੰਗ ਫ੍ਰੀਪੀਬੀਐਕਸ php4 ਦੇ ਸਮੇਂ ਰੱਖਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਉਸ ਸਮੇਂ ਪਹਿਲਾਂ ਹੀ php5.6 ਸੀ ਜਿਸ 'ਤੇ ਹਰ ਚੀਜ਼ ਨੂੰ ਸਰਲ ਅਤੇ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਸੀ।

ਆਖਰੀ ਤੂੜੀ ਇੱਕ ਚਿੱਤਰ ਦੇ ਰੂਪ ਵਿੱਚ ਗ੍ਰਾਫਿਕਲ ਡਾਇਲਪਲਾਨਸ ਸੀ. ਜਦੋਂ ਮੈਂ ਇਸ ਲਈ ਕੁਝ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਫ੍ਰੀਪੀਬੀਐਕਸ, ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਮੈਨੂੰ ਇਸ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪਏਗਾ ਅਤੇ ਕੁਝ ਨਵਾਂ ਬਣਾਉਣਾ ਆਸਾਨ ਹੋਵੇਗਾ.

ਮੁੱਖ ਲੋੜਾਂ ਸਨ:

• ਸਧਾਰਨ ਸੈੱਟਅੱਪ, ਇੱਕ ਨਵੇਂ ਪ੍ਰਸ਼ਾਸਕ ਲਈ ਵੀ ਅਨੁਭਵੀ ਪਹੁੰਚਯੋਗ। ਇਸ ਤਰ੍ਹਾਂ, ਕੰਪਨੀਆਂ ਨੂੰ ਸਾਡੇ ਪਾਸੇ PBX ਰੱਖ-ਰਖਾਅ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ,
• ਆਸਾਨ ਸੋਧ ਤਾਂ ਜੋ ਕੰਮਾਂ ਨੂੰ ਢੁਕਵੇਂ ਸਮੇਂ ਵਿੱਚ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕੇ,
• PBX ਨਾਲ ਏਕੀਕਰਣ ਦੀ ਸੌਖ। ਯੂ ਫ੍ਰੀਪੀਬੀਐਕਸ ਸੈਟਿੰਗਾਂ ਨੂੰ ਬਦਲਣ ਲਈ ਕੋਈ API ਨਹੀਂ ਸੀ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ, ਉਦਾਹਰਨ ਲਈ, ਕਿਸੇ ਤੀਜੀ-ਧਿਰ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਗਰੁੱਪ ਜਾਂ ਵੌਇਸ ਮੀਨੂ ਨਹੀਂ ਬਣਾ ਸਕਦੇ, ਸਿਰਫ਼ API ਹੀ ਤਾਰੇ,
• ਓਪਨਸੋਰਸ - ਪ੍ਰੋਗਰਾਮਰਾਂ ਲਈ ਇਹ ਕਲਾਇੰਟ ਲਈ ਸੋਧਾਂ ਲਈ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ।

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

ਅਗਲੀ ਚੀਜ਼ ਜੋ ਦੁਬਾਰਾ ਕੰਮ ਕਰਨ ਦੇ ਸਮੇਂ ਨੂੰ ਹੌਲੀ ਕਰਦੀ ਹੈ ਅਤੇ ਡੁਪਲੀਕੇਸ਼ਨ ਤੋਂ ਬਚਣ ਦੇ ਯੋਗ ਸੀ. ਜੇਕਰ ਕਿਸੇ ਕਰਮਚਾਰੀ ਨੂੰ ਡਾਇਲ ਕਰਨ ਲਈ ਕੋਈ ਮਾਡਿਊਲ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਤਾਂ ਹੋਰ ਸਾਰੇ ਮਾਡਿਊਲ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਿਸੇ ਕਰਮਚਾਰੀ ਨੂੰ ਕਾਲ ਭੇਜਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਨੂੰ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਉਹਨਾਂ ਦੀਆਂ ਆਪਣੀਆਂ ਕਾਪੀਆਂ ਬਣਾਉਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇਸ ਲਈ, ਜੇ ਤੁਹਾਨੂੰ ਕੁਝ ਬਦਲਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਿਰਫ ਇੱਕ ਜਗ੍ਹਾ ਵਿੱਚ ਬਦਲਣਾ ਪਏਗਾ ਅਤੇ "ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ" ਦੀ ਖੋਜ ਇੱਕ ਜਗ੍ਹਾ ਤੇ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਖੋਜ ਨਹੀਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ।

ਪਹਿਲਾ ਸੰਸਕਰਣ ਅਤੇ ਪਹਿਲੀ ਗਲਤੀਆਂ

ਪਹਿਲਾ ਪ੍ਰੋਟੋਟਾਈਪ ਇੱਕ ਸਾਲ ਦੇ ਅੰਦਰ ਤਿਆਰ ਹੋ ਗਿਆ ਸੀ। ਪੂਰਾ PBX, ਜਿਵੇਂ ਕਿ ਯੋਜਨਾਬੱਧ ਕੀਤਾ ਗਿਆ ਸੀ, ਮਾਡਿਊਲਰ ਸੀ, ਅਤੇ ਮੋਡੀਊਲ ਨਾ ਸਿਰਫ਼ ਕਾਲਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਜੋੜ ਸਕਦੇ ਸਨ, ਸਗੋਂ ਵੈੱਬ ਇੰਟਰਫੇਸ ਨੂੰ ਵੀ ਬਦਲ ਸਕਦੇ ਸਨ।

ਹਾਂ, ਅਜਿਹੀ ਸਕੀਮ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਡਾਇਲਪਲਾਨ ਬਣਾਉਣ ਦਾ ਵਿਚਾਰ ਮੇਰਾ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਬਹੁਤ ਸੁਵਿਧਾਜਨਕ ਹੈ ਅਤੇ ਮੈਂ ਵੀ ਅਜਿਹਾ ਹੀ ਕੀਤਾ ਹੈ। ਤਾਰੇ.

ਇੱਕ ਮੋਡੀਊਲ ਲਿਖ ਕੇ, ਪ੍ਰੋਗਰਾਮਰ ਪਹਿਲਾਂ ਹੀ:

• ਕਾਲ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਆਪਣੀ ਖੁਦ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਬਣਾਓ, ਜਿਸ ਨੂੰ ਡਾਇਗ੍ਰਾਮ 'ਤੇ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਨਾਲ ਹੀ ਖੱਬੇ ਪਾਸੇ ਦੇ ਤੱਤਾਂ ਦੇ ਮੀਨੂ ਵਿੱਚ,
• ਵੈੱਬ ਇੰਟਰਫੇਸ ਲਈ ਆਪਣੇ ਖੁਦ ਦੇ ਪੰਨੇ ਬਣਾਓ ਅਤੇ ਆਪਣੇ ਟੈਂਪਲੇਟਸ ਨੂੰ ਮੌਜੂਦਾ ਪੰਨਿਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ (ਜੇ ਪੇਜ ਡਿਵੈਲਪਰ ਨੇ ਇਸਦੇ ਲਈ ਪ੍ਰਦਾਨ ਕੀਤਾ ਹੈ),
• ਆਪਣੀਆਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਮੁੱਖ ਸੈਟਿੰਗਾਂ ਟੈਬ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ ਜਾਂ ਆਪਣੀ ਖੁਦ ਦੀ ਸੈਟਿੰਗ ਟੈਬ ਬਣਾਓ,
• ਪ੍ਰੋਗਰਾਮਰ ਮੌਜੂਦਾ ਮੋਡੀਊਲ ਤੋਂ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹੈ, ਕਾਰਜਸ਼ੀਲਤਾ ਦਾ ਹਿੱਸਾ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਨਵੇਂ ਨਾਮ ਹੇਠ ਰਜਿਸਟਰ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਅਸਲੀ ਮੋਡੀਊਲ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ।

ਉਦਾਹਰਨ ਲਈ, ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਆਪਣਾ ਵੌਇਸ ਮੀਨੂ ਬਣਾ ਸਕਦੇ ਹੋ:

......
class CPBX_MYIVR extends CPBX_IVR
{
 function __construct()
 {
 parent::__construct();
 $this->_module = "myivr";
 }
}
.....
$myIvrModule = new CPBX_MYIVR();
CPBXEngine::getInstance()->registerModule($myIvrModule,__DIR__); //Зарегистрировать новый модуль
CPBXEngine::getInstance()->registerModuleExtension($myIvrModule,'ivr',__DIR__); //Подменить существующий модуль

ਪਹਿਲੇ ਗੁੰਝਲਦਾਰ ਅਮਲਾਂ ਨੇ ਪਹਿਲਾ ਮਾਣ ਅਤੇ ਪਹਿਲੀ ਨਿਰਾਸ਼ਾ ਲਿਆਂਦੀ। ਮੈਨੂੰ ਖੁਸ਼ੀ ਸੀ ਕਿ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਕਿ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਦੁਬਾਰਾ ਤਿਆਰ ਕਰਨ ਦੇ ਯੋਗ ਸੀ ਫ੍ਰੀਪੀਬੀਐਕਸ. ਮੈਨੂੰ ਖੁਸ਼ੀ ਸੀ ਕਿ ਲੋਕਾਂ ਨੇ ਸਕੀਮ ਦਾ ਵਿਚਾਰ ਪਸੰਦ ਕੀਤਾ। ਵਿਕਾਸ ਨੂੰ ਸਰਲ ਬਣਾਉਣ ਲਈ ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ ਸਨ, ਪਰ ਉਸ ਸਮੇਂ ਵੀ ਕੁਝ ਕੰਮਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਆਸਾਨ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਸੀ।

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

ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ:

*ਡਾਇਲਪਲਾਨ ਇੱਕ ਨਿਯਮ (ਐਲਗੋਰਿਦਮ) ਹੈ ਜਿਸ ਦੁਆਰਾ ਇੱਕ ਕਾਲ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

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

ਇਸ ਸੰਸਕਰਣ ਵਿੱਚ, ਜਿਵੇਂ ਕਿ ਵਿੱਚ ਅਸਕੋਜ਼ੀਆ, ਸਿਰਫ ਬਦਲੇ ਹੋਏ ਮੋਡੀਊਲਾਂ ਦੀ ਸੰਰਚਨਾ ਤਿਆਰ ਕਰਨਾ ਅਤੇ ਸਿਰਫ ਲੋੜੀਂਦੇ ਮੋਡੀਊਲਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਸੰਭਵ ਸੀ, ਪਰ ਇਹ ਸਾਰੇ ਅੱਧੇ ਉਪਾਅ ਹਨ। ਪਹੁੰਚ ਬਦਲਣ ਦੀ ਲੋੜ ਸੀ।

ਦੂਜਾ ਸੰਸਕਰਣ. ਨੱਕ ਕੱਢੀ ਪੂਛ ਫਸੀ

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

ਅੰਤ ਵਿੱਚ, ਮੁੜ ਚਾਲੂ ਕਰਨ ਦੀ ਵੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਸੀ ਤਾਰੇ ਜਦੋਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਬਦਲਣਾ ਅਤੇ ਸਾਰੀਆਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਤੁਰੰਤ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ ਤਾਰੇ.

ਡਾਇਲਪਲਾਨ ਵਿੱਚ ਸਿਰਫ ਬਦਲਾਅ ਐਕਸਟੈਂਸ਼ਨ ਨੰਬਰਾਂ ਨੂੰ ਜੋੜਨਾ ਹੈ ਅਤੇ ਸੰਕੇਤ. ਪਰ ਇਹ ਛੋਟੇ ਸਪਾਟ ਬਦਲਾਅ ਸਨ

exten=>101,1,GoSub(‘sub-callusers’,s,1(1)); - точечное изменение, добавляется/изменяется через ami

; sub-callusers – универсальная функция генерится при установке модуля.
[sub-callusers]
exten =>s,1,Noop()
exten =>s,n,Set(LOCAL(TOUSERID)=${ARG1})
exten =>s,n,ClearHash(TOUSERPARAM)
exten =>s,n,Set(HASH(TOUSERPARAM)=${REALTIME_HASH(rl_users,id,${LOCAL(TOUSERID)})})
exten =>s,n,GotoIf($["${HASH(TOUSERPARAM,id)}"=""]?return)
...

ਤੁਸੀਂ ਡਾਇਲਪਲਾਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਸਾਨੀ ਨਾਲ ਇੱਕ ਲਾਈਨ ਜੋੜ ਜਾਂ ਬਦਲ ਸਕਦੇ ਹੋ ਅਮੀ (ਕੰਟਰੋਲ ਇੰਟਰਫੇਸ ਤਾਰੇ) ਅਤੇ ਪੂਰੇ ਡਾਇਲਪਲਾਨ ਨੂੰ ਰੀਬੂਟ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਇਸ ਨੇ ਕੌਂਫਿਗਰੇਸ਼ਨ API ਨਾਲ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ। ਤੁਸੀਂ ਸਿੱਧੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਜਾ ਸਕਦੇ ਹੋ ਅਤੇ ਇੱਕ ਨਵਾਂ ਸਮੂਹ ਜੋੜ ਸਕਦੇ ਹੋ ਜਾਂ ਬਦਲ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਗਰੁੱਪ ਲਈ "ਡਾਇਲਟਾਈਮ" ਖੇਤਰ ਵਿੱਚ ਡਾਇਲ-ਅੱਪ ਸਮਾਂ ਅਤੇ ਅਗਲੀ ਕਾਲ ਪਹਿਲਾਂ ਹੀ ਨਿਰਧਾਰਤ ਸਮੇਂ ਤੱਕ ਚੱਲੇਗੀ (ਇਹ ਇਸ ਲਈ ਸਿਫਾਰਸ਼ ਨਹੀਂ ਹੈ ਕਾਰਵਾਈ, ਕਿਉਂਕਿ ਕੁਝ API ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਮੀ ਕਾਲਾਂ)

ਪਹਿਲੇ ਮੁਸ਼ਕਲ ਅਮਲਾਂ ਨੇ ਫਿਰ ਪਹਿਲਾ ਮਾਣ ਅਤੇ ਨਿਰਾਸ਼ਾ ਲਿਆਂਦੀ। ਮੈਨੂੰ ਖੁਸ਼ੀ ਸੀ ਕਿ ਇਸ ਨੇ ਕੰਮ ਕੀਤਾ। ਡਾਟਾਬੇਸ ਇੱਕ ਨਾਜ਼ੁਕ ਲਿੰਕ ਬਣ ਗਿਆ, ਡਿਸਕ 'ਤੇ ਨਿਰਭਰਤਾ ਵਧ ਗਈ, ਹੋਰ ਜੋਖਮ ਸਨ, ਪਰ ਸਭ ਕੁਝ ਸਥਿਰ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕੀਤਾ. ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਹੁਣ ਉਹ ਸਭ ਕੁਝ ਜੋ ਵੈਬ ਇੰਟਰਫੇਸ ਦੁਆਰਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ API ਦੁਆਰਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ, ਅਤੇ ਉਹੀ ਢੰਗ ਵਰਤੇ ਗਏ ਸਨ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਵੈੱਬ ਇੰਟਰਫੇਸ ਨੇ "ਪੀਬੀਐਕਸ 'ਤੇ ਸੈਟਿੰਗਾਂ ਲਾਗੂ ਕਰੋ" ਬਟਨ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਇਆ, ਜਿਸ ਬਾਰੇ ਪ੍ਰਬੰਧਕ ਅਕਸਰ ਭੁੱਲ ਜਾਂਦੇ ਹਨ।

ਨਿਰਾਸ਼ਾ ਇਹ ਸੀ ਕਿ ਵਿਕਾਸ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੋ ਗਿਆ. ਪਹਿਲੇ ਸੰਸਕਰਣ ਤੋਂ, PHP ਭਾਸ਼ਾ ਨੇ ਭਾਸ਼ਾ ਵਿੱਚ ਇੱਕ ਡਾਇਲਪਲਾਨ ਤਿਆਰ ਕੀਤਾ ਹੈ ਤਾਰੇ ਅਤੇ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਪੜ੍ਹਨਯੋਗ ਨਹੀਂ ਹੈ, ਨਾਲ ਹੀ ਭਾਸ਼ਾ ਵੀ ਤਾਰੇ ਡਾਇਲਪਲਾਨ ਲਿਖਣ ਲਈ ਇਹ ਬਹੁਤ ਹੀ ਮੁੱਢਲਾ ਹੈ।

ਇਹ ਕਿਹੋ ਜਿਹਾ ਦਿਸਦਾ ਸੀ:

$usersInitSection = $dialplan->createExtSection('usersinit-sub','s');
$usersInitSection
 ->add('',new Dialplanext_gotoif('$["${G_USERINIT}"="1"]','exit'))
 ->add('',new Dialplanext_set('G_USERINIT','1'))
 ->add('',new Dialplanext_gosub('1','s','sub-AddOnAnswerSub','usersconnected-sub'))
 ->add('',new Dialplanext_gosub('1','s','sub-AddOnPredoDialSub','usersinitondial-sub'))
 ->add('',new Dialplanext_set('LOCAL(TECH)','${CUT(CHANNEL(name),/,1)}'))
 ->add('',new Dialplanext_gotoif('$["${LOCAL(TECH)}"="SIP"]','sipdev'))
 ->add('',new Dialplanext_gotoif('$["${LOCAL(TECH)}"="PJSIP"]','pjsipdev'))

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

ਤੀਜਾ ਸੰਸਕਰਣ

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

ਅਜ਼ਮਾਇਸ਼ ਅਤੇ ਗਲਤੀ ਦਾ ਇੱਕ ਬਹੁਤ ਸਾਰਾ ਸੀ. ਮੁੱਖ ਸਮੱਸਿਆ ਇਹ ਸੀ ਕਿ ਮੇਰੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਸਾਰੀਆਂ ਕਲਾਸਾਂ/ਫਾਇਲਾਂ ਸਨ। ਆਬਜੈਕਟ ਬਣਾਉਣ, ਉਹਨਾਂ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ, ਅਤੇ ਇੱਕ ਦੂਜੇ ਨਾਲ ਇੱਕ ਦੂਜੇ ਨੂੰ ਰਜਿਸਟਰ ਕਰਨ ਵਿੱਚ ਲਗਭਗ 1,5 ਸਕਿੰਟ ਲੱਗ ਗਏ, ਅਤੇ ਇਹ ਦੇਰੀ ਪ੍ਰਤੀ ਕਾਲ ਅਜਿਹੀ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਹੈ ਜਿਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਸ਼ੁਰੂਆਤ ਕੇਵਲ ਇੱਕ ਵਾਰ ਹੀ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ ਅਤੇ ਇਸਲਈ ਇੱਕ ਹੱਲ ਦੀ ਖੋਜ php ਵਿੱਚ ਇੱਕ ਸੇਵਾ ਲਿਖਣ ਨਾਲ ਸ਼ੁਰੂ ਹੋਈ ਪਥਰੇਡ. ਇੱਕ ਹਫ਼ਤੇ ਦੇ ਪ੍ਰਯੋਗਾਂ ਤੋਂ ਬਾਅਦ, ਇਹ ਐਕਸਟੈਂਸ਼ਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਦੀਆਂ ਪੇਚੀਦਗੀਆਂ ਦੇ ਕਾਰਨ ਇਸ ਵਿਕਲਪ ਨੂੰ ਰੋਕ ਦਿੱਤਾ ਗਿਆ ਸੀ। ਇੱਕ ਮਹੀਨੇ ਦੀ ਜਾਂਚ ਤੋਂ ਬਾਅਦ, ਮੈਨੂੰ PHP ਵਿੱਚ ਅਸਿੰਕ੍ਰੋਨਸ ਪ੍ਰੋਗਰਾਮਿੰਗ ਨੂੰ ਵੀ ਛੱਡਣਾ ਪਿਆ; ਮੈਨੂੰ ਕਿਸੇ ਸਧਾਰਨ, ਕਿਸੇ ਵੀ PHP ਸ਼ੁਰੂਆਤੀ ਲਈ ਜਾਣੂ ਹੋਣ ਦੀ ਲੋੜ ਸੀ, ਅਤੇ PHP ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਐਕਸਟੈਂਸ਼ਨਾਂ ਸਮਕਾਲੀ ਹਨ।

ਹੱਲ ਸੀ ਵਿੱਚ ਸਾਡੀ ਆਪਣੀ ਮਲਟੀ-ਥਰਿੱਡਡ ਸੇਵਾ ਸੀ, ਜਿਸ ਨਾਲ ਕੰਪਾਇਲ ਕੀਤਾ ਗਿਆ ਸੀ PHPLIB. ਇਹ ਸਾਰੀਆਂ ATS php ਫਾਈਲਾਂ ਨੂੰ ਲੋਡ ਕਰਦਾ ਹੈ, ਸਾਰੇ ਮੋਡਿਊਲਾਂ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਇੱਕ ਦੂਜੇ ਨੂੰ ਕਾਲਬੈਕ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਸਭ ਕੁਝ ਤਿਆਰ ਹੁੰਦਾ ਹੈ, ਇਸ ਨੂੰ ਕੈਸ਼ ਕਰਦਾ ਹੈ। ਵਲੋਂ ਪੁੱਛਗਿੱਛ ਕਰਨ 'ਤੇ ਐੱਸ ਫਾਸਟੈਜੀ ਇੱਕ ਸਟ੍ਰੀਮ ਬਣਾਈ ਜਾਂਦੀ ਹੈ, ਸਾਰੀਆਂ ਕਲਾਸਾਂ ਦੇ ਕੈਸ਼ ਤੋਂ ਇੱਕ ਕਾਪੀ ਅਤੇ ਡੇਟਾ ਇਸ ਵਿੱਚ ਦੁਬਾਰਾ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਬੇਨਤੀ ਨੂੰ php ਫੰਕਸ਼ਨ ਨੂੰ ਪਾਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਇਸ ਹੱਲ ਦੇ ਨਾਲ, ਸਾਡੀ ਸੇਵਾ ਨੂੰ ਕਾਲ ਭੇਜਣ ਤੋਂ ਲੈ ਕੇ ਪਹਿਲੀ ਕਮਾਂਡ ਤੱਕ ਦਾ ਸਮਾਂ ਤਾਰੇ 1,5s ਤੋਂ 0,05s ਤੱਕ ਘਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਹ ਸਮਾਂ ਪ੍ਰੋਜੈਕਟ ਦੇ ਆਕਾਰ 'ਤੇ ਥੋੜ੍ਹਾ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

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

ਮੋਡੀਊਲ ਕਲਾਸ ਵਿੱਚ ਡਾਇਲਪਲਾਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਫੰਕਸ਼ਨ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ dialplanDynamicCall ਅਤੇ ਦਲੀਲ pbxCallRequest ਨਾਲ ਗੱਲਬਾਤ ਕਰਨ ਲਈ ਇੱਕ ਵਸਤੂ ਸ਼ਾਮਲ ਹੋਵੇਗੀ ਤਾਰੇ.

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਡਾਇਲਪਲਾਨ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਸੰਭਵ ਹੋ ਗਿਆ ਹੈ (php ਕੋਲ xdebug ਹੈ ਅਤੇ ਇਹ ਸਾਡੀ ਸੇਵਾ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ), ਤੁਸੀਂ ਵੇਰੀਏਬਲ ਦੇ ਮੁੱਲਾਂ ਨੂੰ ਦੇਖ ਕੇ ਕਦਮ ਦਰ ਕਦਮ ਵਧਾ ਸਕਦੇ ਹੋ।

ਕਾਲ ਡੇਟਾ

ਕਿਸੇ ਵੀ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਰਿਪੋਰਟਾਂ ਲਈ ਸਹੀ ਢੰਗ ਨਾਲ ਇਕੱਤਰ ਕੀਤੇ ਡੇਟਾ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਹ ਪੀਬੀਐਕਸ ਬਲਾਕ ਵੀ ਪਹਿਲੇ ਤੋਂ ਤੀਜੇ ਸੰਸਕਰਣ ਤੱਕ ਬਹੁਤ ਸਾਰੇ ਅਜ਼ਮਾਇਸ਼ਾਂ ਅਤੇ ਗਲਤੀਆਂ ਵਿੱਚੋਂ ਲੰਘਿਆ ਹੈ। ਅਕਸਰ, ਕਾਲ ਡੇਟਾ ਇੱਕ ਸੰਕੇਤ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਕਾਲ = ਇੱਕ ਰਿਕਾਰਡਿੰਗ: ਕਿਸਨੇ ਬੁਲਾਇਆ, ਕਿਸ ਨੇ ਜਵਾਬ ਦਿੱਤਾ, ਕਿੰਨੀ ਦੇਰ ਤੱਕ ਗੱਲ ਕੀਤੀ। ਵਧੇਰੇ ਦਿਲਚਸਪ ਵਿਕਲਪਾਂ ਵਿੱਚ, ਇੱਕ ਵਾਧੂ ਚਿੰਨ੍ਹ ਹੈ ਜੋ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਾਲ ਦੇ ਦੌਰਾਨ ਕਿਸ PBX ਕਰਮਚਾਰੀ ਨੂੰ ਬੁਲਾਇਆ ਗਿਆ ਸੀ। ਪਰ ਇਹ ਸਭ ਲੋੜਾਂ ਦਾ ਸਿਰਫ਼ ਹਿੱਸਾ ਹੀ ਕਵਰ ਕਰਦਾ ਹੈ।

ਸ਼ੁਰੂਆਤੀ ਲੋੜਾਂ ਸਨ:

• ਨਾ ਸਿਰਫ਼ ਪੀਬੀਐਕਸ ਨੇ ਕਿਸ ਨੂੰ ਬੁਲਾਇਆ, ਸਗੋਂ ਕਿਸ ਨੇ ਜਵਾਬ ਦਿੱਤਾ, ਕਿਉਂਕਿ ਇੱਥੇ ਰੁਕਾਵਟਾਂ ਹਨ ਅਤੇ ਕਾਲਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਸਮੇਂ ਇਸ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ,
• ਕਿਸੇ ਕਰਮਚਾਰੀ ਨਾਲ ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਸਮਾਂ। ਵਿੱਚ ਫ੍ਰੀਪੀਬੀਐਕਸ ਅਤੇ ਕੁਝ ਹੋਰ PBX, ਜਿਵੇਂ ਹੀ PBX ਫ਼ੋਨ ਚੁੱਕਦਾ ਹੈ, ਕਾਲ ਨੂੰ ਜਵਾਬ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਪਰ ਵੌਇਸ ਮੀਨੂ ਲਈ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਫ਼ੋਨ ਚੁੱਕਣ ਦੀ ਲੋੜ ਹੈ, ਇਸ ਲਈ ਸਾਰੀਆਂ ਕਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਲਈ ਉਡੀਕ ਸਮਾਂ 0-1 ਸਕਿੰਟ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਸ ਲਈ, ਨਾ ਸਿਰਫ਼ ਜਵਾਬ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਸਮਾਂ ਬਚਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਸਗੋਂ ਮੁੱਖ ਮੋਡੀਊਲ ਨਾਲ ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਸਮਾਂ (ਮੌਡਿਊਲ ਖੁਦ ਇਹ ਫਲੈਗ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਵਰਤਮਾਨ ਵਿੱਚ ਇਹ "ਕਰਮਚਾਰੀ", "ਬਾਹਰੀ ਲਾਈਨ" ਹੈ),
• ਇੱਕ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਡਾਇਲਪਲਾਨ ਲਈ, ਜਦੋਂ ਇੱਕ ਕਾਲ ਵੱਖ-ਵੱਖ ਸਮੂਹਾਂ ਵਿਚਕਾਰ ਯਾਤਰਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਹਰੇਕ ਤੱਤ ਦੀ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਜ਼ਰੂਰੀ ਸੀ।

ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਉਦੋਂ ਨਿਕਲਿਆ ਜਦੋਂ ਪੀਬੀਐਕਸ ਮੋਡੀਊਲ ਕਾਲਾਂ 'ਤੇ ਆਪਣੇ ਬਾਰੇ ਜਾਣਕਾਰੀ ਭੇਜਦੇ ਹਨ ਅਤੇ ਆਖਰਕਾਰ ਜਾਣਕਾਰੀ ਨੂੰ ਇੱਕ ਰੁੱਖ ਦੇ ਰੂਪ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹਨ।

ਇਹ ਇਸ ਤਰਾਂ ਦਿਸਦਾ ਹੈ:

ਪਹਿਲਾਂ, ਕਾਲ ਬਾਰੇ ਆਮ ਜਾਣਕਾਰੀ (ਹਰ ਕਿਸੇ ਦੀ ਤਰ੍ਹਾਂ - ਕੁਝ ਖਾਸ ਨਹੀਂ)।

1. ਇੱਕ ਬਾਹਰੀ ਲਾਈਨ 'ਤੇ ਇੱਕ ਕਾਲ ਪ੍ਰਾਪਤ ਕੀਤੀ "ਟੈਸਟ ਲਈ"05:55:52 'ਤੇ ਨੰਬਰ 89295671458 ਤੋਂ ਨੰਬਰ 89999999999 ਤੱਕ, ਅੰਤ ਵਿੱਚ ਇੱਕ ਕਰਮਚਾਰੀ ਦੁਆਰਾ ਜਵਾਬ ਦਿੱਤਾ ਗਿਆ"ਸਕੱਤਰ 2» ਨੰਬਰ 104 ਦੇ ਨਾਲ। ਕਲਾਇੰਟ ਨੇ 60 ਸਕਿੰਟ ਉਡੀਕ ਕੀਤੀ ਅਤੇ 36 ਸਕਿੰਟ ਲਈ ਗੱਲ ਕੀਤੀ।
2. ਕਰਮਚਾਰੀ"ਸਕੱਤਰ 2"112 'ਤੇ ਕਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਕਰਮਚਾਰੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ"ਪ੍ਰਬੰਧਕ 1» 8 ਸਕਿੰਟਾਂ ਬਾਅਦ। ਉਹ 14 ਸਕਿੰਟ ਤੱਕ ਗੱਲ ਕਰਦੇ ਹਨ।
3. ਕਲਾਇੰਟ ਨੂੰ ਕਰਮਚਾਰੀ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ "ਮੈਨੇਜਰ 1ਜਿੱਥੇ ਉਹ ਹੋਰ 13 ਸਕਿੰਟਾਂ ਲਈ ਗੱਲ ਕਰਦੇ ਰਹੇ

ਪਰ ਇਹ ਆਈਸਬਰਗ ਦੀ ਟਿਪ ਹੈ; ਹਰੇਕ ਰਿਕਾਰਡ ਲਈ ਤੁਸੀਂ PBX ਦੁਆਰਾ ਇੱਕ ਵਿਸਤ੍ਰਿਤ ਕਾਲ ਇਤਿਹਾਸ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।

ਸਾਰੀ ਜਾਣਕਾਰੀ ਕਾਲਾਂ ਦੇ ਆਲ੍ਹਣੇ ਵਜੋਂ ਪੇਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

1. ਇੱਕ ਬਾਹਰੀ ਲਾਈਨ 'ਤੇ ਇੱਕ ਕਾਲ ਪ੍ਰਾਪਤ ਕੀਤੀ "ਟੈਸਟ ਲਈ» 05:55:52 'ਤੇ ਨੰਬਰ 89295671458 ਤੋਂ ਨੰਬਰ 89999999999 ਤੱਕ।
2. 05:55:53 'ਤੇ ਬਾਹਰਲੀ ਲਾਈਨ ਇਨਕਮਿੰਗ ਸਰਕਟ ਨੂੰ ਕਾਲ ਭੇਜਦੀ ਹੈ।ਟੈਸਟ»
3. ਸਕੀਮ ਦੇ ਅਨੁਸਾਰ ਇੱਕ ਕਾਲ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਸਮੇਂ, ਮੋਡੀਊਲ "ਮੈਨੇਜਰ ਕਾਲ", ਜਿਸ ਵਿੱਚ ਕਾਲ 16 ਸਕਿੰਟ ਹੈ। ਇਹ ਕਲਾਇੰਟ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਇੱਕ ਮੋਡੀਊਲ ਹੈ।
4. ਮੋਡੀਊਲ "ਮੈਨੇਜਰ ਕਾਲ"ਨੰਬਰ (ਕਲਾਇੰਟ) ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਕਰਮਚਾਰੀ ਨੂੰ ਇੱਕ ਕਾਲ ਭੇਜਦਾ ਹੈ"ਪ੍ਰਬੰਧਕ 1” ਅਤੇ ਜਵਾਬ ਲਈ 5 ਸਕਿੰਟ ਉਡੀਕ ਕਰਦਾ ਹੈ। ਮੈਨੇਜਰ ਨੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਦਿੱਤਾ।
5. ਮੋਡੀਊਲ "ਮੈਨੇਜਰ ਕਾਲ"ਸਮੂਹ ਨੂੰ ਇੱਕ ਕਾਲ ਭੇਜਦਾ ਹੈ"CORP ਪ੍ਰਬੰਧਕ" ਇਹ ਉਸੇ ਦਿਸ਼ਾ ਦੇ ਦੂਜੇ ਪ੍ਰਬੰਧਕ ਹਨ (ਇੱਕੋ ਕਮਰੇ ਵਿੱਚ ਬੈਠੇ ਹੋਏ) ਅਤੇ ਜਵਾਬ ਲਈ 11 ਸਕਿੰਟ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਹਨ।
6. ਸਮੂਹ "CORP ਪ੍ਰਬੰਧਕ"ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ"ਪ੍ਰਬੰਧਕ 1, ਪ੍ਰਬੰਧਕ 2, ਪ੍ਰਬੰਧਕ 3"11 ਸਕਿੰਟਾਂ ਲਈ ਇੱਕੋ ਸਮੇਂ। ਕੋਈ ਉੱਤਰ ਨਹੀਂ.
7. ਮੈਨੇਜਰ ਦਾ ਕਾਲ ਖਤਮ ਹੋ ਗਿਆ। ਅਤੇ ਸਰਕਟ ਮੋਡੀਊਲ ਨੂੰ ਇੱਕ ਕਾਲ ਭੇਜਦਾ ਹੈ "1c ਤੋਂ ਰੂਟ ਚੁਣਨਾ" ਕਲਾਇੰਟ ਲਈ ਲਿਖਿਆ ਇੱਕ ਮੋਡੀਊਲ ਵੀ। ਇੱਥੇ ਕਾਲ 0 ਸਕਿੰਟਾਂ ਲਈ ਪ੍ਰੋਸੈਸ ਕੀਤੀ ਗਈ ਸੀ।
8. ਸਰਕਟ ਵੌਇਸ ਮੀਨੂ ਨੂੰ ਕਾਲ ਭੇਜਦਾ ਹੈ "ਵਾਧੂ ਡਾਇਲਿੰਗ ਦੇ ਨਾਲ ਬੁਨਿਆਦੀ" ਕਲਾਇੰਟ ਨੇ 31 ਸਕਿੰਟਾਂ ਲਈ ਉੱਥੇ ਇੰਤਜ਼ਾਰ ਕੀਤਾ, ਕੋਈ ਵਾਧੂ ਡਾਇਲਿੰਗ ਨਹੀਂ ਸੀ।
9. ਸਕੀਮ ਗਰੁੱਪ ਨੂੰ ਇੱਕ ਕਾਲ ਭੇਜਦੀ ਹੈ "ਸਕੱਤਰਾਂ", ਜਿੱਥੇ ਕਲਾਇੰਟ ਨੇ 12 ਸਕਿੰਟ ਉਡੀਕ ਕੀਤੀ।
10. ਇੱਕ ਸਮੂਹ ਵਿੱਚ, 2 ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ"ਸਕੱਤਰ 1"ਅਤੇ"ਸਕੱਤਰ 2"ਅਤੇ 12 ਸਕਿੰਟਾਂ ਬਾਅਦ ਕਰਮਚਾਰੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ"ਸਕੱਤਰ 2" ਕਾਲ ਦਾ ਜਵਾਬ ਮਾਤਾ-ਪਿਤਾ ਕਾਲਾਂ ਵਿੱਚ ਡੁਪਲੀਕੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸਮੂਹ ਵਿੱਚ ਉਸਨੇ ਜਵਾਬ ਦਿੱਤਾ "ਸਕੱਤਰ 2", ਸਰਕਟ ਨੂੰ ਕਾਲ ਕਰਨ 'ਤੇ ਜਵਾਬ ਦਿੱਤਾ"ਸਕੱਤਰ 2"ਅਤੇ ਬਾਹਰਲੀ ਲਾਈਨ 'ਤੇ ਕਾਲ ਦਾ ਜਵਾਬ ਦਿੱਤਾ"ਸਕੱਤਰ 2".

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

ਅਜਿਹੀ ਜਾਣਕਾਰੀ ਸਟੋਰੇਜ ਤੁਹਾਨੂੰ ਹਰੇਕ ਸਮੂਹ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਲੈਣ ਅਤੇ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਵੇਗੀ ਕਿ ਇਹ ਕਿੰਨੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਘੰਟੇ ਦੇ ਹਿਸਾਬ ਨਾਲ ਜਵਾਬ ਦਿੱਤੇ ਅਤੇ ਖੁੰਝੇ ਸਮੂਹਾਂ ਦਾ ਗ੍ਰਾਫ ਤਿਆਰ ਕਰੇਗਾ। ਤੁਸੀਂ ਪ੍ਰਬੰਧਕ ਨਾਲ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਟ੍ਰਾਂਸਫਰ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਕੇ ਇਹ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਜ਼ਿੰਮੇਵਾਰ ਮੈਨੇਜਰ ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਕਿੰਨਾ ਸਹੀ ਹੈ।

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

ਅੰਤ ਵਿੱਚ ਕੀ?

PBX ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਇੱਕ ਮਾਹਰ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ; ਸਭ ਤੋਂ ਆਮ ਪ੍ਰਸ਼ਾਸਕ ਇਹ ਕਰ ਸਕਦਾ ਹੈ - ਅਭਿਆਸ ਵਿੱਚ ਟੈਸਟ ਕੀਤਾ ਗਿਆ.

ਸੋਧਾਂ ਲਈ, ਗੰਭੀਰ ਯੋਗਤਾਵਾਂ ਵਾਲੇ ਮਾਹਿਰਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ; PHP ਦਾ ਗਿਆਨ ਕਾਫ਼ੀ ਹੈ, ਕਿਉਂਕਿ SIP ਪ੍ਰੋਟੋਕੋਲ, ਅਤੇ ਕਤਾਰ ਲਈ, ਅਤੇ ਇੱਕ ਕਰਮਚਾਰੀ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ, ਅਤੇ ਹੋਰਾਂ ਲਈ ਮੋਡੀਊਲ ਪਹਿਲਾਂ ਹੀ ਲਿਖੇ ਗਏ ਹਨ। ਲਈ ਇੱਕ ਰੈਪਰ ਕਲਾਸ ਹੈ ਤਾਰੇ. ਇੱਕ ਮੋਡੀਊਲ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ, ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ (ਅਤੇ ਇੱਕ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ) ਤਿਆਰ ਕੀਤੇ ਮੋਡੀਊਲ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। ਅਤੇ ਗਿਆਨ ਤਾਰੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਲੋੜੀ ਹੈ ਜੇਕਰ ਕਲਾਇੰਟ ਕੁਝ ਨਵੀਂ ਰਿਪੋਰਟ ਦੇ ਨਾਲ ਇੱਕ ਪੰਨਾ ਜੋੜਨ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਪਰ ਅਭਿਆਸ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਹਾਲਾਂਕਿ ਤੀਜੀ-ਧਿਰ ਦੇ ਪ੍ਰੋਗਰਾਮਰ ਇਸ ਦਾ ਮੁਕਾਬਲਾ ਕਰ ਸਕਦੇ ਹਨ, ਉਹ ਦਸਤਾਵੇਜ਼ਾਂ ਅਤੇ ਟਿੱਪਣੀਆਂ ਦੇ ਆਮ ਕਵਰੇਜ ਤੋਂ ਬਿਨਾਂ ਅਸੁਰੱਖਿਅਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਅਜੇ ਵੀ ਸੁਧਾਰ ਲਈ ਜਗ੍ਹਾ ਹੈ।

ਮੋਡੀਊਲ ਇਹ ਕਰ ਸਕਦੇ ਹਨ:

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

API ਦੁਆਰਾ PBX ਸੈਟਿੰਗਾਂ। ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਸਾਰੀਆਂ ਸੈਟਿੰਗਾਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਕਾਲ ਦੇ ਸਮੇਂ ਪੜ੍ਹੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ ਤੁਸੀਂ API ਦੁਆਰਾ ਸਾਰੀਆਂ PBX ਸੈਟਿੰਗਾਂ ਨੂੰ ਬਦਲ ਸਕੋ। API ਨੂੰ ਕਾਲ ਕਰਦੇ ਸਮੇਂ, ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਾਈ ਜਾਂਦੀ ਹੈ ਅਤੇ ਮੋਡੀਊਲ ਮੁੜ ਚਾਲੂ ਨਹੀਂ ਹੁੰਦੇ ਹਨ, ਇਸਲਈ, ਇਸ ਨਾਲ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿੰਨੀਆਂ ਸੈਟਿੰਗਾਂ ਅਤੇ ਕਰਮਚਾਰੀ ਹਨ। API ਬੇਨਤੀਆਂ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਇੱਕ ਦੂਜੇ ਨੂੰ ਬਲੌਕ ਨਹੀਂ ਕਰਦੀਆਂ।

ਪੀਬੀਐਕਸ ਕਾਲਾਂ (ਉਡੀਕ/ਗੱਲਬਾਤ), ਨੇਸਟਿੰਗ ਅਤੇ ਪੀਬੀਐਕਸ ਸ਼ਬਦਾਂ (ਕਰਮਚਾਰੀ, ਸਮੂਹ, ਬਾਹਰੀ ਲਾਈਨ, ਚੈਨਲ, ਨੰਬਰ ਨਹੀਂ) ਦੇ ਨਾਲ ਸਾਰੀਆਂ ਮੁੱਖ ਕਾਰਵਾਈਆਂ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਖਾਸ ਗਾਹਕਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਰਿਪੋਰਟਾਂ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਕੰਮ ਉਪਭੋਗਤਾ-ਅਨੁਕੂਲ ਇੰਟਰਫੇਸ ਬਣਾਉਣਾ ਹੈ।

ਅੱਗੇ ਕੀ ਹੋਵੇਗਾ ਸਮਾਂ ਦੱਸੇਗਾ। ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰੀਆਂ ਬਾਰੀਕੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਦੁਬਾਰਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰੀਆਂ ਯੋਜਨਾਵਾਂ ਹਨ, ਪਰ ਤੀਜੇ ਸੰਸਕਰਣ ਦੀ ਸਿਰਜਣਾ ਤੋਂ ਇੱਕ ਸਾਲ ਬੀਤ ਚੁੱਕਾ ਹੈ ਅਤੇ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਇਹ ਵਿਚਾਰ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ. ਸੰਸਕਰਣ 3 ਦਾ ਮੁੱਖ ਨੁਕਸਾਨ ਹਾਰਡਵੇਅਰ ਸਰੋਤ ਹਨ, ਪਰ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਵਿਕਾਸ ਦੀ ਸੌਖ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਸਰੋਤ: www.habr.com