이 문서에서는 네트워크 환경이 음성 및 화상 통화 품질에 미치는 영향을 요약합니다. 많은 요소가 오디오, 비디오 및 애플리케이션 공유를 포함하는 Azure Communication Services 실시간 미디어의 품질에 기여합니다. 일부 요인에는 네트워크 품질 및 대역폭, 방화벽, 호스트 및 디바이스 구성이 포함됩니다.
네트워크 품질
기본 네트워크 연결의 품질은 IP를 통해 실시간 미디어에 부정적인 영향을 줄 수 있습니다. 가장 중요한 기여 요인은 다음과 같습니다.
- 대기 시간. 네트워크의 지점 A에서 지점 B까지 IP 패킷을 가져오는 데 걸리는 시간입니다. 네트워크 전파 지연은 두 지점 간의 물리적 거리와 트래픽이 흐르는 디바이스에서 발생하는 다른 오버헤드의 요소입니다. 대기 시간은 단방향 또는 RTT(왕복 시간)로 측정됩니다.
- 패킷 손실. 특정 기간 동안 손실된 패킷의 백분율입니다. 패킷 손실은 오디오 품질에 직접적인 영향을 줍니다. 작은 개별 패킷 손실은 거의 영향을 미치지 않지만, 연속적인 버스트 손실은 전체 오디오가 끊기는 결과를 초래할 수 있습니다.
- 패킷 간 도착 지터(지터라고도 함). 연속 패킷 간의 지연 변화에 대한 평균입니다. Communication Services는 버퍼링을 통해 일부 수준의 지터에 적응할 수 있습니다. 지터가 버퍼링을 초과했을 때 참가자가 그 영향을 인식하게 됩니다.
네트워크 대역폭
동시 Communication Services 미디어 세션 및 기타 비즈니스 애플리케이션에 필요한 대역폭을 지원하도록 네트워크가 구성되어 있는지 확인합니다. 대역폭 병목 현상에 대한 엔드투엔드 네트워크 경로를 테스트하는 것은 멀티미디어 Communication Services 솔루션의 성공적인 배포에 매우 중요합니다.
JavaScript SDK에는 다음과 같은 대역폭 요구 사항이 있습니다.
대역폭 | 시나리오 |
---|---|
40Kbps | 피어 투 피어 오디오 통화 |
500Kbps | 피어 투 피어 오디오 통화 및 화면 공유 |
500Kbps | 360픽셀 해상도에서 30FPS로 진행되는 피어 투 피어 영상 통화 품질 |
1.2Mbps | 30FPS에서 HD 720픽셀 해상도의 피어 투 피어 HD 품질 영상 통화 |
500Kbps | 360픽셀, 30FPS로 그룹 영상 통화 |
1.2Mbps | 30FPS에서 HD 720픽셀 해상도로 HD 그룹 영상 통화 |
1.5Mbps | 30FPS에서 HD 1080 픽셀 해상도의 피어 투 피어 HD 품질 비디오 통화 |
다음 대역폭 요구 사항은 네이티브 Windows, Android 및 iOS SDK에 대한 것입니다.
대역폭 | 시나리오 |
---|---|
30Kbps | 피어 투 피어 오디오 통화 |
130Kbps | 피어 투 피어 오디오 통화 및 화면 공유 |
500Kbps | 360픽셀 해상도에서 30FPS로 진행되는 피어 투 피어 영상 통화 품질 |
1.2Mbps | 30FPS에서 HD 720픽셀 해상도의 피어 투 피어 HD 품질 영상 통화 |
1.5Mbps | 30FPS에서 HD 1080 픽셀 해상도의 피어 투 피어 HD 품질 비디오 통화 |
500Kbps/1Mbps | 그룹 화상 통화 |
1Mbps/2Mbps | HD 그룹 영상 통화, 1080픽셀 화면의 540픽셀 비디오 |
방화벽 구성
통신 서비스 연결은 고품질 멀티미디어 환경을 제공하기 위해 특정 포트 및 IP 주소에 대한 인터넷 연결이 필요합니다. 이러한 포트 및 IP 주소에 액세스할 수 없으면 Communication Services가 제대로 작동하지 않습니다. 사용하도록 설정해야 하는 IP 범위 및 허용 나열된 도메인 목록은 다음과 같습니다.
카테고리 | IP 범위 또는 FQDN | 항구 |
---|---|---|
미디어 트래픽 | Azure 공용 클라우드 IP 주소의 범위는 20.202.0.0/16입니다. 여기에 제공된 범위는 미디어 프로세서 또는 Azure Communication Services TURN 서비스의 IP 주소 범위입니다. | UDP 3478~3481, TCP 포트 443 |
신호, 원격 분석, 등록 | *.skype.com, *.microsoft.com, *.azure.net, *.azure.com, *.office.com | TCP 443, 80 |
자동화 미디어 호출 | 52.112.0.0/14, 52.122.0.0/15, 2603:1063::/38 | UDP: 3478, 3479, 3480, 3481 |
콜 자동화 콜백 URL | *.lync.com, *.teams.cloud.microsoft, *.teams.microsoft.com, teams.cloud.microsoft, teams.microsoft.com, 52.112.0.0/14, 52.122.0.0/15, 2603:1027::/48, 2603:1037::48, 2603:1047::/48, 2603:1057::/48, 2603:1063::/38, 2620:1ec:6::/48, 2620:1ec:40::/42 | TCP: 443, 80 UDP: 443 |
미국 정부 GCC High 고객만 다음 엔드포인트에 도달할 수 있습니다.
카테고리 | IP 범위 또는 FQDN | 항구 |
---|---|---|
미디어 트래픽 | 52.127.88.0/21, 52.238.114.160/32, 52.238.115.146/32, 52.238.117.171/32, 52.238.118.132/32, 52.247.167.192/32, 52.247.169.1/32, 52.247.172.50/32, 52.247.172.103/32, 104.212.44.0/22, 195.134.228.0/22 | UDP 3478~3481, TCP 포트 443 |
신호, 원격 분석, 등록 | *.gov.teams.microsoft.us, *.infra.gov.skypeforbusiness.us, *.online.gov.skypeforbusiness.us, gov.teams.microsoft.us | TCP 443, 80 |
네트워크 최적화
다음 작업은 선택 사항이며 Communication Services를 롤아웃하는 데 필요하지 않습니다. 네트워크 및 Communication Services 성능을 최적화하거나 네트워크 제한 사항이 있는 경우 이 지침을 사용합니다.
다음과 같은 경우 추가로 최적화할 수 있습니다.
- Communication Services는 느리게 실행됩니다. 대역폭이 부족할 수 있습니다.
- 전화가 계속 끊깁니다. 방화벽 및 프록시 차단으로 인해 호출이 삭제될 수 있습니다.
- 통화는 정적이고 잘리거나 음성이 로봇처럼 들립니다. 지터 또는 패킷 손실로 인해 이러한 문제가 발생할 수 있습니다.
네트워크 최적화 작업 | 세부 정보 |
---|---|
네트워크 계획 | 이 설명서에서는 호출에 대한 최소한의 네트워크 요구 사항을 찾을 수 있습니다. 네트워크 계획에 대한 Teams 예제를 참조하세요. |
외부 이름 해결 | Communication Services SDK를 실행하는 모든 컴퓨터가 외부 DNS 쿼리를 확인하여 통신 서비스 사용자가 제공하는 서비스를 검색할 수 있고 방화벽이 액세스를 차단하지 않는지 확인합니다. SDK에서 *.skype.com, *.microsoft.com, *.azure.net, *.azure.com 및 *.office.com 주소를 확인할 수 있는지 확인합니다. |
세션 지속성 유지 | 방화벽이 UDP에 대한 매핑된 NAT(네트워크 주소 변환) 주소 또는 포트를 변경하지 않는지 확인합니다. |
NAT 풀 크기 확인 | 사용자 연결에 필요한 NAT 풀 크기의 유효성을 검사합니다. 여러 사용자 및 디바이스가 NAT 또는 포트 주소 변환을 사용하여 Communication Services에 액세스하는 경우 공개적으로 라우팅 가능한 각 IP 주소 뒤에 숨겨진 디바이스가 지원되는 수를 초과하지 않는지 확인합니다. 포트 소진을 방지하도록 NAT 풀에 적절한 공용 IP 주소를 할당해야 합니다. 포트 고갈은 내부 사용자 및 디바이스가 Communication Services에 연결할 수 없게 됩니다. |
침입 감지 및 방지 지침 | 환경에 아웃바운드 연결에 대한 추가 보안 계층을 위해 침입 감지 시스템 또는 침입 방지 시스템이 배포된 경우 모든 Communication Services URL을 허용합니다. |
분할 터널 VPN 구성 | 일반적으로 분할 터널 VPN이라고 하는 VPN(가상 사설망)을 우회하는 Teams 트래픽에 대한 대체 경로를 제공합니다. 분할 터널링은 Communication Services에 대한 트래픽이 VPN을 통과하지 않고 대신 Azure로 직접 이동한다는 것을 의미합니다. VPN을 우회하면 미디어 품질에 긍정적인 영향을 미치며 VPN 디바이스 및 조직의 네트워크에서 부하가 줄어듭니다. 분할 터널 VPN을 구현하기 위해 VPN 공급업체와 협력하세요. VPN 우회를 권장하는 다른 이유:
|
QoS 구현 | QoS(서비스 품질)를 사용하여 패킷 우선순위를 구성합니다. QoS는 통화 품질을 향상시키고 통화 품질을 모니터링하고 문제를 해결하는 데 도움이 됩니다. QoS는 관리 네트워크의 모든 세그먼트에 구현해야 합니다. 네트워크가 대역폭에 적절하게 프로비전된 경우에도 QoS는 예기치 않은 네트워크 이벤트가 발생할 경우 위험 완화를 제공합니다. QoS를 사용하여 이러한 예상치 않은 이벤트가 품질에 부정적인 영향을 주지 있도록 음성 트래픽이 우선시됩니다. |
Wi-Fi 최적화 | VPN과 마찬가지로 Wi-Fi 네트워크가 반드시 실시간 미디어를 지원하도록 설계되거나 구성되지는 않습니다. Communication Services를 지원하기 위한 Wi-Fi 네트워크를 계획하거나 최적화하는 것은 고품질 배포를 위한 중요한 고려 사항입니다. 다음 요소를 고려합니다.
|
운영 체제 및 브라우저(JavaScript SDK용)
Communication Services 음성 및 비디오 SDK는 특정 운영 체제 및 브라우저를 지원합니다. 호출 SDK가 지원하는 운영 체제 및 브라우저에 대해 통화 개념 설명서에서 알아봅니다.
다음 단계
- 라이브러리 호출에 대해 자세히 알아봅니다.
- 클라이언트 서버 아키텍처에 대해 알아봅니다.
- 호출 흐름 토폴로지에 대해 알아봅니다.
- Azure Communication Services를 Azure ExpressRoute와 통합하는 방법에 대해 알아봅니다.