비즈니스용 Skype 서버 직접 SIP 연결

직접 SIP 연결은 Enterprise Voice 비즈니스용 Skype 서버 PSTN 게이트웨이와 IP-PBX 간에 지원됩니다.

직접 SIP 연결을 사용하여 다음 중 하나에 비즈니스용 Skype 서버 연결할 수 있습니다.

• An IP-PBX

• PSTN 게이트웨이

직접 SIP 연결을 구현하려면 기본적으로 SIP 트렁크를 구현하는 것과 동일한 배포 단계를 따릅니다. 두 경우 모두 중재 서버의 외부 인터페이스를 사용하여 연결을 구현합니다. 유일한 차이점은 SIP 트렁크를 ITSP 게이트웨이와 같은 외부 엔터티에 연결하고 IP-PBX 또는 PSTN(공용 전화망) 게이트웨이와 같은 로컬 네트워크 내의 내부 엔터티에 직접 SIP 연결을 연결한다는 것입니다.

직접 SIP 배포 옵션

비즈니스용 Skype 서버 Stand-Alone

organization 이 섹션에 설명된 배포 중 하나를 사용하는 경우 비즈니스용 Skype 서버 organization 일부 또는 전체에 대한 유일한 전화 통신 솔루션으로 사용할 수 있습니다. 이 섹션에서는 다음 배포에 대해 자세히 설명합니다.

• 증분 배포: 이 옵션은 기존 PBX(프라이빗 분기 교환) 인프라가 있고 organization 내의 소규모 그룹 또는 팀에 증분 방식으로 Enterprise Voice 도입하려고 하는 것으로 가정합니다.

• VoIP 전용 배포: 이 옵션은 기존 전화 통신 인프라가 없는 사이트에 Enterprise Voice 배포하는 것을 고려하고 있다고 가정합니다.

증분 배포

증분 배포에서 비즈니스용 Skype 서버 개별 팀 또는 부서를 위한 유일한 전화 통신 솔루션이며, organization 나머지 사용자는 PBX를 계속 사용합니다. 이 증분 배포 전략은 제어된 파일럿 프로그램을 통해 엔터프라이즈에 IP 전화 통신을 도입하는 한 가지 방법을 제공합니다. Microsoft Unified Communications에서 통신 요구 사항을 가장 잘 제공하는 작업 그룹은 Enterprise Voice 이동되고 다른 사용자는 기존 PBX에 남아 있습니다. 필요에 따라 추가 작업 그룹을 Enterprise Voice 마이그레이션할 수 있습니다.

통신 요구 사항이 공통적으로 있고 중앙 집중식 관리에 도움이 되는 사용자 그룹을 명확하게 정의한 경우 증분 옵션을 사용하는 것이 좋습니다. 이 옵션은 장거리 요금 절감이 중요할 수 있는 넓은 지리적 영역에 분산된 팀 또는 부서가 있는 경우에도 효과적입니다. 실제로 이 옵션은 구성원이 전 세계에 흩어져 있을 수 있는 가상 팀을 만드는 데 유용합니다. 변화하는 비즈니스 요구 사항에 신속하게 대응하여 이러한 팀을 만들거나 수정하거나 해체할 수 있습니다.

다음 그림에서는 PBX 뒤에 Enterprise Voice 배포하기 위한 일반 토폴로지를 보여줍니다. 증분 배포에 권장되는 토폴로지입니다.

증분 배포 옵션

이 토폴로지에서 선택한 부서 또는 작업 그룹은 Enterprise Voice 사용할 수 있습니다. PSTN 게이트웨이는 VoIP(Voice over Internet Protocol) 지원 작업 그룹을 PBX에 연결합니다. 원격 작업자를 포함하여 Enterprise Voice 사용하도록 설정된 사용자는 IP 네트워크를 통해 통신합니다. PSTN 및 Enterprise Voice 사용하도록 설정되지 않은 동료에 대한 Enterprise Voice 사용자의 호출은 적절한 PSTN 게이트웨이로 라우팅됩니다. PBX 시스템에 있는 동료 또는 PSTN의 호출자로부터의 호출은 PSTN 게이트웨이로 라우팅되어 라우팅을 위해 비즈니스용 Skype 서버 호출을 전달합니다.

상호 운용성을 위해 Enterprise Voice 기존 PBX 인프라에 연결하는 두 가지 권장 구성이 있습니다. PBX 뒤에 Enterprise Voice PBX 앞에 Enterprise Voice.

PBX 뒤에 Enterprise Voice

Enterprise Voice PBX 뒤에 배포되면 PSTN의 모든 호출이 PBX에 도착하여 Enterprise Voice 사용자에 대한 호출을 PSTN 게이트웨이로 라우팅하고 PBX 사용자를 PBX로 호출합니다.

PBX 앞에 Enterprise Voice

Enterprise Voice PBX 앞에 배포되면 모든 호출이 PSTN 게이트웨이에 도착합니다. 이 게이트웨이는 Enterprise Voice 사용자가 비즈니스용 Skype 서버 호출하고 PBX 사용자를 PBX로 호출합니다. Enterprise Voice 및 PBX 사용자 모두에서 PSTN에 대한 호출은 IP 네트워크를 통해 가장 비용 효율적인 PSTN 게이트웨이로 라우팅됩니다. 다음 표에서는 이 구성의 장점과 단점을 보여 줍니다.

PBX 앞에서 Enterprise Voice 배포할 때의 장점 및 단점

VoIP-Only 배포

Enterprise Voice PBX 통합에 대해 걱정할 필요 없이 또는 IP-PBX 인프라의 상당한 배포 및 유지 관리 비용을 발생시키지 않고도 완전한 기능을 갖춘 VoIP 솔루션을 구현할 수 있는 기회를 통해 기존 비즈니스를 위한 새로운 비즈니스 및 새 사무실 사이트를 제공합니다. 이 솔루션은 현장 및 원격 작업자를 모두 지원합니다.

이 배포에서 모든 호출은 IP 네트워크를 통해 라우팅됩니다. PSTN에 대한 호출은 적절한 PSTN 게이트웨이로 라우팅됩니다. Skype for Business 또는 Lync Phone Edition은 소프트폰으로 사용됩니다. 사용자가 제어할 PBX 휴대폰이 없으므로 원격 통화 제어를 사용할 수 없으며 불필요합니다. 음성 메일 및 자동 전화 교환 서비스는 UM(Exchange Unified Messaging)의 선택적 배포를 통해 사용할 수 있습니다.

다음 그림에서는 VoIP 전용 배포에 대한 일반적인 토폴로지를 보여줍니다.

VoIP 전용 배포 옵션

PSTN Gateway 배포 옵션

PSTN 게이트웨이

PSTN(공용 전화망) 게이트웨이는 직접 또는 SIP 트렁크에 대한 연결을 통해 Enterprise Voice 인프라와 PSTN 간에 신호 및 미디어를 변환하는 타사 하드웨어 구성 요소입니다. 두 토폴로지에서 게이트웨이는 PSTN을 종료합니다. 게이트웨이는 자체 서브넷에서 격리되며 중재 서버를 통해 엔터프라이즈 네트워크에 연결됩니다.

여러 사이트가 있는 엔터프라이즈는 일반적으로 각 사이트에 하나 이상의 게이트웨이를 배포합니다. 분기 사이트는 게이트웨이를 통해 또는 게이트웨이와 서버를 단일 상자에 결합하는 Survivable Branch Appliance를 통해 PSTN에 연결할 수 있습니다. 분기 사이트에서 게이트웨이를 사용하는 경우 WAN 링크가 복원력이 없는 한 등록자 서버와 중재 서버가 모두 사이트에 필요합니다. 프런트 엔드 서버에 배치된 하나 이상의 중재 서버는 각 사이트에서 하나 이상의 게이트웨이에 대한 호출을 라우팅할 수 있습니다. 사이트에 필요한 등록자, 중재 서버 및 게이트웨이를 Survivable Branch Appliance로 배포하는 것이 좋습니다.

PSTN 게이트웨이의 수, 크기 및 위치를 결정하는 것은 아마도 Enterprise Voice 인프라를 계획할 때 가장 중요하고 비용이 많이 드는 결정일 것입니다.

다음은 고려해야 할 기본 질문입니다. 이러한 질문에 대한 답변은 모두 상호 종속되어 있습니다.

• 필요한 PSTN 게이트웨이는 몇 개입니까? 응답은 사용자 수, 예상 동시 호출 수(트래픽 로드) 및 사이트 수(각 사이트에는 1개 필요)에 따라 달라집니다.

• 게이트웨이는 어떤 크기여야 하나요? 응답은 사이트의 사용자 수와 트래픽 부하에 따라 달라집니다.

• 게이트웨이는 어디에 있어야 하나요? 대답은 부분적으로 토폴로지와 organization 지리적 분포에 따라 달라집니다.

  게이트웨이 토폴로지 옵션도 고려해야 합니다(자세한 내용은 이 항목의 뒷부분에 있는 게이트웨이 토폴로지를 참조하세요).

M:N 트렁크 지원

중재 서버는 여러 게이트웨이, 인터넷 전화 통신 서비스 공급자가 제공하는 SBC(세션 테두리 컨트롤러) 또는 둘의 조합을 통해 호출을 라우팅할 수 있습니다. 또한 풀의 여러 중재 서버는 여러 게이트웨이와 상호 작용할 수 있습니다. 중재 서버와 게이트웨이 간에 정의된 논리 경로를 트렁크라고 합니다. 내부 사용자가 PSTN 호출을 배치하는 경우 프런트 엔드 풀의 아웃바운드 라우팅 논리는 특정 호출을 라우팅하는 데 사용할 수 있는 가능한 모든 조합 중에서 라우팅할 트렁크를 선택합니다. DNS 부하 분산을 사용하면 풀의 특정 중재 서버 문제로 인해 호출이 게이트웨이에 도달하지 못하면 호출이 풀의 대체 중재 서버로 다시 시도됩니다.

여러 게이트웨이 계획에 대한 자세한 내용은 비즈니스용 Skype 서버 M:N 트렁크를 참조하세요.

다른 아웃바운드 라우팅 향상에 대한 자세한 내용은 통화 경로를 참조하세요.

게이트웨이 토폴로지

게이트웨이 배포의 기본 질문을 고려할 때 다음 단계를 수행합니다.

1. Enterprise Voice 사용하여 PSTN 연결을 제공하려는 사이트를 계산합니다.

2. 각 사이트의 트래픽을 예측합니다(사용자 수 및 사용자당 시간당 평균 통화 수).

3. 각 사이트에 하나 이상의 게이트웨이를 배포하여 예상 트래픽을 처리합니다.

이 토폴로지를 사용하면 각 사이트와 사이트 간 작업자 간의 호출이 모두 인트라넷을 통해 라우팅됩니다. PSTN에 대한 호출은 엔터프라이즈 IP 네트워크를 통해 대상 번호의 위치에 가장 가까운 게이트웨이로 라우팅됩니다. 그러나 organization 많은 금융 기관 및 기타 대기업처럼 하나 이상의 대륙에 걸쳐 수십 또는 수백 또는 수천 개의 사이트를 지원한다면 어떨까요? 이러한 경우 각 사이트에 별도의 게이트웨이를 배포하는 것은 실용적이지 않습니다.

이 문제를 해결하기 위해 많은 대기업은 하나 또는 몇 개의 대규모 전화 통신 중앙 사이트를 배포하는 것을 선호합니다.

이 토폴로지에서 예상되는 사용자 부하를 수용하기에 충분한 여러 개의 큰 게이트웨이가 각 중앙 사이트에 배포됩니다. 기업 내 사용자에 대한 모든 통화는 회사의 전화 서비스 공급자가 중앙 사이트로 전달합니다. 중앙 사이트의 라우팅 논리는 호출을 인트라넷을 통해 또는 PSTN으로 라우팅해야 하는지 여부를 결정합니다.

게이트웨이 위치

게이트웨이 위치는 선택한 게이트웨이 유형과 구성 방법을 결정할 수도 있습니다. 수십 개의 PSTN 프로토콜이 있으며, 그 중 어느 것도 전 세계 표준이 없습니다. 모든 게이트웨이가 단일 국가/지역에 있는 경우 문제가 되지 않지만 여러 국가/지역에서 게이트웨이를 찾는 경우 각 게이트웨이는 해당 국가/지역의 PSTN 표준에 따라 구성되어야 합니다. 또한 캐나다와 같이 에서 작동하기 위해 인증된 게이트웨이는 인도, 브라질 또는 유럽 연합에서 인증되지 않을 수 있습니다.

게이트웨이 크기 및 번호

대부분의 조직에서 2개에서 최대 960개의 포트까지 범위의 배포를 고려할 PSTN 게이트웨이입니다. (더 큰 게이트웨이가 있지만 주로 전화 서비스 공급자가 사용합니다.) organization 필요한 포트 수를 예측하는 경우 다음 지침을 사용합니다.

• 가벼운 전화 통신 사용량이 있는 조직(시간당 사용자당 하나의 PSTN 호출)은 15명의 사용자마다 하나의 포트를 할당해야 합니다. 예를 들어 사용자가 20명인 경우 두 개의 포트가 있는 게이트웨이가 필요합니다.

• 보통 전화 통신 사용량이 있는 조직(시간당 사용자당 두 개의 PSTN 호출)은 사용자 10명당 하나의 포트를 할당해야 합니다. 예를 들어 사용자가 100명인 경우 하나 이상의 게이트웨이에 총 10개의 포트가 할당되어야 합니다.

• 전화 통신 사용량이 많은 조직(시간당 사용자당 3개 이상의 PSTN 호출)은 5명의 사용자마다 하나의 포트를 할당해야 합니다. 예를 들어 사용자가 47,000명인 경우 10개 이상의 대형 게이트웨이에 총 9,400개의 포트가 할당되어야 합니다.

• 사용자 수 또는 organization 트래픽 양이 증가함에 따라 추가 포트를 획득할 수 있습니다.

지원해야 하는 지정된 수의 사용자에 대해 더 적은 수의 더 큰 게이트웨이 또는 더 작은 게이트웨이를 배포할 수 있습니다. 일반적으로 하나의 게이트웨이가 실패하는 경우 가용성을 유지하기 위해 organization 대한 최소 두 개의 게이트웨이가 권장됩니다.

배포하는 각 PSTN 게이트웨이에는 하나 이상의 해당 중재 서버가 있어야 합니다.