Cisco Spark 하이브리드 서비스를 배포하기 전에 준비해야 할 다섯 가지 중요한 작업

Document created by Cisco Localization Team on Feb 4, 2017
Version 1Show Document
  • View in full screen mode
 

Cisco Spark 하이브리드 서비스 배포에 대해 다음 다섯 가지 작업이 중요한 이유

 

이 문서는 Cisco Spark 하이브리드 서비스와 관련된 다섯 가지 주요 구성 항목에 대해 추가된 컨텍스트를 제공합니다.

  

Expressway-호스트된 Cisco Spark 하이브리드 서비스(통화 서비스 인식/연결 및 캘린더 서비스)를 성공적으로 배포하려면 다음 다섯 가지 항목이 매우 중요합니다. 다음의 이유로 해당 다섯 가지 작업을 특별히 강조합니다.

  
  •  

    귀하에게 해당 작업을 설명하고, 하이브리드 배포에서 해당 역할을 이해하여 작업에 대해 확신할 수 있도록 하기 위함입니다.

      

  •  

    해당 작업은 저희 클라우드와 귀하의 온-프레미스 환경 간의 안전한 배포를 위한 필수 전제 조건입니다.

      

  •  

    해당 작업은 데이 제로 활동으로 간주합니다. 이는 사용자 인터페이스에서 정렬하고 준비하는 데 있어 일반적인 구성보다 더 긴 시간이 소요될 수 있기 때문에 해당 항목을 정리하기 위한 타임 프레임을 허용해야 합니다.

      

  •  

    환경에서 해당 항목이 처리된 후에 나머지 Cisco Spark 하이브리드 서비스 구성이 원활하게 진행됩니다.

      

  

인터넷 방화벽에 있는 TCP 포트 5062

 

Expressway-C 및 Expressway-E 페어 배포방화벽 순회 기술을 사용하여 통화가 인터넷에서 수신, 발신되도록 허용합니다. 이 배포는 Cisco 협업 클라우드를 통해 Cisco Spark에서 온-프레미스 통화 제어를 안전하게 제한합니다.

Expressway-C 및 Expressway-E는 방화벽 순회 아키텍처로 인해 비무장 영역(DMZ) 방화벽에서 인바운드 포트가 열려 있도록 요구하지 않습니다. 단, TCP SIP 시그널링 포트 및 UDP 미디어 포트는 인터넷 방화벽에서 걸려오는 전화가 통과하도록 인바운드에 대해 열려 있어야 합니다. 기업 방화벽에서 적당한 포트가 열릴 때까지 충분한 시간을 허용해야 합니다.

 
방화벽 순회 아키텍처는 다음 다이어그램에서 표시됩니다.


예를 들어, SIP 프로토콜을 사용하는 인바운드 비즈니스 간(B2B) 통화에 대해 TCP 포트 5060 및 5061(5061은 SIP TLS를 위해 사용됨)은 음성, 비디오, 콘텐츠 공유, 듀얼 비디오 등의 서비스에 사용되는 UDP 미디어 포트와 함께 외부 방화벽에 열려 있어야 합니다. 어떤 미디어 포트를 열어 두어야 하는지는 동시 통화의 수 및 서비스의 수에 따라 달라집니다.

 

Expressway에서 SIP 수신 대기 포트를 1024부터 65534 사이의 값으로 구성할 수 있습니다. 동시에 이 값 및 프로토콜 유형은 공개 DNS SRV 레코드에 광고되어야 하며, 해당 동일한 값은 인터넷 방화벽에 열려 있어야 합니다.

 

SIP TCP에 대한 표준은 5060이며 SIP TLS 5061이지만, 다음 예제에서 표시하는 바와 같이 다른 포트를 사용할 수도 있습니다.

 

이 예제에서 인바운드 SIP TLS 통화에 대해 포트 5062가 사용된다고 가정합니다.

 

두 개의 Expressway 서버의 클러스터에 대한 DNS SRV 레코드는 다음과 같습니다.

_sips._tcp.example.com SRV service location:

priority = 10

 

weight = 10

 

port = 5062

 

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV service location:

priority = 10

 

weight = 10

 

port = 5062

 

svr hostname = us-expe2.example.com

 

해당 레코드는 전송 유형으로 TLS를 사용하고 수신 대기 포트 번호로 5062를 사용하여 동일한 로드 공유(우선순위(priority) 및 가중치(weight))로 통화가 us-expe1.example.comus-expe2.example.com으로 디렉트됨을 의미합니다.

 

네트워크에 대해 외부이며(인터넷에서) 기업 도메인의 사용자(user1@example.com)에게 SIP 통화를 실행하는 장치는 DNS를 쿼리하여 어떠한 전송 유형을 사용할 지, 포트 번호, 트래픽을 로드-공유하는 방법 및 어떤 SIP 서버에서 통화를 발송하는지 이해해야 합니다.

 

DNS 입력값에 _sips._tcp가 포함된 경우, 해당 값은 SIP TLS를 지정합니다.

 

가장 일반적인 실행에 있어 TLS가 클라이언트-서버 프로토콜이며 인증서를 사용하여 인증합니다. 비즈니스 간 통화 시나리오에서 TLS 클라이언트는 전화를 거는 장치이며, TLS 서버는 전화를 받는 장치입니다. TLS를 사용하여 클라이언트는 서버의 인증서를 확인하며, 인증서 확인에 실패하는 경우에 통화의 연결을 끊습니다. 클라이언트는 인증서가 필요하지 않습니다.

TLS 핸드쉐이크는 다음 다이어그램에서 표시됩니다.


 

단, TLS 사양은 TLS 핸드쉐이크 프로토콜 과정 중에 클라이언트에게 인증서 요청 메시지를 발송하여 서버 또한 클라이언트 인증서를 확인할 수 있음을 설명합니다. 이 메시지는 Expressway-E 및 Cisco 협업 클라우드 간에 연결된 통화 등 서버 간 연결에 있어 유용합니다. 이 개념은 상호 인증을 사용하는 TLS로 지칭하며, Cisco Spark와 통합할 때 필요합니다.

 
다음 다이어그램에 표시된 바와 같이 전화를 거는 사용자 및 전화를 받는 사용자 모두 다른 피어의 인증서를 확인합니다.


 

클라우드는 Expressway 아이덴티티를 확인하고, Expressway는 클라우드 아이덴티티를 확인합니다. 예를 들어, 인증서(CN 또는 SAN)에 있는 클라우드 아이덴티티가 Expressway에 구성된 아이덴티티와 일치하지 않는 경우 연결은 끊깁니다.

 

상호 인증이 켜져 있으면 Expressway-E는 항상 클라이언트 인증서를 요청합니다. 결과적으로 모바일 및 Remote Access(MRA)는 작동하지 않게 됩니다. 이는 대부분의 경우에 Jabber 클라이언트에 인증서가 배포되어 있지 않기 때문입니다. 비즈니스 간 시나리오에서 전화를 거는 엔티티가 인증서를 제공할 수 없는 경우, 전화의 연결이 끊깁니다.

 

상호 인증을 포함하는 TLS에 대해 5062 등 5061 이외의 값을 사용할 것을 권장합니다. Cisco Spark 하이브리드 서비스는 B2B에 사용된 동일한 SIP TLS 레코드를 사용합니다. 포트 5061의 경우, TLS 클라이언트 인증서를 제공할 수 없는 일부 다른 서비스는 작동하지 않습니다.

     

동일한 Expressway 페어에서 비즈니스 간, 모바일 및 원격 액세스, Spark 트래픽

비즈니스 간 및 모바일 및 원격 액세스 통화는 SIP TLS에 대해 포트 5061을 사용하며, Cisco Spark 트래픽은 상호 인증이 포함된 SIP TLS에 대해 포트 5062를 사용합니다.

클라우드에서 도메인 소유권을 확인하는 이유

도메인 소유권 확인은 아이덴티티 인증의 일부입니다. 도메인 인증은 Cisco 협업 클라우드에서 귀하가 실제 본인인지 증명하기 위해 실행하는 보안 측정이자 아이덴티티 확인입니다.

 

아이덴티티 확인은 다음 두 단계로 실행됩니다.

  1. 도메인 소유권 확인하기. 이 단계에는 다음 세 가지 유형의 도메인이 포함되며, 이는 일회성 인증 확인입니다.

     

    • 이메일 도메인

       

    • Expressway-E DNS 도메인

       

    • 디렉토리 URI 도메인

       

  2. Expressway-E DNS 이름 소유권 확인하기. 이 단계는 상호 인증이 포함되는 TLS의 실행을 통해 수행되며, 클라우드 및 Expressway 모두에 있는 공개 인증서가 사용됩니다. 도메인 아이덴티티 확인과 달리, 이 단계는 클라우드에서 발신 및 수신하는 모든 통화 중에 실행됩니다.

     

       

도메인 소유권 확인의 실행에 대한 스토리

Cisco 협업 클라우드는 보안을 강화하기 위해 도메인 소유권 확인을 실행합니다. 이 확인 작업이 실행되지 않는 경우에 신원 도용의 위험이 있을 수 있습니다.

 

다음 스토리는 도메인 소유권 확인이 실행되지 않는 경우에 발생할 수도 있는 사례를 소개합니다.

 

DNS 도메인이 "hacker.com"으로 설정된 회사에서 Cisco Spark 하이브리드 서비스를 구입합니다. 도메인이 "example.com"으로 설정된 다른 회사에서도 하이브리드 서비스를 사용합니다. 회사 Example.com의 관리자 중 한 명의 이름은 Jane Roe이며, 디렉토리 URI jane.roe@example.com를 갖고 있습니다.

 

Hacker.com 회사의 관리자가 디렉토리 URI 중 하나를 jane.roe@example.com, 이메일 주소를 jane.roe@hacker.com으로 설정합니다. 이 예제에서 클라우드가 SIP URI 도메인을 확인하지 않았기 때문에 해당 관리자는 이와 같은 작업을 할 수 있습니다.

 

그 후 jane.roe@hacker.com으로 Cisco Spark에 로그인합니다. 해당 관리자가 도메인을 소유하고 있기 때문에 인증 이메일을 읽고 응답한 후 로그인할 수 있습니다. 마지막으로 Cisco Spark 클라이언트에서 john.doe@example.com으로 다이얼하여 동료인 John Doe에게 전화를 겁니다. 사무실에 있는 John은 비디오 장치에서 jane.roe@example.com(이는 해당 이메일 계정과 연계된 디렉토리 URI임)으로부터 걸려오는 전화를 확인합니다.

 

John은 "Jane이 출근한 모양이군." "중요한 일이 있나?"라고 생각하고 전화에 응답하며, 가짜 Jane Roe가 중요한 문서를 요청합니다. 가짜 Jane은 현재 출장 중인데 장치가 고장났으며, 개인 이메일 주소인 jane.roe@hacker.com으로 해당 문서를 보내 줄 것을 요청합니다. 이러한 방법으로 회사는 실제 Jane Roe가 출근한 후에야 중요한 정보가 외부로 유출되었음을 알게 됩니다.

 

회사 Example.com은 인터넷에서 걸려오는 사기적인 통화로부터 자사를 보호할 수 있는 많은 방법이 있습니다. Cisco 협업 클라우드의 책임 중 하나는 Cisco Spark로부터 걸려오는 전화의 사용자에 대한 아이덴티티가 올바른지, 위조된 것이 아닌지를 확인하는 것입니다.

 

아이덴티티를 확인하기 위해 Cisco Spark는 해당 회사에서 Spark 하이브리드 통화에 사용된 도메인을 소유하고 있는지 증명하도록 요구합니다. 소유하고 있지 않은 경우, Cisco Spark 하이브리드 서비스는 작동하지 않게 됩니다.

 

이 소유권을 확인하기 위해 도메인 인증의 두 단계가 필요합니다.

  1. 회사에서 이메일 도메인, Expressway-E 도메인, 디렉토리 URI 도메인을 소유하고 있는지 증명합니다.

      

    •  

      해당되는 모든 도메인은 라우팅할 수 있으며, 공개 DNS 서버에서 알고 있어야 합니다.

        

    •  

      소유권을 증명하기 위해 DNS 관리자는 DNS 텍스트 레코드(TXT)를 입력해야 합니다. TXT 레코드는 DNS에서 호스트 또는 다른 이름과 일부 임의적이고 서식화되지 않은 텍스트를 연계하는 기능을 제공하기 위해 사용되는 리소스 레코드의 유형입니다.

        

    •  

      DNS 관리자는 누구의 소유권이 증명되어야 하는지 영역에 TXT 레코드를 입력해야 합니다. 해당 단계 이후에 Cisco 협업 클라우드는 해당 도메인에 대한 TXT 레코드 쿼리를 실행합니다.

        

    •  

      TXT 쿼리가 성공적으로 실행되고 결과가 Cisco 협업 클라우드에서 생성된 토큰과 일치하는 경우에 해당 도메인은 인증됩니다.

        

    •  

      예를 들어, 관리자는 사용자가 자신의 도메인에서 Cisco Spark 및 Cisco Spark 하이브리드 서비스를 작동하도록 하려는 경우에 해당 사용자가 도메인 "example.com"을 소유하고 있는지 증명해야 합니다.

        

    •  
      관리 포털을 통해 사용자는 Cisco 협업 클라우드에서 생성한 토큰을 일치시키기 위해 TXT 레코드를 생성하여 인증 프로세스를 시작합니다.


        
    •  
      그 후 DNS 관리자는 다음 예제와 같이 123456789abcdef123456789abcdef123456789abcdef123456789abcdef에 설정된 값으로 이 도메인에 대한 TXT 레코드를 만듭니다.


        
    •  

      이 단계에서 클라우드는 도메인 example.com에 대한 TXT 레코드가 토큰과 일치하는지 확인할 수 있습니다.

        

    •  
      클라우드는 TXT DNS 조회를 실행합니다.


        
    •  

      TXT 값이 토큰 값과 일치하기 때문에 이 일치 작업은 관리자가 공개 DNS에 사용자 자신의 도메인에 대한 TXT 레코드를 추가했으며, 해당 사용자가 도메인을 소유하고 있음을 증명합니다.

        

     
  2. Expressway-E DNS 이름 소유권 확인하기.

      

    •  

      클라우드는 Expressway-E가 클라우드에서 신뢰하는 인증 기관 중 하나에서 확인된 아이덴티티를 갖고 있는지 확인해야 합니다. Expressway-E 관리자는 Expressway-E에 대해 해당 인증 기관 중 하나로 공개 인증서를 요청해야 합니다. 인증서를 발행하려면 도메인 유효성 검증 확인(도메인 유효성이 검증된 인증서) 또는 조직 유효성 검증 확인(조직 유효성이 검증된 인증서)에 기반하여 인증 기관에서 아이덴티티 인증 프로세스를 실행해야 합니다.

        

    •  

      클라우드에서 발신 및 수신되는 통화는 Expressway-E에 발행된 인증서에 따라 다릅니다. 인증서가 유효하지 않은 경우, 통화는 끊깁니다.

        

    

지원되는 인증 기관

하이브리드 서비스가 작동하도록 하려면 Expressway-C 커넥터 호스트가 Cisco 협업 클라우드에 등록되어야 합니다.

 

Expressway-C는 내부 네트워크에 배포되며, 클라우드에 등록하는 방법은 아웃바운드 HTTPS 연결을 통합니다. 이는 웹 서버에 연결하는 브라우저에 대해 사용된 것과 동일한 유형입니다.

 

Cisco 협업 클라우드에 등록 및 통신은 TLS를 사용합니다. Expressway-C는 TLS 클라이언트이며, Cisco 협업 클라우드는 TLS 서버입니다. 이와 같이 Expressway-C는 서버 인증서를 확인합니다.

 

인증 기관은 자신의 비공개 키를 사용하여 서버 인증서에 서명합니다. 공개 키가 있는 사용자는 해당 서명을 디코딩하고 동일한 인증 기관이 해당 인증서에 서명했는지 증명할 수 있습니다.

 

Expressway-C가 클라우드에서 제공한 인증서의 유효성을 검증해야 하는 경우, 서명을 디코딩하려면 인증서를 서명한 인증 기관의 공개 키를 사용해야 합니다. 공개 키는 인증 기관의 인증서에 포함되어 있습니다. 클라우드에서 사용하는 인증 기관을 신뢰하려면 신뢰하는 해당 인증 기관의 인증서 목록이 Expressway의 신뢰 스토어에 있어야 합니다. 이렇게 하면 Expressway는 해당 통화가 실제로 Cisco 협업 클라우드에서 걸려오는 것으로 인증할 수 있습니다.

 

수동 업로드를 사용하여 Expressway-C의 신뢰 스토어에 관련된 모든 인증 기관 인증서를 업로드할 수 있습니다.

 

자동 업로드를 사용하여 Expressway-C의 신뢰 스토어에 클라우드가 직접 해당 인증서를 업로드하도록 할 수 있습니다. 자동 업로드를 사용할 것을 권장합니다. 인증서 목록은 변경될 수도 있으며, 자동 업로드는 가장 업데이트된 목록이 유지되도록 보장합니다.

 

인증 기관 인증서의 자동 설치를 허용하는 경우, Cisco 클라우드 협업 관리(관리 포털)로 리디렉트됩니다. 리디렉션은 사용자가 실행하지 않아도 Expressway-C에서 직접 실행합니다. Cisco Spark 관리자인 본인은 HTTPS 연결을 통해 인증해야 합니다. 그 후 곧 클라우드에서 CA 인증서를 Expressway-C로 푸쉬합니다.

 

인증서가 Expressway-C 신뢰 스토어에 업로드될 때까지 HTTPS 연결을 시작할 수 없습니다.

 

이 문제를 예방하기 위해 Expressway-C는 Cisco Spark-신뢰하는 CA 인증서를 포함하여 미리 설치됩니다. 해당 인증서는 첫 HTTPS 연결을 설정하고 유효성을 검증하기 위해서만 사용되며, Expressway-C 신뢰 목록에 나타나지 않습니다. 신뢰하는 인증 기관의 인증서가 이 첫 HTTPS 연결을 통해 클라우드로부터 축출되면 해당 인증서는 플랫폼 전반에서 사용할 수 있습니다. 그 후 Expressway-C 신뢰 목록에 나타납니다.

 
이 프로세스는 다음 이유로 안전합니다.
  •  

    Expressway-C 및 Cisco 클라우드 협업 관리(admin.ciscospark.com)로 관리 액세스를 요구합니다. 해당 연결은 HTTPS를 사용하며, 암호화됩니다.

      

  •  

    인증서는 동일 암호화된 연결을 사용하여 클라우드에서 Expressway로 푸쉬됩니다.

      

   

이 목록은 현재 Cisco 협업 클라우드에서 사용하는 인증 기관 인증서를 표시합니다. 이 목록은 향후에 변경될 수도 있습니다.

  • C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

     

  • C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

     

  • C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

     

  • C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

     

  • C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

     

  • C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

     

  • C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

     

  

인증 기관 인증서의 목록은 순회 페어에서 Expressway-E를 요구합니다. Expressway-E는 SIP와 TLS(상호 인증에서 강제함)를 사용하여 Cisco 협업 클라우드와 통신합니다. Expressway-E는 TLS 연결 설치 중에 클라우드에서 표시하는 인증서의 CN 또는 SAN이 Expressway에서 DNS 영역에 대해 구성된 주체명과 일치하는 경우에만("callservice.ciscospark.com") 클라우드로부터 걸려오는 전화 및 거는 전화를 신뢰합니다. 인증 기관은 아이덴티티 확인 후에만 인증서를 릴리즈합니다. 서명된 인증서를 확보하려면 callservice.ciscospark.com 도메인의 소유권이 증명되어야 합니다. Cisco에서 해당 도메인을 소유하고 있기 때문에 DNS 이름 "callservice.ciscospark.com"은 원격 피어가 실제 Cisco 협업 클라우드임에 대한 직접적인 증명입니다.

 

Exchange 가장 계정

 

캘린더 커넥터는 가장 계정을 통해 Cisco Spark를 Microsoft Exchange 2010, 2013, 2016 또는 Office 365와 통합합니다. Exchange에 있는 응용프로그램 가장 관리 역할은 응용프로그램이 조직에 있는 사용자를 가장하도록 활성화하여 사용자 대신 작업을 실행합니다. 응용프로그램 가장 역할은 Exchange에 구성되어야 하며, Expressway-C 인터페이스에 있는 Exchange 구성의 일부로 캘린더 커넥터에서 사용되어야 합니다.

Exchange 가장 계정은 이 작업에 대해 Microsoft에서 권장하는 방법입니다. 가장 계정을 사용하여 ESW(Exchange Web Services)를 통해 액세스하면 다음의 이유로 안전합니다.

  • 해당 액세스는 사용자가 사용할 수 없으며, EWS 연결은 TLS를 통한 와이어에서 안전합니다.

     

  • 해당 계정은 EWS를 통해서만 사용될 수 있습니다. 즉, 가장 권한이 있는 계정에 액세스하는 사용자가 사용자의 메일박스에 액세스하려면 EWS 응용프로그램을 써야 하며, 메일박스 클라이언트를 통해 직접 메일박스에 액세스하지 못합니다.

     

  • 가장 계정 비밀번호는 Expressway-C에 암호화되어 저장됩니다.

     

  

이러한 이유로, 해당 값은 Exchange 관리자가 Expressway-C 인터페이스에 입력하기 때문에 Expressway-C 관리자는 비밀번호를 알아야 필요가 없습니다. Expressway-C 관리자가 Expressway-C 박스로의 루트 액세스를 갖고 있더라도 비밀번호는 명확하게 표시되지 않습니다.

 

보안은 Expressway-C 응용프로그램만 해당 비밀번호를 사용하도록 보장합니다.

 

다수의 Expressway 배포

Expressway-C 커넥터 호스트는 최대 여섯 개의 서버로 클러스터될 수 있습니다. 다른 지역에 있는 다수의 Unified CM 클러스터가 포함된 시나리오에서 로컬 중복성만 포함하는 다수의 Expressway-C 클러스터(Unified CM 클러스터 당 한 개)를 배포할 수 있습니다. Expressway-C 노드 중 한 개가 다운되면 클러스터에 있는 다른 노드가 Cisco 협업 클라우드 및 Unified CM으로 연결합니다. 현재 지리적 중복성은 사용할 수 없습니다.

SIP 시그널링 및 미디어에 대해 사용된 Expressway-C 및 Expressway-E

   

다른 지역에 다수의 Expressway-C 및 Expressway-E 클러스터를 가질 수 있습니다. Unified CM은 파티션 및 콜링 서치 스페이스 구성에 기반하여 Unified CM에서 Cisco 협업 클라우드로 실행되는 아웃바운드 통화에 대해 가장 근접한 Expressway 클러스터를 사용합니다.

  

인바운드 통화에 대해서는 Internet Edge의 상이한 Expressway-E 클러스터 간에 트래픽을 나누는 방법을 이해해야 합니다.

  
  •  

    동일한 데이터센터 또는 동일한 지역에 Internet Edges가 배포된 경우, DNS SRV 수준에서 로드 밸런싱이 발생할 수 있습니다. 예를 들어, 기업 네트워크에 Spark 하이브리드 통화에 사용되는 Internet Edge가 세 개 포함된 경우, 각 Edge는 두 개의 Expressway-E 및 Expressway-C 노드로 구성되며, _sips._tcp.example.com은 동일한 우선순위 및 가중치로 여섯 개의 모든 Expressway-E 레코드(3 Expressway-E x 2)를 포함하게 됩니다. 이 설정은 통화를 Cisco 협업 클라우드에서 다양한 Expressway-E 및 Expressway-C 클러스터 전반으로 동일하게 분배합니다.

      

  •  

    다른 지역 전반에 Internet Edge가 배포된 경우, 최고의 솔루션은 Geo DNS 서비스를 사용하는 것입니다.

      

    Geo DNS 서비스는 다수의 DNS 공급자가 전달하며, Geo DNS의 기능에 기반하여 소스 IP 주소를 확인하고 해당 IP 주소가 속한 국가 또는 지역을 파악한 후 해당 지역에 물리적으로 근접한 에지로 요청을 전달합니다. Expressway-E로의 하이브리드 통화는 Spark 클라이언트가 아닌 Cisco 협업 클라우드에서 걸려오는 것임을 숙지하십시오. 이러한 이유로 소스 IP 주소는 Cisco 협업 클라우드에서 사용하고 있는 IP 주소 중의 하나입니다.

      

    이 범주 및 Geo DNS의 구성에 기반하여 통화는 통화 IP 주소가 소속된 영역과 물리적으로 근접한 Expressway-E로 발송됩니다.

      

  
예를 들어, AWS Geo DNS 서비스가 다음 방법으로 구성되었습니다.


  

SRV 레코드가 작성되면 "위치" 레이블이 적용되고 국가가 지정됩니다. 동일한 위치의 일부인 IP 주소가 포함된 클라우드(이 예제에서는 이탈리아)에서 걸려오는 통화는 emea-expe1.example.com으로 보내집니다. 지역의 수에 기반하여 다수의 SRV 레코드를 만들 수 있습니다.

  

Geo DNS의 구성은 DNS 공급자에 따라 달라지며, 이 구성 예제는 참조의 목적으로만 사용됩니다.

  
US 및 EMEA에 두 개의 다른 Expressway-C 및 Expressway-E 클러스터가 배포된 경우, DNS SRV 레코드 _sips._tcp.example.com는 두 개의 상이한 영역에 소속된 것으로 구성됩니다. 다음 예제에서 표시한 바와 같이 AWS를 사용하려면 _sips._tcp.example.com에 대한 두 개의 DNS SRV 레코드가 필요합니다.


  

이러한 방법으로 US에 있는 Cisco 협업 클라우드에서 나가는 통화가 US에 있는 Expressway-E로 들어가면 US에 있는 Expressway-E 클러스터를 사용할 수 없는 경우에만 EMEA에 있는 Expressway-E 클러스터가 사용됩니다. 통화가 EMEA에 있는 Cisco 협업 클라우드에서 나가는 경우, 이는 EMEA에 위치한 Expressway-E 클러스터로 이동하며, EMEA 클러스터를 사용할 수 없는 경우에만 US 클러스터를 사용합니다.

  
 

Attachments

    Outcomes