ਸਿਸਕੋ ਮੀਟਿੰਗ ਸਰਵਰ 2.5.2. ਵੀਡੀਓ ਕਾਨਫਰੰਸ ਰਿਕਾਰਡਿੰਗ ਫੰਕਸ਼ਨ ਦੇ ਨਾਲ ਸਕੇਲੇਬਲ ਅਤੇ ਲਚਕੀਲੇ ਮੋਡ ਵਿੱਚ ਕਲੱਸਟਰ

ਇਸ ਅੰਕ ਵਿੱਚ ਮੈਂ ਫੇਲਓਵਰ ਕਲੱਸਟਰ ਮੋਡ ਵਿੱਚ ਇੱਕ CMS ਸਰਵਰ ਸਥਾਪਤ ਕਰਨ ਦੀਆਂ ਕੁਝ ਪੇਚੀਦਗੀਆਂ ਨੂੰ ਦਿਖਾਵਾਂਗਾ ਅਤੇ ਵਿਆਖਿਆ ਕਰਾਂਗਾ।


ਥਿਊਰੀਆਮ ਤੌਰ 'ਤੇ, CMS ਸਰਵਰ ਤੈਨਾਤੀ ਦੀਆਂ ਤਿੰਨ ਕਿਸਮਾਂ ਹਨ:

• ਸਿੰਗਲ ਸੰਯੁਕਤ(ਸਿੰਗਲ ਸੰਯੁਕਤ), i.e. ਇਹ ਇੱਕ ਸਰਵਰ ਹੈ ਜਿਸ ਉੱਤੇ ਸਾਰੀਆਂ ਜ਼ਰੂਰੀ ਸੇਵਾਵਾਂ ਚੱਲ ਰਹੀਆਂ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇਸ ਕਿਸਮ ਦੀ ਤੈਨਾਤੀ ਸਿਰਫ ਅੰਦਰੂਨੀ ਕਲਾਇੰਟ ਪਹੁੰਚ ਲਈ ਅਤੇ ਛੋਟੇ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਢੁਕਵੀਂ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਇੱਕ ਸਿੰਗਲ ਸਰਵਰ ਦੀ ਸਕੇਲੇਬਿਲਟੀ ਅਤੇ ਰਿਡੰਡੈਂਸੀ ਸੀਮਾਵਾਂ ਇੱਕ ਨਾਜ਼ੁਕ ਮੁੱਦਾ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਜਾਂ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਜਿੱਥੇ CMS ਸਿਰਫ ਕੁਝ ਫੰਕਸ਼ਨ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਐਡਹਾਕ। ਸਿਸਕੋ UCM 'ਤੇ ਕਾਨਫਰੰਸ.

  ਕੰਮ ਦੀ ਅੰਦਾਜ਼ਨ ਸਕੀਮ:
  

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

  ਕੰਮ ਦੀ ਅੰਦਾਜ਼ਨ ਸਕੀਮ:
  

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

ਤੈਨਾਤੀ 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਕੁਝ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਹੈ, ਅਰਥਾਤ

ਮੁੱਖ CMS ਸਾਫਟਵੇਅਰ ਭਾਗ:

• ਡਾਟਾਬੇਸ: ਤੁਹਾਨੂੰ ਕੁਝ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਡਾਇਲ ਪਲਾਨ, ਉਪਭੋਗਤਾ ਸਪੇਸ, ਅਤੇ ਉਪਭੋਗਤਾ ਖੁਦ। ਸਿਰਫ਼ ਉੱਚ ਉਪਲਬਧਤਾ (ਸਿੰਗਲ ਮਾਸਟਰ) ਲਈ ਕਲੱਸਟਰਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
• ਕਾਲ ਬ੍ਰਿਜ: ਆਡੀਓ ਅਤੇ ਵੀਡੀਓ ਕਾਨਫਰੰਸਿੰਗ ਲਈ ਇੱਕ ਸੇਵਾ ਜੋ ਕਾਲਾਂ ਅਤੇ ਮਲਟੀਮੀਡੀਆ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਅਤੇ ਪ੍ਰਕਿਰਿਆ 'ਤੇ ਪੂਰਾ ਨਿਯੰਤਰਣ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਉੱਚ ਉਪਲਬਧਤਾ ਅਤੇ ਸਕੇਲੇਬਿਲਟੀ ਲਈ ਕਲੱਸਟਰਿੰਗ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
• XMPP ਸਰਵਰ: ਸਿਸਕੋ ਮੀਟਿੰਗ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ/ਜਾਂ WebRTC ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਗਾਹਕਾਂ ਦੀ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਜ਼ਿੰਮੇਵਾਰਰੀਅਲ-ਟਾਈਮ ਸੰਚਾਰ, ਜਾਂ ਬਸ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ), ਅਤੇ ਨਾਲ ਹੀ ਇੰਟਰਕੰਪੋਨੈਂਟ ਸਿਗਨਲਿੰਗ। ਸਿਰਫ਼ ਉੱਚ ਉਪਲਬਧਤਾ ਲਈ ਕਲੱਸਟਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
• ਵੈੱਬ ਬ੍ਰਿਜ: WebRTC ਤੱਕ ਕਲਾਇੰਟ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।
• ਲੋਡਬੈਲੈਂਸਰ: ਸਿੰਗਲ ਸਪਲਿਟ ਮੋਡ ਵਿੱਚ ਸਿਸਕੋ ਮੀਟਿੰਗ ਐਪਸ ਲਈ ਇੱਕ ਸਿੰਗਲ ਕਨੈਕਸ਼ਨ ਪੁਆਇੰਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਆਉਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਬਾਹਰੀ ਇੰਟਰਫੇਸ ਅਤੇ ਪੋਰਟ ਨੂੰ ਸੁਣਦਾ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਲੋਡ ਬੈਲੇਂਸਰ XMPP ਸਰਵਰ ਤੋਂ ਆਉਣ ਵਾਲੇ TLS ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਜਿਸ ਰਾਹੀਂ ਇਹ ਬਾਹਰੀ ਗਾਹਕਾਂ ਤੋਂ TCP ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ।
  ਸਾਡੇ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੋਵੇਗੀ।
• ਟਰਨ ਸਰਵਰ: ਫਾਇਰਵਾਲ ਬਾਈਪਾਸ ਤਕਨਾਲੋਜੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ
  Cisco Meeting App ਜਾਂ SIP ਡਿਵਾਈਸਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਬਾਹਰੀ ਕਲਾਇੰਟਸ ਨਾਲ ਜੁੜਨ ਲਈ ਸਾਡੇ CMS ਨੂੰ ਫਾਇਰਵਾਲ ਜਾਂ NAT ਦੇ ਪਿੱਛੇ ਰੱਖੋ। ਸਾਡੇ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੋਵੇਗੀ।
• ਵੈੱਬ ਪ੍ਰਸ਼ਾਸਕ: ਪ੍ਰਸ਼ਾਸਕੀ ਇੰਟਰਫੇਸ ਅਤੇ API ਪਹੁੰਚ, ਵਿਸ਼ੇਸ਼ ਯੂਨੀਫਾਈਡ CM ਕਾਨਫਰੰਸਾਂ ਸਮੇਤ।

ਸੰਰਚਨਾ ਮੋਡ

ਸਿਸਕੋ ਦੇ ਹੋਰ ਉਤਪਾਦਾਂ ਦੇ ਉਲਟ, ਸਿਸਕੋ ਮੀਟਿੰਗ ਸਰਵਰ ਕਿਸੇ ਵੀ ਕਿਸਮ ਦੀ ਤੈਨਾਤੀ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਲਈ ਤਿੰਨ ਸੰਰਚਨਾ ਵਿਧੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

• ਕਮਾਂਡ ਲਾਈਨ (CLI): ਸ਼ੁਰੂਆਤੀ ਸੰਰਚਨਾ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਕਾਰਜਾਂ ਲਈ MMP ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਕਮਾਂਡ ਲਾਈਨ ਇੰਟਰਫੇਸ।
• ਵੈੱਬ ਪ੍ਰਸ਼ਾਸਕ: ਮੁੱਖ ਤੌਰ 'ਤੇ ਕਾਲਬ੍ਰਿਜ ਨਾਲ ਸਬੰਧਤ ਸੰਰਚਨਾਵਾਂ ਲਈ, ਖਾਸ ਤੌਰ 'ਤੇ ਜਦੋਂ ਇੱਕ ਸਿੰਗਲ ਗੈਰ-ਕਲੱਸਟਰਡ ਸਰਵਰ ਸਥਾਪਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
• REST API: ਸਭ ਤੋਂ ਗੁੰਝਲਦਾਰ ਸੰਰਚਨਾ ਕਾਰਜਾਂ ਅਤੇ ਕਲੱਸਟਰਡ ਡੇਟਾਬੇਸ ਨਾਲ ਸਬੰਧਤ ਕਾਰਜਾਂ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਉਪਰੋਕਤ ਤੋਂ ਇਲਾਵਾ, ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ SFTP ਫਾਈਲਾਂ ਦਾ ਤਬਾਦਲਾ ਕਰਨ ਲਈ—ਆਮ ਤੌਰ 'ਤੇ ਲਾਇਸੰਸ, ਸਰਟੀਫਿਕੇਟ, ਜਾਂ ਲੌਗਸ- ਨੂੰ ਅਤੇ CMS ਸਰਵਰ ਤੋਂ।

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

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

ਪਰ XMPP ਦੇ ਸੰਦਰਭ ਵਿੱਚ, ਤਿੰਨ ਸਰਵਰਾਂ ਦੇ ਇੱਕ ਕਲੱਸਟਰ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਅਸਲ ਵਿੱਚ ਜ਼ਰੂਰੀ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਜੇਕਰ, ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ XMPP ਸੇਵਾ ਨੂੰ ਕਿਸੇ ਇੱਕ ਸਰਵਰ 'ਤੇ ਅਸਮਰੱਥ ਕਰਦੇ ਹੋ ਜਿਸ ਵਿੱਚ XMMP ਲੀਡਰ ਸਥਿਤੀ ਵਿੱਚ ਹੈ, ਤਾਂ ਬਾਕੀ ਸਰਵਰ 'ਤੇ XMPP ਫਾਲੋਅਰ ਸਥਿਤੀ ਵਿੱਚ ਰਹੇਗਾ ਅਤੇ XMPP ਨਾਲ ਕਾਲਬ੍ਰਿਜ ਕਨੈਕਸ਼ਨ ਬੰਦ ਹੋ ਜਾਣਗੇ, ਕਿਉਂਕਿ ਕਾਲਬ੍ਰਿਜ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਲੀਡਰ ਸਥਿਤੀ ਦੇ ਨਾਲ XMPP ਨਾਲ ਜੁੜਦਾ ਹੈ। ਅਤੇ ਇਹ ਨਾਜ਼ੁਕ ਹੈ, ਕਿਉਂਕਿ... ਇੱਕ ਵੀ ਕਾਲ ਨਹੀਂ ਲੰਘੇਗੀ।

ਉਸੇ ਤੈਨਾਤੀ ਗਾਈਡਾਂ ਵਿੱਚ ਇੱਕ XMPP ਸਰਵਰ ਵਾਲਾ ਇੱਕ ਕਲੱਸਟਰ ਵੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਅਤੇ ਉਪਰੋਕਤ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਕਿਉਂ: ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਫੇਲਓਵਰ ਮੋਡ ਵਿੱਚ ਹੈ.

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, XMPP ਸਰਵਰ ਸਾਰੇ ਤਿੰਨ ਨੋਡਾਂ 'ਤੇ ਮੌਜੂਦ ਹੋਵੇਗਾ।

ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਸਾਡੇ ਤਿੰਨੋਂ ਸਰਵਰ ਚਾਲੂ ਹਨ।

DNS ਰਿਕਾਰਡ

ਸਰਵਰ ਸਥਾਪਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ DNS ਰਿਕਾਰਡ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ А и ਐਸ.ਆਰ.ਵੀ. ਕਿਸਮ:

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਸਾਡੇ DNS ਰਿਕਾਰਡਾਂ ਵਿੱਚ ਦੋ ਡੋਮੇਨ ਹਨ example.com ਅਤੇ ਸੰਰਚਨਾ.example.com. Example.com ਇੱਕ ਡੋਮੇਨ ਹੈ ਜਿਸਨੂੰ ਸਾਰੇ ਸਿਸਕੋ ਯੂਨੀਫਾਈਡ ਕਮਿਊਨੀਕੇਸ਼ਨ ਮੈਨੇਜਰ ਗਾਹਕ ਆਪਣੇ URIs ਲਈ ਵਰਤ ਸਕਦੇ ਹਨ, ਜੋ ਕਿ ਤੁਹਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਮੌਜੂਦ ਹੈ ਜਾਂ ਮੌਜੂਦ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ। ਜਾਂ example.com ਉਸੇ ਡੋਮੇਨ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਆਪਣੇ ਈਮੇਲ ਪਤਿਆਂ ਲਈ ਵਰਤਦੇ ਹਨ। ਜਾਂ ਤੁਹਾਡੇ ਲੈਪਟਾਪ 'ਤੇ ਜੈਬਰ ਕਲਾਇੰਟ ਕੋਲ URI ਹੋ ਸਕਦਾ ਹੈ [ਈਮੇਲ ਸੁਰੱਖਿਅਤ]. ਡੋਮੇਨ ਸੰਰਚਨਾ.example.com ਉਹ ਡੋਮੇਨ ਹੈ ਜੋ ਸਿਸਕੋ ਮੀਟਿੰਗ ਸਰਵਰ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾਵੇਗਾ। ਸਿਸਕੋ ਮੀਟਿੰਗ ਸਰਵਰ ਦਾ ਡੋਮੇਨ ਹੋਵੇਗਾ ਸੰਰਚਨਾ.example.com, ਇਸ ਲਈ ਉਸੇ ਜੈਬਰ ਉਪਭੋਗਤਾ ਲਈ, ਯੂਜ਼ਰ@ ਯੂਆਰਆਈ ਨੂੰ ਸਿਸਕੋ ਮੀਟਿੰਗ ਸਰਵਰ ਵਿੱਚ ਲੌਗਇਨ ਕਰਨ ਲਈ ਵਰਤਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।ਸੰਰਚਨਾ.example.com.

ਬੁਨਿਆਦੀ ਸੰਰਚਨਾ

ਹੇਠਾਂ ਦੱਸੀਆਂ ਸਾਰੀਆਂ ਸੈਟਿੰਗਾਂ ਇੱਕ ਸਰਵਰ 'ਤੇ ਦਿਖਾਈਆਂ ਗਈਆਂ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਕਲੱਸਟਰ ਵਿੱਚ ਹਰੇਕ ਸਰਵਰ 'ਤੇ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

QoS

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

ਹਰੇਕ ਸਰਵਰ 'ਤੇ ਅਸੀਂ ਇਹ ਕਮਾਂਡਾਂ ਦਰਜ ਕਰਾਂਗੇ

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

ਇਸ ਤਰ੍ਹਾਂ, ਸਾਰੇ ਵੀਡੀਓ ਟ੍ਰੈਫਿਕ ਨੂੰ AF41 (DSCP 0x22) ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਸਾਰੇ ਵੌਇਸ ਟ੍ਰੈਫਿਕ ਨੂੰ EF (DSCP 0x2E) ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਹੋਰ ਕਿਸਮ ਦੇ ਘੱਟ ਲੇਟੈਂਸੀ ਟ੍ਰੈਫਿਕ ਜਿਵੇਂ ਕਿ SIP ਅਤੇ XMPP AF31 (DSCP 0x1A) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

ਅਸੀਂ ਜਾਂਚਦੇ ਹਾਂ:

NTP

ਨੈੱਟਵਰਕ ਟਾਈਮ ਪ੍ਰੋਟੋਕੋਲ (NTP) ਨਾ ਸਿਰਫ਼ ਕਾਲਾਂ ਅਤੇ ਕਾਨਫਰੰਸਾਂ ਦੇ ਸਹੀ ਟਾਈਮਸਟੈਂਪ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ, ਸਗੋਂ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਆਪਣੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ NTP ਸਰਵਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ

ntp server add <server>

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਦੋ ਅਜਿਹੇ ਸਰਵਰ ਹਨ, ਇਸ ਲਈ ਦੋ ਟੀਮਾਂ ਹੋਣਗੀਆਂ.
ਅਸੀਂ ਜਾਂਚਦੇ ਹਾਂ:

ਅਤੇ ਸਾਡੇ ਸਰਵਰ ਲਈ ਸਮਾਂ ਖੇਤਰ ਸੈੱਟ ਕਰੋ

DNS ਨੂੰ

ਅਸੀਂ DNS ਸਰਵਰਾਂ ਨੂੰ CMS ਵਿੱਚ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਜੋੜਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ:

dns add forwardzone <domain-name> <server ip>

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਦੋ ਅਜਿਹੇ ਸਰਵਰ ਹਨ, ਇਸ ਲਈ ਦੋ ਟੀਮਾਂ ਹੋਣਗੀਆਂ.
ਅਸੀਂ ਜਾਂਚਦੇ ਹਾਂ:

ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ਸੰਰਚਨਾ

ਅਸੀਂ ਇੰਟਰਫੇਸ ਨੂੰ ਕਮਾਂਡ ਨਾਲ ਸੰਰਚਿਤ ਕਰਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ:

ipv4 <interface> add <address>/<prefix length> <gateway>

ਅਸੀਂ ਜਾਂਚਦੇ ਹਾਂ:

ਸਰਵਰ ਨਾਮ (ਹੋਸਟਨਾਮ)

ਅਸੀਂ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਸਰਵਰ ਨਾਮ ਸੈਟ ਕਰਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ:

hostname <name>

ਅਤੇ ਅਸੀਂ ਰੀਬੂਟ ਕਰਦੇ ਹਾਂ।


ਇਹ ਬੁਨਿਆਦੀ ਸੰਰਚਨਾ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ.

ਸਰਟੀਫਿਕੇਟ

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

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

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

ਕੰਮ ਕਰਨ ਲਈ ਰਿਡੰਡੈਂਸੀ ਲਈ, ਡੇਟਾਬੇਸ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ 3 ਸਰਵਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਪਰ 5 ਤੋਂ ਵੱਧ ਨਹੀਂ, ਕਿਸੇ ਵੀ ਕਲੱਸਟਰ ਦੇ ਮੈਂਬਰਾਂ ਵਿਚਕਾਰ ਵੱਧ ਤੋਂ ਵੱਧ 200 ms ਦੇ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਸਮੇਂ ਦੇ ਨਾਲ। ਇਹ ਸੀਮਾ ਕਾਲ ਬ੍ਰਿਜ ਕਲੱਸਟਰਿੰਗ ਨਾਲੋਂ ਵਧੇਰੇ ਪ੍ਰਤਿਬੰਧਿਤ ਹੈ, ਇਸਲਈ ਇਹ ਭੂਗੋਲਿਕ ਤੌਰ 'ਤੇ ਵੰਡੀਆਂ ਤੈਨਾਤੀਆਂ ਵਿੱਚ ਅਕਸਰ ਸੀਮਤ ਕਾਰਕ ਹੁੰਦੀ ਹੈ।

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

CMS ਇੱਕ ਮਾਸਟਰ ਅਤੇ ਕਈ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਾਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੇ ਨਾਲ ਇੱਕ ਪੋਸਟਗ੍ਰੇਸ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰਾਇਮਰੀ ਡਾਟਾਬੇਸ ਹੁੰਦਾ ਹੈ (“ਡੇਟਾਬੇਸ ਸਰਵਰ”)। ਕਲੱਸਟਰ ਦੇ ਬਾਕੀ ਮੈਂਬਰ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਜਾਂ "ਡਾਟਾਬੇਸ ਕਲਾਇੰਟਸ" ਹਨ।

ਇੱਕ ਡੇਟਾਬੇਸ ਕਲੱਸਟਰ ਲਈ ਇੱਕ ਸਮਰਪਿਤ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਇੱਕ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਸਰਟੀਫਿਕੇਟਾਂ ਦੁਆਰਾ ਹਸਤਾਖਰ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ, ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਅੰਦਰੂਨੀ ਪ੍ਰਾਈਵੇਟ ਸਰਟੀਫਿਕੇਟ ਅਥਾਰਟੀ। ਕਿਉਂਕਿ ਡੇਟਾਬੇਸ ਕਲੱਸਟਰ ਦਾ ਕੋਈ ਵੀ ਮੈਂਬਰ ਮਾਸਟਰ ਬਣ ਸਕਦਾ ਹੈ, ਡੇਟਾਬੇਸ ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਜੋੜੇ (ਜਨਤਕ ਅਤੇ ਪ੍ਰਾਈਵੇਟ ਕੁੰਜੀਆਂ ਵਾਲੇ) ਨੂੰ ਸਾਰੇ ਸਰਵਰਾਂ ਤੇ ਕਾਪੀ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਕਲਾਇੰਟ ਜਾਂ ਡੇਟਾਬੇਸ ਸਰਵਰ ਦੀ ਪਛਾਣ ਮੰਨ ਸਕਣ। ਇਸ ਤੋਂ ਇਲਾਵਾ, CA ਰੂਟ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਲੋਡ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾ ਸਕੇ।

ਇਸ ਲਈ, ਅਸੀਂ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਲਈ ਇੱਕ ਬੇਨਤੀ ਬਣਾਉਂਦੇ ਹਾਂ ਜੋ ਡੇਟਾਬੇਸ ਨੂੰ ਛੱਡ ਕੇ ਸਾਰੀਆਂ ਸਰਵਰ ਸੇਵਾਵਾਂ ਦੁਆਰਾ ਵਰਤੀ ਜਾਵੇਗੀ (ਇਸ ਲਈ ਇੱਕ ਵੱਖਰੀ ਬੇਨਤੀ ਹੋਵੇਗੀ) ਇੱਕ ਕਮਾਂਡ ਨਾਲ:

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

CN ਵਿੱਚ ਅਸੀਂ ਆਪਣੇ ਸਰਵਰਾਂ ਦਾ ਆਮ ਨਾਮ ਲਿਖਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਸਾਡੇ ਸਰਵਰਾਂ ਦੇ ਮੇਜ਼ਬਾਨ ਨਾਮ ਸਰਵਰ 01, ਸਰਵਰ 02, ਸਰਵਰ 03, ਫਿਰ CN ਹੋਵੇਗਾ server.example.com

ਅਸੀਂ ਬਾਕੀ ਬਚੇ ਦੋ ਸਰਵਰਾਂ 'ਤੇ ਇਸ ਫਰਕ ਨਾਲ ਅਜਿਹਾ ਕਰਦੇ ਹਾਂ ਕਿ ਕਮਾਂਡਾਂ ਵਿੱਚ ਸੰਬੰਧਿਤ "ਹੋਸਟਨਾਮ" ਸ਼ਾਮਲ ਹੋਣਗੇ।

ਅਸੀਂ ਸਰਟੀਫਿਕੇਟਾਂ ਲਈ ਦੋ ਬੇਨਤੀਆਂ ਤਿਆਰ ਕਰਦੇ ਹਾਂ ਜੋ ਡੇਟਾਬੇਸ ਸੇਵਾ ਦੁਆਰਾ ਕਮਾਂਡਾਂ ਨਾਲ ਵਰਤੇ ਜਾਣਗੇ:

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

ਜਿੱਥੇ dbclusterserver и dbclusterclient ਸਾਡੀਆਂ ਬੇਨਤੀਆਂ ਅਤੇ ਭਵਿੱਖ ਦੇ ਸਰਟੀਫਿਕੇਟਾਂ ਦੇ ਨਾਮ, ਹੋਸਟਨਾਮ1(2)(3) ਸੰਬੰਧਿਤ ਸਰਵਰਾਂ ਦੇ ਨਾਮ।

ਅਸੀਂ ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸਰਵਰ (!) 'ਤੇ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਅਸੀਂ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਸੰਬੰਧਿਤ .key ਫਾਈਲਾਂ ਨੂੰ ਦੂਜੇ ਸਰਵਰਾਂ 'ਤੇ ਅੱਪਲੋਡ ਕਰਾਂਗੇ।

AD CS ਵਿੱਚ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਮੋਡ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ

ਤੁਹਾਨੂੰ ਹਰੇਕ ਸਰਵਰ ਲਈ ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਮਿਲਾਉਣ ਦੀ ਵੀ ਲੋੜ ਹੈ।*NIX 'ਤੇ:

cat server01.cer server02.cer server03.cer > server.cer

ਵਿੰਡੋਜ਼/ਡੌਸ 'ਤੇ:

copy server01.cer + server02.cer + server03.cer  server.cer

ਅਤੇ ਹਰੇਕ ਸਰਵਰ ਤੇ ਅੱਪਲੋਡ ਕਰੋ:
1. "ਵਿਅਕਤੀਗਤ" ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ।
2. ਰੂਟ ਸਰਟੀਫਿਕੇਟ (ਵਿਚਕਾਰ ਦੇ ਨਾਲ, ਜੇਕਰ ਕੋਈ ਹੋਵੇ)।
3. ਡੇਟਾਬੇਸ ("ਸਰਵਰ" ਅਤੇ "ਕਲਾਇੰਟ") ਲਈ ਸਰਟੀਫਿਕੇਟ ਅਤੇ .ਕੁੰਜੀ ਐਕਸਟੈਂਸ਼ਨ ਵਾਲੀਆਂ ਫਾਈਲਾਂ, ਜੋ ਕਿ "ਸਰਵਰ" ਅਤੇ "ਕਲਾਇੰਟ" ਡੇਟਾਬੇਸ ਸਰਟੀਫਿਕੇਟ ਲਈ ਬੇਨਤੀ ਬਣਾਉਣ ਵੇਲੇ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ। ਇਹ ਫ਼ਾਈਲਾਂ ਸਾਰੇ ਸਰਵਰਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
4. ਤਿੰਨੋਂ "ਵਿਅਕਤੀਗਤ" ਸਰਟੀਫਿਕੇਟਾਂ ਦੀ ਫਾਈਲ।

ਨਤੀਜੇ ਵਜੋਂ, ਤੁਹਾਨੂੰ ਹਰੇਕ ਸਰਵਰ 'ਤੇ ਇਸ ਫਾਈਲ ਤਸਵੀਰ ਵਰਗਾ ਕੁਝ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ.

ਡਾਟਾਬੇਸ ਕਲੱਸਟਰ

ਹੁਣ ਜਦੋਂ ਕਿ ਤੁਹਾਡੇ ਕੋਲ CMS ਸਰਵਰਾਂ 'ਤੇ ਅੱਪਲੋਡ ਕੀਤੇ ਗਏ ਸਾਰੇ ਸਰਟੀਫਿਕੇਟ ਹਨ, ਤੁਸੀਂ ਤਿੰਨ ਨੋਡਾਂ ਦੇ ਵਿਚਕਾਰ ਡਾਟਾਬੇਸ ਕਲੱਸਟਰਿੰਗ ਨੂੰ ਕੌਂਫਿਗਰ ਅਤੇ ਸਮਰੱਥ ਕਰ ਸਕਦੇ ਹੋ। ਪਹਿਲਾ ਕਦਮ ਹੈ ਇੱਕ ਸਰਵਰ ਨੂੰ ਡੇਟਾਬੇਸ ਕਲੱਸਟਰ ਦੇ ਮਾਸਟਰ ਨੋਡ ਵਜੋਂ ਚੁਣਨਾ ਅਤੇ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੰਰਚਿਤ ਕਰਨਾ।

ਮਾਸਟਰ ਡਾਟਾਬੇਸ

ਡੇਟਾਬੇਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਵਿੱਚ ਪਹਿਲਾ ਕਦਮ ਉਹਨਾਂ ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਹੈ ਜੋ ਡੇਟਾਬੇਸ ਲਈ ਵਰਤੇ ਜਾਣਗੇ। ਇਹ ਇੱਕ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਵੇਂ ਕਿ:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

ਹੁਣ CMS ਨੂੰ ਦੱਸੀਏ ਕਿ ਕਮਾਂਡ ਨਾਲ ਡਾਟਾਬੇਸ ਕਲੱਸਟਰਿੰਗ ਲਈ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਵਰਤਣਾ ਹੈ:

database cluster localnode a

ਫਿਰ ਅਸੀਂ ਕਮਾਂਡ ਨਾਲ ਮੁੱਖ ਸਰਵਰ 'ਤੇ ਕਲੱਸਟਰ ਡੇਟਾਬੇਸ ਨੂੰ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ:

database cluster initialize

ਕਲਾਇੰਟ ਡਾਟਾਬੇਸ ਨੋਡਸ

ਅਸੀਂ ਉਹੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹਾਂ, ਸਿਰਫ ਕਮਾਂਡ ਦੀ ਬਜਾਏ ਡਾਟਾਬੇਸ ਕਲੱਸਟਰ ਸ਼ੁਰੂ ਇੱਕ ਕਮਾਂਡ ਦਿਓ ਜਿਵੇਂ:

database cluster join <ip address existing master>

ਜਿੱਥੇ CMS ਸਰਵਰ ਦਾ ip ਐਡਰੈੱਸ ਮੌਜੂਦਾ ਮਾਸਟਰ ਆਈਪੀ ਐਡਰੈੱਸ ਹੈ ਜਿਸ 'ਤੇ ਕਲੱਸਟਰ ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ ਸੀ, ਬਸ ਮਾਸਟਰ।

ਅਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਡਾ ਡੇਟਾਬੇਸ ਕਲੱਸਟਰ ਕਮਾਂਡ ਨਾਲ ਸਾਰੇ ਸਰਵਰਾਂ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ:

database cluster status

ਅਸੀਂ ਬਾਕੀ ਤੀਜੇ ਸਰਵਰ 'ਤੇ ਵੀ ਅਜਿਹਾ ਹੀ ਕਰਦੇ ਹਾਂ।

ਨਤੀਜੇ ਵਜੋਂ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਸਾਡਾ ਪਹਿਲਾ ਸਰਵਰ ਮਾਸਟਰ ਹੈ, ਬਾਕੀ ਗੁਲਾਮ ਹਨ।

ਵੈੱਬ ਐਡਮਿਨ ਸੇਵਾ

ਵੈੱਬ ਪ੍ਰਸ਼ਾਸਕ ਸੇਵਾ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ:

webadmin listen a 445

ਪੋਰਟ 445 ਨੂੰ ਚੁਣਿਆ ਗਿਆ ਸੀ ਕਿਉਂਕਿ ਪੋਰਟ 443 ਵੈੱਬ ਕਲਾਇੰਟ ਤੱਕ ਉਪਭੋਗਤਾ ਪਹੁੰਚ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ

ਅਸੀਂ ਵੈੱਬ ਐਡਮਿਨ ਸੇਵਾ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਫਾਈਲਾਂ ਨਾਲ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਕੌਂਫਿਗਰ ਕਰਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ:

webadmin certs <keyfile> <certificatefile> <ca bundle>

ਅਤੇ ਕਮਾਂਡ ਨਾਲ ਵੈੱਬ ਐਡਮਿਨ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ:

webadmin enable

ਜੇਕਰ ਸਭ ਕੁਝ ਠੀਕ-ਠਾਕ ਹੈ, ਤਾਂ ਅਸੀਂ ਸਫਲਤਾ ਦੀਆਂ ਲਾਈਨਾਂ ਪ੍ਰਾਪਤ ਕਰਾਂਗੇ ਜੋ ਇਹ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਕਿ ਵੈੱਬ ਐਡਮਿਨ ਨੈੱਟਵਰਕ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਲਈ ਸਹੀ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਅਸੀਂ ਇੱਕ ਵੈਬ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੇਵਾ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਅਤੇ ਵੈਬ ਪ੍ਰਸ਼ਾਸਕ ਦਾ ਪਤਾ ਦਰਜ ਕਰਦੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ: cms.example.com: 445

ਕਾਲ ਬ੍ਰਿਜ ਕਲੱਸਟਰ

ਕਾਲ ਬ੍ਰਿਜ ਹਰ CMS ਤੈਨਾਤੀ ਵਿੱਚ ਮੌਜੂਦ ਇੱਕੋ-ਇੱਕ ਸੇਵਾ ਹੈ। ਕਾਲ ਬ੍ਰਿਜ ਮੁੱਖ ਕਾਨਫਰੰਸਿੰਗ ਵਿਧੀ ਹੈ। ਇਹ ਇੱਕ SIP ਇੰਟਰਫੇਸ ਵੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਕਾਲਾਂ ਨੂੰ ਇਸ ਦੁਆਰਾ ਜਾਂ ਇਸ ਤੋਂ ਰੂਟ ਕੀਤਾ ਜਾ ਸਕੇ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਿਸਕੋ ਯੂਨੀਫਾਈਡ ਸੀ.ਐਮ.

ਹੇਠਾਂ ਵਰਣਿਤ ਕਮਾਂਡਾਂ ਨੂੰ ਹਰੇਕ ਸਰਵਰ 'ਤੇ ਢੁਕਵੇਂ ਸਰਟੀਫਿਕੇਟਾਂ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਸ ਤਰ੍ਹਾਂ:

ਅਸੀਂ ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਕਾਲ ਬ੍ਰਿਜ ਸੇਵਾ ਨਾਲ ਜੋੜਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

ਅਸੀਂ ਕਾਲਬ੍ਰਿਜ ਸੇਵਾਵਾਂ ਨੂੰ ਉਸ ਇੰਟਰਫੇਸ ਨਾਲ ਜੋੜਦੇ ਹਾਂ ਜਿਸਦੀ ਸਾਨੂੰ ਕਮਾਂਡ ਨਾਲ ਲੋੜ ਹੁੰਦੀ ਹੈ:

callbridge listen a

ਅਤੇ ਕਮਾਂਡ ਨਾਲ ਸੇਵਾ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ:

callbridge restart

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

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

1. ਵੈੱਬ ਰਾਹੀਂ ਸੰਰਚਨਾ > ਕਲੱਸਟਰ 'ਤੇ ਜਾਓ।
2.ਇੰ ਕਾਲ ਬ੍ਰਿਜ ਪਛਾਣ ਇੱਕ ਵਿਲੱਖਣ ਨਾਮ ਦੇ ਰੂਪ ਵਿੱਚ, ਸਰਵਰ ਨਾਮ ਦੇ ਅਨੁਸਾਰੀ ਕਾਲਬ੍ਰਿਜ [01,02,03] ਦਰਜ ਕਰੋ। ਇਹ ਨਾਂ ਆਪਹੁਦਰੇ ਹਨ, ਪਰ ਇਸ ਕਲੱਸਟਰ ਲਈ ਵਿਲੱਖਣ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਉਹ ਕੁਦਰਤ ਵਿੱਚ ਵਰਣਨਯੋਗ ਹਨ ਕਿਉਂਕਿ ਉਹ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਉਹ ਸਰਵਰ ਪਛਾਣਕਰਤਾ [01,02,03] ਹਨ।
3.ਬੀ ਕਲੱਸਟਰਡ ਕਾਲ ਬ੍ਰਿਜ ਕਲੱਸਟਰ ਵਿੱਚ ਸਾਡੇ ਸਰਵਰਾਂ ਦੇ ਵੈਬ ਪ੍ਰਸ਼ਾਸਕ URL ਦਾਖਲ ਕਰੋ, CMS[01,02,03].example.com:445, ਐਡਰੈੱਸ ਖੇਤਰ ਵਿੱਚ। ਪੋਰਟ ਨਿਸ਼ਚਿਤ ਕਰਨਾ ਯਕੀਨੀ ਬਣਾਓ। ਤੁਸੀਂ ਪੀਅਰ ਲਿੰਕ SIP ਡੋਮੇਨ ਨੂੰ ਖਾਲੀ ਛੱਡ ਸਕਦੇ ਹੋ।
4. ਹਰੇਕ ਸਰਵਰ ਦੇ ਕਾਲਬ੍ਰਿਜ ਟਰੱਸਟ ਵਿੱਚ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਸ਼ਾਮਲ ਕਰੋ, ਜਿਸ ਦੀ ਫਾਈਲ ਵਿੱਚ ਸਾਡੇ ਸਰਵਰਾਂ ਦੇ ਸਾਰੇ ਸਰਟੀਫਿਕੇਟ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਜਿਸ ਨੂੰ ਅਸੀਂ ਇਸ ਫਾਈਲ ਵਿੱਚ ਸ਼ੁਰੂ ਵਿੱਚ ਮਿਲਾ ਦਿੱਤਾ ਸੀ, ਜਿਵੇਂ ਕਿ ਇੱਕ ਕਮਾਂਡ ਨਾਲ:

callbridge trust cluster <trusted cluster certificate bundle>

ਅਤੇ ਕਮਾਂਡ ਨਾਲ ਸੇਵਾ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ:

callbridge restart

ਨਤੀਜੇ ਵਜੋਂ, ਹਰੇਕ ਸਰਵਰ 'ਤੇ ਤੁਹਾਨੂੰ ਇਹ ਤਸਵੀਰ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ:

XMPP ਕਲੱਸਟਰ

CMS ਵਿੱਚ XMPP ਸੇਵਾ ਦੀ ਵਰਤੋਂ CMA WebRTC ਵੈੱਬ ਕਲਾਇੰਟ ਸਮੇਤ, Cisco Meeting Apps (CMA) ਲਈ ਸਾਰੇ ਰਜਿਸਟ੍ਰੇਸ਼ਨ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਕਾਲ ਬ੍ਰਿਜ ਖੁਦ ਵੀ ਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਉਦੇਸ਼ਾਂ ਲਈ ਇੱਕ XMPP ਕਲਾਇੰਟ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਲਈ ਇਸਨੂੰ ਹੋਰ ਕਲਾਇੰਟਸ ਵਾਂਗ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। XMPP ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਜੋ ਸੰਸਕਰਣ 2.1 ਤੋਂ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਸਮਰਥਿਤ ਹੈ

ਹੇਠਾਂ ਵਰਣਿਤ ਕਮਾਂਡਾਂ ਨੂੰ ਹਰੇਕ ਸਰਵਰ 'ਤੇ ਢੁਕਵੇਂ ਸਰਟੀਫਿਕੇਟਾਂ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇਸ ਤਰ੍ਹਾਂ:

ਅਸੀਂ ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ XMPP ਸੇਵਾ ਨਾਲ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਜੋੜਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

ਫਿਰ ਕਮਾਂਡ ਨਾਲ ਸੁਣਨ ਵਾਲੇ ਇੰਟਰਫੇਸ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ:

xmpp listen a

XMPP ਸੇਵਾ ਲਈ ਇੱਕ ਵਿਲੱਖਣ ਡੋਮੇਨ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਲੌਗਇਨ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਜਦੋਂ ਇੱਕ ਉਪਭੋਗਤਾ CMA ਐਪ (ਜਾਂ WebRTC ਕਲਾਇੰਟ ਦੁਆਰਾ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲੌਗਇਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ userID@logindomain ਦਾਖਲ ਕਰਦੇ ਹਨ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਇਹ userid@ ਹੋਵੇਗਾਸੰਰਚਨਾ.example.com. ਇਹ ਸਿਰਫ਼ example.com ਕਿਉਂ ਨਹੀਂ ਹੈ? ਸਾਡੀ ਖਾਸ ਤੈਨਾਤੀ ਵਿੱਚ, ਅਸੀਂ ਆਪਣਾ ਯੂਨੀਫਾਈਡ CM ਡੋਮੇਨ ਚੁਣਿਆ ਹੈ ਜਿਸਨੂੰ Jabber ਉਪਭੋਗਤਾ ਯੂਨੀਫਾਈਡ CM ਵਿੱਚ example.com ਦੇ ਤੌਰ 'ਤੇ ਵਰਤਣਗੇ, ਇਸਲਈ ਸਾਨੂੰ CMS ਉਪਭੋਗਤਾਵਾਂ ਲਈ SIP ਡੋਮੇਨਾਂ ਰਾਹੀਂ CMS ਤੱਕ ਅਤੇ ਕਾਲਾਂ ਨੂੰ ਰੂਟ ਕਰਨ ਲਈ ਇੱਕ ਵੱਖਰੇ ਡੋਮੇਨ ਦੀ ਲੋੜ ਹੈ।

ਇੱਕ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ XMPP ਡੋਮੇਨ ਸੈਟ ਅਪ ਕਰੋ ਜਿਵੇਂ ਕਿ:

xmpp domain <domain>

ਅਤੇ ਕਮਾਂਡ ਨਾਲ XMPP ਸੇਵਾ ਨੂੰ ਸਮਰੱਥ ਕਰੋ:

xmpp enable

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

ਹੁਣ ਸਾਨੂੰ ਤਿੰਨ ਕਾਲ ਬ੍ਰਿਜਾਂ callbridge01, callbridge02 ਅਤੇ callbridge03 ਨਾਲ ਪਹਿਲੇ ਸਰਵਰ 'ਤੇ XMPP ਸੇਵਾ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਹਰੇਕ ਖਾਤੇ ਨੂੰ ਬੇਤਰਤੀਬੇ ਪਾਸਵਰਡ ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਣਗੇ। ਉਹਨਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਇਸ XMPP ਸਰਵਰ ਵਿੱਚ ਲੌਗ ਇਨ ਕਰਨ ਲਈ ਦੂਜੇ ਕਾਲ ਬ੍ਰਿਜ ਸਰਵਰਾਂ 'ਤੇ ਦਾਖਲ ਕੀਤਾ ਜਾਵੇਗਾ। ਹੇਠ ਲਿਖੀਆਂ ਕਮਾਂਡਾਂ ਦਰਜ ਕਰੋ:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਕਮਾਂਡ ਨਾਲ ਕੀ ਹੋਇਆ:

xmpp callbridge list

ਹੇਠਾਂ ਦੱਸੇ ਗਏ ਕਦਮਾਂ ਤੋਂ ਬਾਅਦ ਬਾਕੀ ਸਰਵਰਾਂ 'ਤੇ ਬਿਲਕੁਲ ਉਹੀ ਤਸਵੀਰ ਦਿਖਾਈ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ।

ਅੱਗੇ, ਅਸੀਂ ਬਾਕੀ ਦੋ ਸਰਵਰਾਂ 'ਤੇ ਬਿਲਕੁਲ ਉਹੀ ਸੈਟਿੰਗਾਂ ਜੋੜਦੇ ਹਾਂ, ਸਿਰਫ਼ ਕਮਾਂਡਾਂ ਨਾਲ

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

ਅਸੀਂ ਸੀਕਰੇਟ ਨੂੰ ਬਹੁਤ ਧਿਆਨ ਨਾਲ ਜੋੜਦੇ ਹਾਂ ਤਾਂ ਕਿ, ਉਦਾਹਰਨ ਲਈ, ਇਸ ਵਿੱਚ ਕੋਈ ਵਾਧੂ ਸਪੇਸ ਨਾ ਹੋਵੇ.


ਨਤੀਜੇ ਵਜੋਂ, ਹਰੇਕ ਸਰਵਰ ਦੀ ਇੱਕੋ ਤਸਵੀਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ:

ਅੱਗੇ, ਕਲੱਸਟਰ ਦੇ ਸਾਰੇ ਸਰਵਰਾਂ 'ਤੇ, ਅਸੀਂ ਸਾਰੇ ਤਿੰਨ ਸਰਟੀਫਿਕੇਟਾਂ ਵਾਲੀ ਫਾਈਲ ਨੂੰ ਭਰੋਸੇ ਵਿੱਚ ਨਿਸ਼ਚਿਤ ਕਰਦੇ ਹਾਂ, ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਕਮਾਂਡ ਨਾਲ ਪਹਿਲਾਂ ਬਣਾਈ ਗਈ ਸੀ:

xmpp cluster trust <trust bundle>

ਅਸੀਂ ਕਮਾਂਡ ਨਾਲ ਸਾਰੇ ਕਲੱਸਟਰ ਸਰਵਰਾਂ 'ਤੇ xmpp ਕਲੱਸਟਰ ਮੋਡ ਨੂੰ ਸਮਰੱਥ ਕਰਦੇ ਹਾਂ:

xmpp cluster enable

ਕਲੱਸਟਰ ਦੇ ਪਹਿਲੇ ਸਰਵਰ 'ਤੇ, ਅਸੀਂ ਕਮਾਂਡ ਨਾਲ ਇੱਕ xmpp ਕਲੱਸਟਰ ਬਣਾਉਣ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਦੇ ਹਾਂ:

xmpp cluster initialize

ਦੂਜੇ ਸਰਵਰਾਂ 'ਤੇ, ਕਮਾਂਡ ਨਾਲ xmpp ਵਿੱਚ ਇੱਕ ਕਲੱਸਟਰ ਸ਼ਾਮਲ ਕਰੋ ਜਿਵੇਂ:

xmpp cluster join <ip address head xmpp server>

ਅਸੀਂ ਹਰੇਕ ਸਰਵਰ 'ਤੇ ਕਮਾਂਡਾਂ ਨਾਲ ਹਰੇਕ ਸਰਵਰ 'ਤੇ XMPP ਕਲੱਸਟਰ ਬਣਾਉਣ ਦੀ ਸਫਲਤਾ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ:

xmpp status
xmpp cluster status

ਪਹਿਲਾ ਸਰਵਰ:

ਦੂਜਾ ਸਰਵਰ:

ਤੀਜਾ ਸਰਵਰ:

ਕਾਲ ਬ੍ਰਿਜ ਨੂੰ XMPP ਨਾਲ ਕਨੈਕਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

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

ਹਰੇਕ ਸਰਵਰ 'ਤੇ, ਕੌਨਫਿਗਰੇਸ਼ਨ> ਜਨਰਲ ਅਤੇ ਖੇਤਰ ਵਿੱਚ ਜਾਓ ਵਿਲੱਖਣ ਕਾਲ ਬ੍ਰਿਜ ਦਾ ਨਾਮ ਸਰਵਰ ਕਾਲ ਬ੍ਰਿਜ ਨਾਲ ਸੰਬੰਧਿਤ ਵਿਲੱਖਣ ਨਾਮ ਲਿਖੋ ਕਾਲਬ੍ਰਿਜ[01,02,03]... ਖੇਤ ਵਿੱਚ ਨੂੰ ਡੋਮੇਨ conf.example.ru ਅਤੇ ਅਨੁਸਾਰੀ ਪਾਸਵਰਡ, ਤੁਸੀਂ ਉਹਨਾਂ 'ਤੇ ਜਾਸੂਸੀ ਕਰ ਸਕਦੇ ਹੋ
ਕਮਾਂਡ ਨਾਲ ਕਲੱਸਟਰ ਵਿੱਚ ਕਿਸੇ ਵੀ ਸਰਵਰ ਉੱਤੇ:

xmpp callbridge list

"ਸਰਵਰ" ਖੇਤਰ ਨੂੰ ਖਾਲੀ ਛੱਡੋ ਕਾਲਬ੍ਰਿਜ ਲਈ ਇੱਕ DNS SRV ਲੁੱਕਅੱਪ ਕਰੇਗਾ _xmpp-component._tcp.conf.example.comਇੱਕ ਉਪਲਬਧ XMPP ਸਰਵਰ ਲੱਭਣ ਲਈ। ਕਾਲਬ੍ਰਿਜ ਨੂੰ XMPP ਨਾਲ ਜੋੜਨ ਲਈ IP ਪਤੇ ਹਰੇਕ ਸਰਵਰ 'ਤੇ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ, ਇਹ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਰਿਕਾਰਡ ਬੇਨਤੀ ਨੂੰ ਕਿਹੜੇ ਮੁੱਲ ਵਾਪਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ _xmpp-component._tcp.conf.example.com ਕਾਲਬ੍ਰਿਜ, ਜੋ ਬਦਲੇ ਵਿੱਚ ਦਿੱਤੇ ਗਏ DNS ਰਿਕਾਰਡ ਲਈ ਤਰਜੀਹੀ ਸੈਟਿੰਗਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਅੱਗੇ, ਇਹ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਸਥਿਤੀ > ਜਨਰਲ 'ਤੇ ਜਾਓ ਕਿ ਕਾਲ ਬ੍ਰਾਈਡ ਸੇਵਾ XMPP ਸੇਵਾ ਨਾਲ ਸਫਲਤਾਪੂਰਵਕ ਜੁੜੀ ਹੈ ਜਾਂ ਨਹੀਂ।

ਵੈੱਬ ਬ੍ਰਿਜ

ਕਲੱਸਟਰ ਵਿੱਚ ਹਰੇਕ ਸਰਵਰ 'ਤੇ, ਕਮਾਂਡ ਨਾਲ ਵੈੱਬ ਬ੍ਰਿਜ ਸੇਵਾ ਨੂੰ ਸਮਰੱਥ ਬਣਾਓ:

webbridge listen a:443

ਅਸੀਂ ਵੈੱਬ ਬ੍ਰਿਜ ਸੇਵਾ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਫਾਈਲਾਂ ਨਾਲ ਇੱਕ ਕਮਾਂਡ ਨਾਲ ਸੰਰਚਿਤ ਕਰਦੇ ਹਾਂ ਜਿਵੇਂ ਕਿ:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

ਵੈੱਬ ਬ੍ਰਿਜ HTTPS ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇਹ HTTP ਨੂੰ HTTPS ਤੇ ਰੀਡਾਇਰੈਕਟ ਕਰੇਗਾ ਜੇਕਰ "http-ਰੀਡਾਇਰੈਕਟ" ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।
HTTP ਰੀਡਾਇਰੈਕਸ਼ਨ ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਲਈ, ਹੇਠ ਦਿੱਤੀ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰੋ:

webbridge http-redirect enable

ਕਾਲ ਬ੍ਰਿਜ ਨੂੰ ਇਹ ਦੱਸਣ ਲਈ ਕਿ ਵੈੱਬ ਬ੍ਰਿਜ ਕਾਲ ਬ੍ਰਿਜ ਤੋਂ ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦਾ ਹੈ, ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰੋ:

webbridge trust <certfile>

ਜਿੱਥੇ ਇਹ ਇੱਕ ਫਾਈਲ ਹੈ ਜਿਸ ਵਿੱਚ ਕਲੱਸਟਰ ਵਿੱਚ ਹਰੇਕ ਸਰਵਰ ਤੋਂ ਤਿੰਨੇ ਸਰਟੀਫਿਕੇਟ ਹਨ।

ਇਹ ਤਸਵੀਰ ਕਲੱਸਟਰ ਦੇ ਹਰੇਕ ਸਰਵਰ 'ਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।


ਹੁਣ ਸਾਨੂੰ "ਐਪਡਮਿਨ" ਰੋਲ ਵਾਲਾ ਇੱਕ ਉਪਭੋਗਤਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਸਾਨੂੰ ਇਸਦੀ ਲੋੜ ਹੈ ਤਾਂ ਜੋ ਅਸੀਂ ਆਪਣੇ ਕਲੱਸਟਰ(!) ਨੂੰ ਸੰਰਚਿਤ ਕਰ ਸਕੀਏ, ਨਾ ਕਿ ਕਲੱਸਟਰ ਵਿੱਚ ਹਰੇਕ ਸਰਵਰ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਇਸ ਤਰ੍ਹਾਂ ਸੈਟਿੰਗਾਂ ਦੇ ਬਾਵਜੂਦ ਹਰੇਕ ਸਰਵਰ 'ਤੇ ਬਰਾਬਰ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ। ਤੱਥ ਕਿ ਉਹ ਇੱਕ ਵਾਰ ਬਣਾਏ ਜਾਣਗੇ।


ਹੋਰ ਸੈੱਟਅੱਪ ਲਈ ਅਸੀਂ ਵਰਤਾਂਗੇ ਪੋਸਟਮੈਨ.

ਅਧਿਕਾਰ ਲਈ, ਅਧਿਕਾਰ ਭਾਗ ਵਿੱਚ ਮੂਲ ਦੀ ਚੋਣ ਕਰੋ

CMS ਸਰਵਰ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕਮਾਂਡਾਂ ਭੇਜਣ ਲਈ, ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੀ ਏਨਕੋਡਿੰਗ ਸੈੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ

ਅਸੀਂ ਕਮਾਂਡ ਨਾਲ ਵੈਬਬ੍ਰਿਜ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਪੋਸਟ ਪੈਰਾਮੀਟਰ ਦੇ ਨਾਲ URL ਨੂੰ ਅਤੇ ਅਰਥ cms.example.com



ਵੈਬਬ੍ਰਿਜ ਵਿੱਚ ਹੀ, ਅਸੀਂ ਲੋੜੀਂਦੇ ਮਾਪਦੰਡਾਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਾਂ: ਮਹਿਮਾਨ ਪਹੁੰਚ, ਸੁਰੱਖਿਅਤ ਪਹੁੰਚ, ਆਦਿ।

ਬ੍ਰਿਜ ਸਮੂਹਾਂ ਨੂੰ ਕਾਲ ਕਰੋ

ਮੂਲ ਰੂਪ ਵਿੱਚ, CMS ਹਮੇਸ਼ਾ ਇਸ ਲਈ ਉਪਲਬਧ ਕਾਨਫਰੰਸਿੰਗ ਸਰੋਤਾਂ ਦੀ ਸਭ ਤੋਂ ਕੁਸ਼ਲ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ ਹੈ।

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

ਇਹ ਸਮੱਸਿਆਵਾਂ ਕਾਲ ਬ੍ਰਿਜ ਗਰੁੱਪ ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੱਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ Cisco Meeting Server ਸੌਫਟਵੇਅਰ ਦੇ ਸੰਸਕਰਣ 2.1 ਵਿੱਚ ਪੇਸ਼ ਕੀਤੀ ਗਈ ਸੀ ਅਤੇ WebRTC ਭਾਗੀਦਾਰਾਂ ਸਮੇਤ, ਇਨਬਾਉਂਡ ਅਤੇ ਆਊਟਬਾਊਂਡ ਸਿਸਕੋ ਮੀਟਿੰਗ ਐਪ (CMA) ਕਾਲਾਂ ਲਈ ਲੋਡ ਸੰਤੁਲਨ ਨੂੰ ਸਮਰਥਨ ਦੇਣ ਲਈ ਵਧਾਇਆ ਗਿਆ ਹੈ।

ਪੁਨਰ-ਕਨੈਕਸ਼ਨ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਹਰੇਕ ਕਾਲ ਬ੍ਰਿਜ ਲਈ ਤਿੰਨ ਸੰਰਚਨਾਯੋਗ ਲੋਡ ਸੀਮਾਵਾਂ ਪੇਸ਼ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ:

ਲੋਡ ਸੀਮਾ - ਇਹ ਕਿਸੇ ਖਾਸ ਕਾਲ ਬ੍ਰਿਜ ਲਈ ਅਧਿਕਤਮ ਸੰਖਿਆਤਮਕ ਲੋਡ ਹੈ। ਹਰੇਕ ਪਲੇਟਫਾਰਮ ਦੀ ਇੱਕ ਸਿਫ਼ਾਰਸ਼ੀ ਲੋਡ ਸੀਮਾ ਹੁੰਦੀ ਹੈ, ਜਿਵੇਂ ਕਿ CMS96000 ਲਈ 1000 ਅਤੇ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਲਈ 1.25 GHz ਪ੍ਰਤੀ vCPU। ਵੱਖ-ਵੱਖ ਕਾਲਾਂ ਪ੍ਰਤੀਭਾਗੀ ਦੇ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਅਤੇ ਫਰੇਮ ਰੇਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ ਕੁਝ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ।
NewConferenceLoadLimitBasisPoints (ਡਿਫੌਲਟ 50% ਲੋਡ ਲਿਮਿਟ) - ਸਰਵਰ ਲੋਡ ਸੀਮਾ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਨਵੀਆਂ ਕਾਨਫਰੰਸਾਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਮੌਜੂਦਾ ਕਾਨਫਰੰਸ ਲੋਡ ਸੀਮਾ ਬੇਸਿਸ ਪੁਆਇੰਟਸ (ਲੋਡ ਲਿਮਿਟ ਦਾ ਡਿਫੌਲਟ 80%) - ਸਰਵਰ ਲੋਡ ਮੁੱਲ ਜਿਸ ਤੋਂ ਬਾਅਦ ਮੌਜੂਦਾ ਕਾਨਫਰੰਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਵਾਲੇ ਭਾਗੀਦਾਰਾਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ।

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

ਇਹ ਪੈਰਾਮੀਟਰ ਇੱਥੇ ਕੌਂਫਿਗਰ ਕੀਤੇ ਗਏ ਹਨ: cms.example.com:445/api/v1/system/configuration/cluster

ਅੱਗੇ, ਅਸੀਂ ਹਰੇਕ ਕਾਲਬ੍ਰਿਜ ਨੂੰ ਸੰਕੇਤ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹ ਕਿਸ ਕਾਲਬ੍ਰਿਜ ਸਮੂਹ ਨਾਲ ਸਬੰਧਤ ਹੈ:

ਪਹਿਲਾ ਕਾਲਬ੍ਰਿਜ

ਦੂਜਾ ਕਾਲਬ੍ਰਿਜ

ਤੀਜਾ ਕਾਲਬ੍ਰਿਜ


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

ਕਿਰਿਆਸ਼ੀਲ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਆਯਾਤ ਕਰਨਾ

ਵੈੱਬ ਐਡਮਿਨ ਸੇਵਾ ਵਿੱਚ ਇੱਕ LDAP ਸੰਰਚਨਾ ਸੈਕਸ਼ਨ ਹੈ, ਪਰ ਇਹ ਗੁੰਝਲਦਾਰ ਸੰਰਚਨਾ ਵਿਕਲਪ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਾਣਕਾਰੀ ਕਲੱਸਟਰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਇਸਲਈ ਸੰਰਚਨਾ ਕਰਨੀ ਪਵੇਗੀ, ਜਾਂ ਤਾਂ ਵੈੱਬ ਇੰਟਰਫੇਸ ਦੁਆਰਾ, ਜਾਂ ਇਸ ਦੁਆਰਾ ਹਰੇਕ ਸਰਵਰ 'ਤੇ ਹੱਥੀਂ। API, ਅਤੇ ਇਸ ਲਈ ਅਸੀਂ "ਤਿੰਨ ਵਾਰ "ਉੱਠੋ ਨਹੀਂ" ਅਸੀਂ ਅਜੇ ਵੀ API ਦੁਆਰਾ ਡੇਟਾ ਸੈਟ ਕਰਾਂਗੇ।

ਪਹੁੰਚ ਕਰਨ ਲਈ URL ਦੀ ਵਰਤੋਂ ਕਰਨਾ cms01.example.com:445/api/v1/ldapServers ਇੱਕ LDAP ਸਰਵਰ ਆਬਜੈਕਟ ਬਣਾਉਂਦੇ ਹਨ, ਪੈਰਾਮੀਟਰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋਏ ਜਿਵੇਂ ਕਿ:

• ਸਰਵਰ ਆਈ.ਪੀ
• ਪੋਰਟ ਨੰਬਰ
• ਉਪਯੋਗਕਰਤਾ ਨਾਮ
• ਪਾਸਵਰਡ
• ਸੁਰੱਖਿਅਤ

ਸੁਰੱਖਿਅਤ - ਪੋਰਟ ਦੇ ਆਧਾਰ 'ਤੇ ਸਹੀ ਜਾਂ ਗਲਤ ਦੀ ਚੋਣ ਕਰੋ, 389 - ਸੁਰੱਖਿਅਤ ਨਹੀਂ, 636 - ਸੁਰੱਖਿਅਤ।


ਸਿਸਕੋ ਮੀਟਿੰਗ ਸਰਵਰ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ LDAP ਸਰੋਤ ਮਾਪਦੰਡਾਂ ਦੀ ਮੈਪਿੰਗ।
LDAP ਮੈਪਿੰਗ LDAP ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ CMS ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਮੈਪ ਕਰਦੀ ਹੈ। ਅਸਲ ਗੁਣ:

• jidMapping
• ਨਾਮ ਮੈਪਿੰਗ
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

ਗੁਣਾਂ ਦਾ ਵੇਰਵਾJID CMS ਵਿੱਚ ਉਪਭੋਗਤਾ ਦੀ ਲੌਗਇਨ ਆਈਡੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਕਿਉਂਕਿ ਇਹ ਇੱਕ Microsoft ਐਕਟਿਵ ਡਾਇਰੈਕਟਰੀ LDAP ਸਰਵਰ ਹੈ, CMS JID LDAP ਵਿੱਚ sAMAccountName ਨਾਲ ਮੈਪ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾ ਦੀ ਐਕਟਿਵ ਡਾਇਰੈਕਟਰੀ ਲੌਗਇਨ ਆਈਡੀ ਹੈ। ਇਹ ਵੀ ਨੋਟ ਕਰੋ ਕਿ ਤੁਸੀਂ sAMAccountName ਲੈਂਦੇ ਹੋ ਅਤੇ ਇਸਦੇ ਅੰਤ ਵਿੱਚ ਡੋਮੇਨ conf.pod6.cms.lab ਜੋੜਦੇ ਹੋ ਕਿਉਂਕਿ ਇਹ ਉਹ ਲੌਗਇਨ ਹੈ ਜੋ ਤੁਹਾਡੇ ਉਪਭੋਗਤਾ CMS ਵਿੱਚ ਲੌਗਇਨ ਕਰਨ ਲਈ ਵਰਤਣਗੇ।

ਨਾਮ ਮੈਪਿੰਗ ਐਕਟਿਵ ਡਾਇਰੈਕਟਰੀ ਡਿਸਪਲੇਨਾਮ ਫੀਲਡ ਵਿੱਚ ਮੌਜੂਦ ਉਪਭੋਗਤਾ ਦੇ CMS ਨਾਮ ਖੇਤਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।

coSpaceNameMapping ਡਿਸਪਲੇਨਾਮ ਫੀਲਡ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ CMS ਸਪੇਸ ਨਾਮ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ, coSpaceUriMapping ਵਿਸ਼ੇਸ਼ਤਾ ਦੇ ਨਾਲ, ਹਰੇਕ ਉਪਭੋਗਤਾ ਲਈ ਇੱਕ ਸਪੇਸ ਬਣਾਉਣ ਲਈ ਲੋੜੀਂਦੀ ਹੈ।

coSpaceUriMapping ਉਪਭੋਗਤਾ ਦੀ ਨਿੱਜੀ ਸਪੇਸ ਨਾਲ ਜੁੜੇ URI ਦੇ ਉਪਭੋਗਤਾ ਹਿੱਸੇ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਕੁਝ ਡੋਮੇਨਾਂ ਨੂੰ ਸਪੇਸ ਵਿੱਚ ਡਾਇਲ ਕਰਨ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਉਪਭੋਗਤਾ ਭਾਗ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਡੋਮੇਨ ਲਈ ਇਸ ਖੇਤਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਤਾਂ ਕਾਲ ਨੂੰ ਉਸ ਉਪਭੋਗਤਾ ਦੀ ਸਪੇਸ ਵਿੱਚ ਭੇਜਿਆ ਜਾਵੇਗਾ।

coSpaceSecondaryUriMapping ਸਪੇਸ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਇੱਕ ਦੂਜੀ URI ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਸਦੀ ਵਰਤੋਂ coSpaceUriMapping ਪੈਰਾਮੀਟਰ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਅਲਫਾਨਿਊਮੇਰਿਕ URI ਦੇ ਵਿਕਲਪ ਵਜੋਂ ਆਯਾਤ ਕੀਤੇ ਉਪਭੋਗਤਾ ਦੀ ਸਪੇਸ ਵਿੱਚ ਕਾਲਾਂ ਨੂੰ ਰੂਟਿੰਗ ਕਰਨ ਲਈ ਇੱਕ ਸੰਖਿਆਤਮਕ ਉਪਨਾਮ ਜੋੜਨ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

LDAP ਸਰਵਰ ਅਤੇ LDAP ਮੈਪਿੰਗ ਸੰਰਚਿਤ ਹਨ। ਹੁਣ ਤੁਹਾਨੂੰ ਇੱਕ LDAP ਸਰੋਤ ਬਣਾ ਕੇ ਉਹਨਾਂ ਨੂੰ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ।

ਪਹੁੰਚ ਕਰਨ ਲਈ URL ਦੀ ਵਰਤੋਂ ਕਰਨਾ cms01.example.com:445/api/v1/ldapSource ਇੱਕ LDAP ਸਰੋਤ ਆਬਜੈਕਟ ਬਣਾਉਂਦਾ ਹੈ, ਪੈਰਾਮੀਟਰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ:

• ਸਰਵਰ
• ਮੈਪਿੰਗ
• baseDn
• ਫਿਲਟਰ

ਹੁਣ ਜਦੋਂ ਕਿ LDAP ਸੰਰਚਨਾ ਪੂਰੀ ਹੋ ਗਈ ਹੈ, ਤੁਸੀਂ ਦਸਤੀ ਸਮਕਾਲੀ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ ਹੋ।

ਅਸੀਂ ਇਸਨੂੰ ਜਾਂ ਤਾਂ ਹਰੇਕ ਸਰਵਰ ਦੇ ਵੈੱਬ ਇੰਟਰਫੇਸ ਵਿੱਚ ਕਲਿੱਕ ਕਰਕੇ ਕਰਦੇ ਹਾਂ ਹੁਣ ਸਿੰਕ ਕਰੋ ਅਧਿਆਇ ਵਿਚ ਐਕਟਿਵ ਡਾਇਰੈਕਟਰੀ


ਜਾਂ ਕਮਾਂਡ ਨਾਲ API ਰਾਹੀਂ ਪੋਸਟ ਪਹੁੰਚ ਕਰਨ ਲਈ URL ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ cms01.example.com:445/api/v1/ldapSyncs

ਐਡ-ਹਾਕ ਕਾਨਫਰੰਸਾਂ

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

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

ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਯੂਨੀਫਾਈਡ CM ਨੂੰ ਕਾਲ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਲਈ API ਕ੍ਰੇਡੇੰਸ਼ਿਅਲਸ ਅਤੇ ਸੇਵਾ ਦੇ WebAdmin ਪਤੇ/ਪੋਰਟ ਦੇ ਨਾਲ-ਨਾਲ SIP ਟਰੰਕ ਨੂੰ ਸਿੱਧੇ CMS ਸਰਵਰ 'ਤੇ ਕੌਂਫਿਗਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਜੇਕਰ ਲੋੜ ਹੋਵੇ, CUCM ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ CMS ਵਿੱਚ ਇੱਕ ਸਪੇਸ ਬਣਾ ਸਕਦਾ ਹੈ ਤਾਂ ਜੋ ਹਰੇਕ ਕਾਲ CMS ਤੱਕ ਪਹੁੰਚ ਸਕੇ ਅਤੇ ਇਨਕਮਿੰਗ ਕਾਲ ਨਿਯਮ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜੋ ਸਪੇਸ ਲਈ ਹੈ।

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

SIP ਸੁਰੱਖਿਆ ਪ੍ਰੋਫਾਈਲ:


ਤਣੇ:


ਹਰ ਤਣਾ ਇੱਕੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:




ਕਾਨਫਰੰਸ ਬ੍ਰਿਜ


ਹਰੇਕ ਕਾਨਫਰੰਸ ਬ੍ਰਿਜ ਇੱਕੋ ਜਿਹਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:


ਰੂਟ ਗਰੁੱਪ


ਰੂਟ ਸੂਚੀ


ਮੀਡੀਆ ਸਰੋਤ ਸਮੂਹ


ਮੀਡੀਆ ਸਰੋਤ ਸਮੂਹ ਸੂਚੀ

ਕਾਲ ਨਿਯਮ

ਵਧੇਰੇ ਉੱਨਤ ਕਾਲ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀਆਂ ਜਿਵੇਂ ਕਿ ਯੂਨੀਫਾਈਡ ਸੀਐਮ ਜਾਂ ਐਕਸਪ੍ਰੈਸਵੇਅ ਦੇ ਉਲਟ, ਸੀਐਮਐਸ ਸਿਰਫ ਨਵੀਆਂ ਕਾਲਾਂ ਲਈ SIP ਬੇਨਤੀ-ਯੂਆਰਆਈ ਖੇਤਰ ਵਿੱਚ ਡੋਮੇਨ ਨੂੰ ਵੇਖਦਾ ਹੈ। ਇਸ ਲਈ ਜੇਕਰ SIP INVITE sip ਲਈ ਹੈ: [ਈਮੇਲ ਸੁਰੱਖਿਅਤ]CMS ਸਿਰਫ਼ domain.com ਦੀ ਪਰਵਾਹ ਕਰਦਾ ਹੈ। CMS ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਇਹਨਾਂ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਕਾਲ ਨੂੰ ਕਿੱਥੇ ਰੂਟ ਕਰਨਾ ਹੈ:

1. CMS ਪਹਿਲਾਂ SIP ਡੋਮੇਨ ਨੂੰ ਇਨਕਮਿੰਗ ਕਾਲ ਨਿਯਮਾਂ ਵਿੱਚ ਕੌਂਫਿਗਰ ਕੀਤੇ ਡੋਮੇਨਾਂ ਨਾਲ ਮੇਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਕਾਲਾਂ ਨੂੰ ਫਿਰ ("ਟਾਰਗੇਟਡ") ਸਪੇਸ ਜਾਂ ਖਾਸ ਉਪਭੋਗਤਾਵਾਂ, ਅੰਦਰੂਨੀ IVR, ਜਾਂ ਸਿੱਧੇ ਏਕੀਕ੍ਰਿਤ Microsoft Lync/Skype for Business (S4B) ਟਿਕਾਣਿਆਂ 'ਤੇ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ।
2. ਜੇਕਰ ਇਨਕਮਿੰਗ ਕਾਲ ਨਿਯਮਾਂ ਵਿੱਚ ਕੋਈ ਮੇਲ ਨਹੀਂ ਹੈ, ਤਾਂ CMS ਕਾਲ ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ ਵਿੱਚ ਕੌਂਫਿਗਰ ਕੀਤੇ ਡੋਮੇਨ ਨਾਲ ਮੇਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ। ਜੇਕਰ ਕੋਈ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਤਾਂ ਨਿਯਮ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਕਾਲ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਕਾਲ ਨੂੰ ਅੱਗੇ ਭੇਜ ਸਕਦਾ ਹੈ। ਇਸ ਸਮੇਂ, CMS ਡੋਮੇਨ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖ ਸਕਦਾ ਹੈ, ਜੋ ਕਈ ਵਾਰ Lync ਡੋਮੇਨਾਂ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਉਪਯੋਗੀ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਥ੍ਰੋ ਪਾਸ ਕਰਨ ਦੀ ਵੀ ਚੋਣ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਿਸੇ ਵੀ ਖੇਤਰ ਨੂੰ ਹੋਰ ਸੋਧਿਆ ਨਹੀਂ ਜਾਵੇਗਾ, ਜਾਂ ਅੰਦਰੂਨੀ CMS ਡਾਇਲ ਪਲਾਨ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਵੇਗੀ। ਜੇਕਰ ਕਾਲ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮਾਂ ਵਿੱਚ ਕੋਈ ਮੇਲ ਨਹੀਂ ਹੈ, ਤਾਂ ਡਿਫੌਲਟ ਕਾਲ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਨਾ ਹੈ। ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ ਕਿ CMS ਵਿੱਚ, ਹਾਲਾਂਕਿ ਕਾਲ "ਅੱਗੇ ਭੇਜੀ ਗਈ ਹੈ", ਮੀਡੀਆ ਅਜੇ ਵੀ CMS ਨਾਲ ਬੰਨ੍ਹਿਆ ਹੋਇਆ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਹ ਸਿਗਨਲਿੰਗ ਅਤੇ ਮੀਡੀਆ ਟ੍ਰੈਫਿਕ ਮਾਰਗ ਵਿੱਚ ਹੋਵੇਗਾ।
ਤਦ ਸਿਰਫ਼ ਫਾਰਵਰਡ ਕੀਤੀਆਂ ਕਾਲਾਂ ਆਊਟਗੋਇੰਗ ਕਾਲ ਨਿਯਮਾਂ ਦੇ ਅਧੀਨ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਸੈਟਿੰਗਾਂ ਉਹਨਾਂ ਮੰਜ਼ਿਲਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੀਆਂ ਹਨ ਜਿੱਥੇ ਕਾਲਾਂ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਟਰੰਕ ਦੀ ਕਿਸਮ (ਭਾਵੇਂ ਇਹ ਇੱਕ ਨਵੀਂ Lync ਕਾਲ ਹੋਵੇ ਜਾਂ ਇੱਕ ਮਿਆਰੀ SIP ਕਾਲ ਹੋਵੇ), ਅਤੇ ਕੋਈ ਵੀ ਪਰਿਵਰਤਨ ਜੋ ਕਾਲ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਦੀ ਚੋਣ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਇੱਥੇ ਇੱਕ ਐਡ-ਹੌਕ ਕਾਨਫਰੰਸ ਦੌਰਾਨ ਕੀ ਹੁੰਦਾ ਹੈ ਦਾ ਅਸਲ ਲੌਗ ਹੈ

ਸਕ੍ਰੀਨਸ਼ੌਟ ਇਸ ਨੂੰ ਮਾੜਾ ਦਿਖਾਉਂਦਾ ਹੈ (ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਬਿਹਤਰ ਬਣਾਉਣਾ ਹੈ), ਇਸ ਲਈ ਮੈਂ ਇਸ ਤਰ੍ਹਾਂ ਲੌਗ ਲਿਖਾਂਗਾ:

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

ਐਡ-ਹੌਕ ਕਾਨਫਰੰਸ ਖੁਦ:


ਇਨਕਮਿੰਗ ਕਾਲ ਨਿਯਮ
CMS ਵਿੱਚ ਕਾਲ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਲਈ ਇਨਕਮਿੰਗ ਕਾਲਾਂ ਦੇ ਮਾਪਦੰਡਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ LDAP ਸੈੱਟਅੱਪ ਵਿੱਚ ਦੇਖਿਆ ਸੀ, ਸਾਰੇ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ conf.pod6.cms.lab ਡੋਮੇਨ ਨਾਲ ਆਯਾਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸ ਲਈ ਘੱਟੋ-ਘੱਟ, ਤੁਸੀਂ ਸਪੇਸ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਲਈ ਇਸ ਡੋਮੇਨ 'ਤੇ ਕਾਲਾਂ ਚਾਹੁੰਦੇ ਹੋ। ਤੁਹਾਨੂੰ ਹਰ ਇੱਕ CMS ਸਰਵਰ ਦੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗਤਾ ਪ੍ਰਾਪਤ ਡੋਮੇਨ ਨਾਮ (ਅਤੇ ਸ਼ਾਇਦ IP ਐਡਰੈੱਸ ਵੀ) ਲਈ ਬਣਾਏ ਗਏ ਹਰ ਚੀਜ਼ ਲਈ ਨਿਯਮ ਸਥਾਪਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ। ਸਾਡਾ ਬਾਹਰੀ ਕਾਲ ਨਿਯੰਤਰਣ, ਯੂਨੀਫਾਈਡ CM, ਹਰੇਕ CMS ਸਰਵਰ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸਮਰਪਿਤ SIP ਟਰੰਕਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰੇਗਾ। ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ ਕਿ ਕੀ ਇਹਨਾਂ SIP ਟਰੰਕਾਂ ਦੀ ਮੰਜ਼ਿਲ ਇੱਕ IP ਐਡਰੈੱਸ ਹੈ ਜਾਂ ਸਰਵਰ ਦਾ FQDN ਇਹ ਨਿਰਧਾਰਤ ਕਰੇਗਾ ਕਿ ਕੀ CMS ਨੂੰ ਇਸਦੇ IP ਪਤੇ ਜਾਂ FQDN 'ਤੇ ਨਿਰਦੇਸ਼ਿਤ ਕਾਲਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਕੌਂਫਿਗਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਡੋਮੇਨ ਜਿਸ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਵਾਲੇ ਇਨਬਾਉਂਡ ਨਿਯਮ ਹਨ, ਕਿਸੇ ਵੀ ਉਪਭੋਗਤਾ ਸਪੇਸ ਲਈ ਡੋਮੇਨ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਉਪਭੋਗਤਾ LDAP ਦੁਆਰਾ ਸਿੰਕ ਕਰਦੇ ਹਨ, ਤਾਂ CMS ਆਪਣੇ ਆਪ ਸਪੇਸ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ URI (coSpaceUriMapping), ਉਦਾਹਰਨ ਲਈ, user.space ਦਾ ਸਿਰਫ਼ ਉਪਭੋਗਤਾ ਹਿੱਸਾ। ਭਾਗ ਨੂੰ ਡੋਮੇਨ ਇਸ ਨਿਯਮ ਦੇ ਆਧਾਰ 'ਤੇ ਪੂਰਾ URI ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਸਮੇਂ ਵੈਬ ਬ੍ਰਿਜ ਵਿੱਚ ਲੌਗਇਨ ਕਰਨਾ ਸੀ, ਤਾਂ ਤੁਸੀਂ ਦੇਖੋਗੇ ਕਿ ਸਪੇਸ ਯੂਆਰਆਈ ਕੋਲ ਕੋਈ ਡੋਮੇਨ ਨਹੀਂ ਹੈ। ਇਸ ਨਿਯਮ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਦੇ ਤੌਰ 'ਤੇ ਸੈਟ ਕਰਕੇ, ਤੁਸੀਂ ਤਿਆਰ ਕੀਤੀਆਂ ਥਾਂਵਾਂ ਲਈ ਡੋਮੇਨ ਸੈੱਟ ਕਰ ਰਹੇ ਹੋ conf.example.com.


ਆਊਟਗੋਇੰਗ ਕਾਲ ਨਿਯਮ

ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਯੂਨੀਫਾਈਡ CM ਕਲੱਸਟਰ 'ਤੇ ਆਊਟਬਾਉਂਡ ਕਾਲਾਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ, ਤੁਹਾਨੂੰ ਆਊਟਬਾਉਂਡ ਨਿਯਮਾਂ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਯੂਨੀਫਾਈਡ CM ਨਾਲ ਰਜਿਸਟਰਡ ਐਂਡਪੁਆਇੰਟਾਂ ਦਾ ਡੋਮੇਨ, ਜਿਵੇਂ ਕਿ Jabber, example.com ਹੈ। ਇਸ ਡੋਮੇਨ 'ਤੇ ਕਾਲਾਂ ਨੂੰ ਯੂਨੀਫਾਈਡ CM ਕਾਲ ਪ੍ਰੋਸੈਸਿੰਗ ਨੋਡਾਂ ਲਈ ਸਟੈਂਡਰਡ SIP ਕਾਲਾਂ ਵਜੋਂ ਰੂਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਮੁੱਖ ਸਰਵਰ cucm-01.example.com ਹੈ, ਅਤੇ ਵਾਧੂ ਸਰਵਰ cucm-02.example.com ਹੈ।

ਪਹਿਲਾ ਨਿਯਮ ਕਲੱਸਟਰ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਕਾਲਾਂ ਦੀ ਸਰਲ ਰਾਊਟਿੰਗ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

ਖੇਤਰ ਡੋਮੇਨ ਤੋਂ ਸਥਾਨਕ "@" ਚਿੰਨ੍ਹ ਤੋਂ ਬਾਅਦ ਕਾਲ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਵਿਅਕਤੀ ਲਈ ਕਾਲਰ ਦੇ SIP-URI ਵਿੱਚ ਕੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤਾ ਜਾਵੇਗਾ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਇਸਨੂੰ ਖਾਲੀ ਛੱਡ ਦਿੰਦੇ ਹਾਂ, ਤਾਂ “@” ਚਿੰਨ੍ਹ ਤੋਂ ਬਾਅਦ CUCM ਦਾ IP ਪਤਾ ਹੋਵੇਗਾ ਜਿਸ ਰਾਹੀਂ ਇਹ ਕਾਲ ਲੰਘਦੀ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਡੋਮੇਨ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ, ਤਾਂ “@” ਚਿੰਨ੍ਹ ਤੋਂ ਬਾਅਦ ਅਸਲ ਵਿੱਚ ਇੱਕ ਡੋਮੇਨ ਹੋਵੇਗਾ। ਵਾਪਸ ਕਾਲ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣ ਲਈ ਇਹ ਜ਼ਰੂਰੀ ਹੈ, ਨਹੀਂ ਤਾਂ SIP-URI name@ip-address ਰਾਹੀਂ ਵਾਪਸ ਕਾਲ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੋਵੇਗਾ।

ਸੰਕੇਤ ਦਿੱਤੇ ਜਾਣ 'ਤੇ ਕਾਲ ਕਰੋ ਡੋਮੇਨ ਤੋਂ ਸਥਾਨਕ


ਜਦੋਂ ਕਾਲ ਕਰੋ ਨਹੀਂ ਸੰਕੇਤ ਕੀਤਾ ਡੋਮੇਨ ਤੋਂ ਸਥਾਨਕ


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

ਰਿਕਾਰਡਿੰਗ

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

ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕ ਕਲੱਸਟਰ ਹੈ ਅਤੇ ਲਾਇਸੰਸ ਨੂੰ ਕਲੱਸਟਰ ਵਿੱਚ ਸਾਰੇ ਤਿੰਨ ਸਰਵਰਾਂ ਵਿੱਚ "ਖਿੱਚਿਆ" ਜਾਣ ਦੀ ਲੋੜ ਹੈ। ਫਿਰ ਬਸ ਤੁਹਾਡੇ ਨਿੱਜੀ ਖਾਤੇ ਵਿੱਚ ਉਹਨਾਂ ਲਾਇਸੰਸਾਂ ਵਿੱਚ ਜੋ ਅਸੀਂ ਕਲੱਸਟਰ ਵਿੱਚ ਸ਼ਾਮਲ ਸਾਰੇ CMS ਸਰਵਰਾਂ ਦੇ ਏ-ਇੰਟਰਫੇਸਾਂ ਦੇ MAC ਪਤਿਆਂ ਨੂੰ ਜੋੜਦੇ (ਜੋੜਦੇ) ਹਾਂ।

ਅਤੇ ਇਹ ਉਹ ਤਸਵੀਰ ਹੈ ਜੋ ਕਲੱਸਟਰ ਦੇ ਹਰ ਸਰਵਰ 'ਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ

ਆਮ ਤੌਰ 'ਤੇ, ਰਿਕਾਰਡਰ ਰੱਖਣ ਲਈ ਕਈ ਦ੍ਰਿਸ਼ ਹਨ, ਪਰ ਅਸੀਂ ਇਸ 'ਤੇ ਬਣੇ ਰਹਾਂਗੇ:


ਰਿਕਾਰਡਰ ਸਥਾਪਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਇੱਕ ਜਗ੍ਹਾ ਤਿਆਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਜਿੱਥੇ ਵੀਡੀਓ ਕਾਨਫਰੰਸਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਰਿਕਾਰਡ ਕੀਤਾ ਜਾਵੇਗਾ। ਅਸਲ ਵਿੱਚ ਇੱਥੇ ਲਿੰਕ, ਸਾਰੀਆਂ ਰਿਕਾਰਡਿੰਗਾਂ ਨੂੰ ਕਿਵੇਂ ਸੈਟ ਅਪ ਕਰਨਾ ਹੈ। ਮੈਂ ਮਹੱਤਵਪੂਰਨ ਨੁਕਤਿਆਂ ਅਤੇ ਵੇਰਵਿਆਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਦਾ ਹਾਂ:

1. ਕਲੱਸਟਰ ਵਿੱਚ ਪਹਿਲੇ ਸਰਵਰ ਤੋਂ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਸਲਿਪ ਕਰਨਾ ਬਿਹਤਰ ਹੈ।
2. "ਰਿਕਾਰਡਰ ਅਣਉਪਲਬਧ" ਗਲਤੀ ਹੋ ਸਕਦੀ ਹੈ ਕਿਉਂਕਿ ਰਿਕਾਰਡਰ ਟਰੱਸਟ ਵਿੱਚ ਗਲਤ ਸਰਟੀਫਿਕੇਟ ਦਿੱਤਾ ਗਿਆ ਹੈ।
3. ਲਿਖਣਾ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ ਜੇਕਰ ਰਿਕਾਰਡਿੰਗ ਲਈ ਦਿੱਤੀ ਗਈ NFS ਡਾਇਰੈਕਟਰੀ ਰੂਟ ਡਾਇਰੈਕਟਰੀ ਨਹੀਂ ਹੈ।

ਕਈ ਵਾਰ ਇੱਕ ਖਾਸ ਉਪਭੋਗਤਾ ਜਾਂ ਸਪੇਸ ਦੀ ਕਾਨਫਰੰਸ ਨੂੰ ਆਪਣੇ ਆਪ ਰਿਕਾਰਡ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ।

ਇਸਦੇ ਲਈ, ਦੋ ਕਾਲਪ੍ਰੋਫਾਇਲ ਬਣਾਏ ਗਏ ਹਨ:
ਰਿਕਾਰਡਿੰਗ ਅਯੋਗ ਹੋਣ ਦੇ ਨਾਲ


ਅਤੇ ਆਟੋਮੈਟਿਕ ਰਿਕਾਰਡਿੰਗ ਫੰਕਸ਼ਨ ਦੇ ਨਾਲ


ਅੱਗੇ, ਅਸੀਂ ਲੋੜੀਂਦੀ ਥਾਂ 'ਤੇ ਇੱਕ ਆਟੋਮੈਟਿਕ ਰਿਕਾਰਡਿੰਗ ਫੰਕਸ਼ਨ ਦੇ ਨਾਲ ਇੱਕ ਕਾਲ ਪ੍ਰੋਫਾਈਲ ਨੂੰ "ਅਟੈਚ" ਕਰਦੇ ਹਾਂ।


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

ਅਗਲੀ ਵਾਰ ਮੈਂ ਇਹ ਵਰਣਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ ਕਿ ਸੰਗਠਨ ਦੇ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਹਰ CMS ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਸਰੋਤ:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later. pdf

ਸਰੋਤ: www.habr.com