클라우드 커넥터 버전 PSTN 사이트 계획

효율적이고 비용 효율적인 통화 라우팅을 보장하기 위해 Cloud Connector Edition PSTN 사이트를 계획하는 방법을 알아보려면 이 문서를 참조하세요.

이 문서에서는 Cloud Connector PSTN 사이트를 계획할 수 있도록 Cloud Connector Edition 및 통화 라우팅에 대해 알아야 할 사항을 설명합니다. PSTN 사이트는 동일한 위치에 배포된 클라우드 커넥터 어플라이언스와 공통 PSTN 게이트웨이가 연결된 클라우드 커넥터 어플라이언스의 조합입니다. 이 항목에서는 클라우드 커넥터 사이트가 가능한 가장 비용 효율적이고 효과적인 방법으로 사이트에 할당된 모든 사용자에 대한 인바운드 및 아웃바운드 라우팅을 모두 처리할 수 있도록 클라우드 커넥터 사이트 토폴로지를 설정하는 방법에 중점을 둡니다. 클라우드 커넥터 및 PSTN 사이트의 이점에 대한 자세한 내용은 비즈니스용 Skype 클라우드 커넥터 버전 계획을 참조하세요.

클라우드 커넥터 PSTN 사이트 및 통화 라우팅

클라우드 커넥터 PSTN 사이트는 불필요한 장거리 및 국가/지역 간 관세를 방지하고 아웃바운드 긴급 통화가 적절한 트렁크로 라우팅되도록 하기 위해 만들어진 토폴로지 구문입니다. 응급 서비스 호출을 포함하여 통화의 비용 효율적이고 효율적인 라우팅을 보장하려면 PSTN 사이트와 사용자가 각 사이트에 할당되는 방법을 신중하게 계획해야 합니다.

클라우드 커넥터에 대한 계획의 일환으로 사무실과 사용자가 있는 위치 및 PSTN 트렁크가 이동 통신 사업자에서 종료되는 위치에 대해 이동 통신업체와 통신하는 것이 중요합니다. 이동 통신 사업자와 협력하여 긴급 통화를 라우팅하는 방법을 확인한 다음, 해당 정보를 사용하여 클라우드 커넥터 PSTN 사이트를 정의하고 적절한 사이트에 사용자를 할당해야 합니다. 예를 들어 PSTN 사이트가 확장된 데이터 센터에서 종료되는 트렁크가 해당 사이트의 사용자에게 할당된 모든 숫자에 대한 인바운드 및 아웃바운드 라우팅을 모두 처리하도록 구성되어 있는지 확인해야 합니다.

각 클라우드 커넥터 어플라이언스 여러 IP 게이트웨이, IP PBX 또는 SBC(세션 테두리 컨트롤러)에 연결할 수 있습니다. 게이트웨이 및 PBX는 통신 트렁크(PRI 또는 SIP 트렁크)에 연결되므로 클라우드 커넥터 어플라이언스는 인바운드 및 아웃바운드 호출을 위해 PSTN 트렁크에 논리적으로 연결됩니다. 클라우드 커넥터 및 온-프레미스 PSTN 연결을 사용하면 로컬 통신 사업자로부터 트렁크 및 연결된 전화 번호를 얻을 수 있습니다. 비즈니스가 대기업인 경우, 특히 비즈니스가 둘 이상의 도시, 주 또는 국가/지역에 걸쳐 있는 경우 둘 이상의 운송업체가 있을 수 있습니다. 운송업체가 전화 번호를 소유하기 때문에 이동통신사는 긴급 통화를 처리해야 합니다.

비즈니스용 Skype Online은 사이트의 모든 클라우드 커넥터 어플라이언스를 동일하게 처리하고 동일한 사이트의 Cloud Connector 어플라이언스로 순환 방식으로 아웃바운드 호출을 라우팅합니다. 사이트의 각 클라우드 커넥터는 동일한 PSTN 트렁크 집합(완전히 메시됨)에 교차 연결됩니다. 각 사용자는 클라우드 커넥터 PSTN 사이트와 연결되므로 해당 사용자의 아웃바운드 호출(정상 또는 긴급)은 사용자가 연결된 PSTN 사이트의 클라우드 커넥터 어플라이언스 중 하나에 할당됩니다.

클라우드 커넥터는 연결된 IP 게이트웨이, IP-PBX, SBC 또는 직접 PSTN 트렁크에 대한 정적 호출 라우팅을 수행합니다. 클라우드 커넥터는 아직 대상(최소 비용 라우팅) 또는 원본(정적 또는 동적 긴급 호출)을 기반으로 트렁크에 동적 라우팅할 수 없습니다. 인바운드 호출은 번호와 연결된 트렁크에서만 호출할 수 있으므로 문제가 되지 않습니다. 그러나 아웃바운드 호출은 사이트의 모든 클라우드 커넥터 어플라이언스(그리고 해당 Cloud Connector 어플라이언스 연결된 PSTN 트렁크)로 이동하여 원치 않는 장거리 호출을 일으킬 수 있습니다. 또한 클라우드 커넥터 PSTN 사이트가 다른 지역 코드 또는 통신 사업자가 있는 데이터 센터에 걸쳐 확장되는 경우 긴급 통화가 진행되지 않습니다.

예제

다음 예제에서는 트렁크를 PSTN 사이트로 그룹화하고 사이트에 사용자를 할당하는 방법을 보여 줍니다. Contoso 회사의 경우 다음을 가정합니다.

• 4명의 사용자가 있습니다.

  • Redmond WA의 사용자 A(미국)

  • Bellevue WA(미국)의 사용자 B

  • Centralia WA(미국)의 사용자 C

  • 포틀랜드 OR(미국)의 사용자 D

• 이동 통신 사업자 A는 다음에서 전화 번호와 트렁크를 제공합니다.

  • Redmond(영역 코드 425)

  • Bellevue(영역 코드 425)

  • Centralia(지역 코드 360)

• 이동 통신 사업자 B는 다음에서 전화 번호와 트렁크를 제공합니다.

  • 포틀랜드(지역 코드 503)

Redmond의 사용자 A(데이터 센터 A)와 Bellevue의 사용자 B(데이터 센터 B)는 서로 옆의 교외에 있고 동일한 지역 코드(425)에 있기 때문에 Carrier A는 Bellevue의 트렁크에 있는 Redmond의 사용자 A로부터 긴급 전화를 받을 수 있어야 합니다.

따라서 사용자 A 및 B와 Bellevue 및 Redmond용 클라우드 커넥터 트렁크는 다음 다이어그램과 동일한 클라우드 커넥터 PSTN 사이트에 있을 수 있습니다. 한 사무실에 있는 사용자의 긴급 전화는 다른 사무실의 트렁크로 라우팅할 수 있습니다. 그러나 이 작업이 작동한다는 것을 운송업체와 검사 합니다.

다음 예제도 고려합니다.

• 캐리어 A에서 번호를 제공하는 Centralia의 사용자 C는 2시간 거리에 있으며 Bellevue 및 Redmond 425 지역 코드의 다른 운송업체 A 사용자와는 다른 지역 코드(360)입니다.

  따라서 이동 통신 사업자 A에서 전화가 오더라도 Centralia 지역 코드 360의 통신 사업자의 통화 라우팅 소프트웨어가 Bellevue 지역 코드 425의 사용자 B에서 발생하는 수신 긴급 통화를 거부할 수 있습니다. 이 경우 통신 사업자는 Cloud Connector 및 Centralia PSTN 사이트의 연결된 트렁크가 거리 및 지역 코드에서 호출을 처리할 수 있는지 확인하는 것이 중요합니다.

• 포틀랜드의 사용자 D는 캐리어 B에서 제공하는 숫자와 트렁크를 사용하므로 캐리어 B가 캐리어 A가 소유한 전화 번호에서 긴급 전화를 받을 가능성은 매우 낮습니다. 따라서 포틀랜드의 사용자 D 및 클라우드 커넥터 어플라이언스 및 연결된 트렁크는 다른 PSTN 사이트에 있어야 합니다.