Skype for Business 대한 네트워크 요구 사항 계획
요약: 비즈니스용 Skype 서버 구현하기 전에 아래의 네트워크 구성 요소 고려 사항을 검토합니다.
이러한 topics 정보는 Lync Server를 사용한 네트워크 계획, 모니터링 및 문제 해결 백서에서 추가 세부 정보와 깊이를 설명합니다. 콘텐츠가 Lync 2010 및 Lync 2013을 명시적으로 참조하지만 비즈니스용 Skype 서버 대한 고려 사항은 변경되지 않습니다.
마찬가지로 네트워크에 Wi-Fi 및 유선 액세스가 포함된 경우 Wi-Fi를 통한 Lync 2013 Real-Time Communications 제공 백서가 좋은 참조이며 비즈니스용 Skype 서버 동일하게 적용됩니다.
서버 하드웨어
비즈니스용 Skype 서버 토폴로지의 각 서버의 네트워크 어댑터는 초당 1GBps 이상의 기가비트를 지원해야 합니다. 일반적으로 짧은 대기 시간 및 높은 대역폭 LAN(로컬 영역 네트워크)을 사용하여 비즈니스용 Skype 서버 토폴로지 내의 모든 서버 역할을 연결해야 합니다. LAN의 크기는 토폴로지의 크기에 따라 달라집니다.
Standard Edition 토폴로지에서 서버는 1Gbps 이더넷 또는 이에 상응하는 네트워크를 지원해야 합니다.
Enterprise Edition 토폴로지에서 대부분의 서버는 특히 오디오/비디오(A/V) 회의 및 애플리케이션 공유를 지원하는 경우 1Gbps 이상을 지원하는 네트워크에 있어야 합니다.
PSTN(공중 전화망) 통합의 경우 T1/E1 회선 또는 SIP 트렁크를 사용하여 통합할 수 있습니다.
오디오/비디오 네트워크 요구 사항
비즈니스용 Skype 서버 배포의 오디오/비디오(A/V)에 대한 네트워크 요구 사항은 다음과 같습니다.
DNS 부하 분산을 사용하여 단일 Edge Server 또는 Edge 풀을 배포하는 경우 NAT(네트워크 주소 변환)를 수행하도록 외부 방화벽을 구성할 수 있습니다. NAT를 수행하도록 내부 방화벽을 구성할 수 없습니다. 자세한 내용은 포트 및 방화벽 계획을 참조하세요.
중요
Edge 풀이 있고 하드웨어 부하 분산 장치를 사용하는 경우 Edge 서버에서 공용 IP 주소를 사용해야 하며 NAT 지원 디바이스(예: 방화벽 어플라이언스 또는 LAN 스위치)의 서버 또는 풀에 NAT를 사용할 수 없습니다. 자세한 내용은 비즈니스용 Skype 서버 에지 서버 시나리오를 참조하세요.
organization QoS(서비스 품질) 인프라를 사용하는 경우 미디어 하위 시스템은 이 기존 인프라 내에서 작동하도록 설계되었습니다.
IPsec(인터넷 프로토콜 보안)을 사용하는 경우 A/V 트래픽에 사용되는 포트 범위에 대해 IPsec을 사용하지 않도록 설정하는 것이 좋습니다. 자세한 내용은 IPsec 예외를 참조하세요.
최적의 미디어 품질을 제공하려면 다음을 수행합니다.
사용량이 많은 기간 동안 오디오 스트림당 초당 65Kbps(킬로비트) 및 비디오 스트림당 500Kbps의 처리량을 지원하도록 네트워크 링크를 프로비전합니다. 양방향 오디오 또는 비디오 세션은 두 개의 스트림을 사용하므로 간단한 오디오/전화 연결은 각 스트림을 커버하기 위해 130Kbps가 필요합니다. 비디오도 마찬가지로 총 1,000Kbps를 사용하여 업스트림 및 다운스트림 연결을 수행합니다.
트래픽의 예기치 않은 급증과 시간에 따른 사용 증가에 대처하기 위해 비즈니스용 Skype 서버 미디어 엔드포인트는 다양한 네트워크 조건에 적응하고 오디오 및 비디오 처리량의 3배를 지원하면서 허용 가능한 품질을 유지할 수 있습니다. 네트워크가 과소 프로비전될 때 이 적응성이 문제를 마스킹한다고 가정하지 마세요. 프로비전되지 않은 네트워크에서는 비즈니스용 Skype 서버 미디어 엔드포인트가 다양한 네트워크 조건(예: 임시 높은 패킷 손실)을 동적으로 처리하는 기능이 줄어듭니다.
프로비저닝이 매우 비용이 많이 들고 어려운 네트워크 링크의 경우 더 낮은 트래픽 볼륨에 대한 프로비저닝을 고려해야 할 수 있습니다. 이 시나리오에서는 비즈니스용 Skype 서버 미디어 엔드포인트의 탄력성이 트래픽 볼륨과 최대 트래픽 수준 간의 차이를 흡수하여 음성 품질을 일부 줄이도록 합니다. 또한, 그렇지 않으면 트래픽의 갑작스런 피크를 흡수하는 데 사용할 수있는 헤드 룸의 감소가있을 것입니다.
단기적으로 올바르게 프로비전할 수 없는 링크(예: 매우 가난한 WAN 링크를 사용하는 사이트)의 경우 특정 사용자에 대한 비디오를 사용하지 않도록 설정하는 것이 좋습니다.
최대 부하에서 최대 150밀리초(밀리초)의 엔드 투 엔드 지연(대기 시간)을 보장하도록 네트워크를 프로비전합니다. 대기 시간은 비즈니스용 Skype 서버 미디어 구성 요소가 줄일 수 없는 네트워크 장애이며, 약점을 찾아 제거하는 것이 중요합니다.
바이러스 백신 소프트웨어를 실행하는 서버의 경우 최적의 성능 및 오디오 품질을 제공하기 위해 예외 목록에 비즈니스용 Skype 서버 실행하는 모든 서버를 포함합니다.
IPsec 예외
IPsec(인터넷 프로토콜 보안)(IETF RFC 4301-4309 참조)이 배포된 엔터프라이즈 네트워크의 경우 오디오, 비디오 및 파노라마 비디오 배달에 사용되는 포트 범위에서 IPsec을 사용하지 않도록 설정해야 합니다. 권장 사항은 IPsec 협상으로 인해 미디어 포트 할당이 지연되지 않도록 해야 하기 때문입니다.
다음 표에서는 권장되는 IPsec 예외 설정을 설명합니다.
권장되는 IPsec 예외
| 규칙 이름 | 원본 IP | 대상 IP | 프로토콜 | 원본 포트 | 대상 포트 | 인증 요구 사항 |
|---|---|---|---|---|---|---|
| A/V Edge 서버 내부 인바운드 | 모든 | A/V Edge 서버 내부 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| A/V Edge 서버 외부 인바운드 | 모든 | A/V Edge 서버 외부 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| A/V Edge 서버 내부 아웃바운드 | A/V Edge 서버 내부 | A/V Edge 서버 외부 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| A/V Edge 서버 외부 아웃바운드 | A/V Edge 서버 외부 | 모든 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| 중재 서버 인바운드 | 모든 | 중재 서버 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| 중재 서버 아웃바운드 | 중재 서버 | 모든 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| 회의 참석자 인바운드 | 모든 | 회의 전화 교환을 실행하는 프런트 엔드 서버 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| 회의 참석자 아웃바운드 | 회의 전화 교환을 실행하는 프런트 엔드 서버 | 모든 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| A/V 회의 인바운드 | 모든 | 프런트 엔드 서버 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| A/V 회의 아웃바운드 | 프런트 엔드 서버 | 모든 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| Exchange 인바운드 | 모든 | Exchange 통합 메시징 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| 애플리케이션 공유 서버 인바운드 | 모든 | 애플리케이션 공유 서버 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| 애플리케이션 공유 서버 아웃바운드 | 애플리케이션 공유 서버 | 모든 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| Exchange 아웃바운드 | Exchange 통합 메시징 | 모든 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
| 클라이언트 | 모든 | 모든 | UDP 및 TCP | 모든 | 모든 | 인증 안 함 |
회의 네트워크 요구 사항
IIS(인터넷 정보 서비스) 서버에서 회의 콘텐츠를 다운로드하는 데 사용되는 대역폭은 콘텐츠 크기에 따라 달라집니다. 실제 사용량을 모니터링하고 그에 따라 대역폭 계획을 조정하도록 선택할 수 있습니다.
미디어 트래픽에 대한 네트워크 대역폭 요구 사항
네트워크 계획의 중요한 부분은 네트워크에서 비즈니스용 Skype 서버 생성된 미디어 트래픽을 처리할 수 있도록 하는 것입니다. 이 섹션에서는 해당 미디어 트래픽을 계획하는 데 도움이 됩니다.
미디어 트래픽 네트워크 사용량
코덱 사용량, 해상도 및 활동 수준과 같은 다양한 변수의 수로 인해 미디어 트래픽 대역폭 사용량을 계산하기가 어려울 수 있습니다. 대역폭 사용은 사용되는 코덱의 함수이며 시나리오마다 다를 수 있는 스트림의 활동입니다. 다음 표에서는 비즈니스용 Skype 서버 시나리오에서 일반적으로 사용되는 오디오 코덱을 나열합니다.
오디오 코덱 대역폭
| 오디오 코덱 | 시나리오 | 오디오 페이로드 비트 전송률(KBPS) | 대역폭 오디오 페이로드 및 IP 헤더만(Kbps) | 대역폭 오디오 페이로드, IP 헤더, UDP, RTP 및 SRTP(Kbps) | 대역폭 오디오 페이로드, IP 헤더, UDP, RTP, SRTP 및 정방향 오류 수정(Kbps) |
|---|---|---|---|---|---|
| RTAudio Wideband |
피어 투 피어 |
29.0 |
45.0 |
57.0 |
86.0 |
| RTAudio Narrowband |
피어 투 피어 PSTN |
11.8 |
27.8 |
39.8 |
51.6 |
| G.722 |
회의 |
64.0 |
80.0 |
95.6 |
159.6 |
| G.722 스테레오 |
피어 투 피어 회의 |
128.0 |
144.0 |
159.6 |
223.6 |
| G.711 |
PSTN, 회의 |
64.0 |
80.0 |
92.0 |
156.0 |
| 사이렌 |
회의 |
16.0 |
32.0 |
47.6 |
63.6 |
| SILK Wideband |
피어 투 피어 |
36.0 |
52.0 |
64.0 |
100.0 |
| SILK Wideband |
피어 투 피어 |
26.0 |
42.0 |
54.0 |
80.0 |
| SILK Wideband |
피어 투 피어 |
20.0 |
36.0 |
48.0 |
68.0 |
| SILK 와이드밴드/좁은 밴드 |
피어 투 피어 |
13.0 |
29.0 |
41.0 |
54.0 |
참고
Skype for Business 클라이언트의 PSTN 호출은 일반적으로 높은 대역폭이 필요한 G.711 코덱을 사용합니다. 해당 코덱에 대해 충분한 대역폭을 사용할 수 없는 경우 미디어 로그에서 다음과 유사한 오류와 함께 호출이 실패할 수 있습니다. Atleast one 코덱을 사용하도록 설정해야 합니다( hr: c0042004). 미디어 로그(.blog 파일)는 암호화되며 Microsoft 지원 담당자만 디코딩할 수 있습니다.
이전 테이블의 대역폭 숫자는 20ms 패킷화(초당 50 패킷)를 기반으로 하며, Siren 및 G.722 코덱의 경우 회의 시나리오에서 추가 보안 SRTP(실시간 전송 프로토콜) 오버헤드를 포함하고 스트림이 100% 활성 상태라고 가정합니다. FEC(정방향 오류 수정)는 오디오 스트림의 품질을 유지하기 위해 링크에 패킷 손실이 있을 때 동적으로 사용됩니다.
G.722 코덱의 스테레오 버전은 단일 스테레오 마이크 또는 한 쌍의 모노 마이크를 사용하여 수신기가 회의실에서 여러 스피커를 더 잘 구분할 수 있도록 하는 Lync Room System을 기반으로 하는 시스템에서 사용됩니다.
비디오 해상도 대역폭
| 비디오 코덱 | 해상도 및 가로 세로 비율 | 최대 비디오 페이로드 비트 속도(Kbps) | 최소 비디오 페이로드 비트 속도(Kbps) |
|---|---|---|---|
| H.264 |
320x180(16:9) 212x160(4:3) |
250 |
15 |
| H.264/RTVideo |
424x240(16:9) 320x240(4:3) |
350 |
100 |
| H.264 |
480x270(16:9) 424x320(4:3) |
450 |
200 |
| H.264/RTVideo |
640x360(16:9) 640x480(4:3) |
800 |
300 |
| H.264 |
848x480(16:9) |
1500 |
400 |
| H.264 |
960x540(16:9) |
2000 |
500 |
| H.264/RTVideo |
1280x720(16:9) |
2500 |
700 |
| H.264 |
1920x1080(16:9) |
4000 |
1500 |
| H.264/RTVideo |
960x144(20:3) |
500 |
15 |
| H.264 |
1280x192(20:3) |
1000 |
250 |
| H.264 |
1920x288(20:3) |
2000 |
500 |
비디오의 기본 코덱은 H.264/MPEG-4 Part 10 Advanced Video Coding 표준과 임시 확장성을 위한 확장 가능한 비디오 코딩 확장입니다. 레거시 클라이언트와의 상호 운용성을 유지하기 위해 RTVideo 코덱은 여전히 비즈니스용 Skype 서버 및 레거시 클라이언트 간의 피어 투 피어 호출에 사용됩니다. 비즈니스용 Skype 서버 및 레거시 클라이언트가 있는 회의 세션에서 비즈니스용 Skype 서버 엔드포인트는 비디오 코덱을 모두 사용하여 비디오를 인코딩하고 H.264 비트스트림을 비즈니스용 Skype 서버 클라이언트와 RTVideo 비트스트림을 레거시 클라이언트에 보낼 수 있습니다.
필요한 대역폭은 해상도, 품질, 프레임 속도 및 그림의 동작 또는 변경 양에 따라 달라집니다. 각 해상도에 대해 두 개의 관련 비트 속도가 있습니다.
최대 페이로드 비트 속도 엔드포인트가 최대 프레임 속도의 해상도에 사용할 비트 속도입니다. 이 값은 가장 높은 비디오 및 음질을 허용하는 값입니다.
최소 페이로드 비트 속도 이는 비즈니스용 Skype 서버 엔드포인트가 다음 낮은 해상도로 전환되는 아래 비트 속도입니다. 특정 해상도를 보장하려면 사용 가능한 비디오 페이로드 비트 전송률이 해당 해상도의 최소 비트 속도보다 낮아서는 안됩니다. 이 값은 최대 비트 전송률을 사용할 수 없거나 실용적이지 않은 경우 가능한 가장 낮은 값을 이해하는 데 도움이 됩니다. 일부 사용자의 경우 이러한 낮은 비트 전송률 비디오는 허용되지 않는 비디오 환경을 제공할 수 있으므로 이러한 최소 비디오 페이로드 비트 전송률에 주의하세요. 정적, 비변동 비디오 장면의 경우 실제 비트 전송률이 일시적으로 최소 비트 속도보다 낮을 수 있습니다.
비즈니스용 Skype 서버 많은 해결을 지원합니다. 이렇게 하면 비즈니스용 Skype 서버 다른 네트워크 대역폭 및 수신 클라이언트 기능에 맞게 조정할 수 있습니다. 비즈니스용 Skype 서버 기본 가로 세로 비율은 16:9입니다. 레거시 4:3 가로 세로 비율은 여전히 16:9 가로 세로 비율에서 캡처를 허용하지 않는 웹캠에서 지원됩니다.
비디오 FEC는 비디오 FEC 및 비디오 FEC 없이 별도의 값이 없도록 비디오 페이로드 비트 전송률에 항상 포함됩니다.
엔드포인트는 오디오 또는 비디오 패킷을 지속적으로 스트리밍하지 않습니다. 시나리오에 따라 스트림에 대해 패킷이 전송되는 빈도를 나타내는 다양한 수준의 스트림 활동이 있습니다. 스트림의 활동은 미디어와 시나리오에 따라 달라지며 사용 중인 코덱에 의존하지 않습니다. 피어 투 피어 시나리오에서:
엔드포인트는 사용자가 말할 때만 오디오 스트림을 보냅니다.
두 참가자 모두 오디오 스트림을 받습니다.
비디오를 사용하는 경우 두 엔드포인트는 통화 중에 비디오 스트림을 보내고 받습니다.
정적 비디오 장면의 경우 비디오 코덱이 이전 샘플 이후 변경 없이 비디오의 인코딩 영역을 건너뛰기 때문에 실제 비트 전송률이 일시적으로 매우 낮을 수 있습니다.
회의 시나리오에서 다음을 수행합니다.
엔드포인트는 사용자가 말할 때만 오디오 스트림을 보냅니다.
모든 참가자는 오디오 스트림을 받습니다.
비디오를 사용하는 경우 모든 참가자는 최대 5개의 수신 비디오 스트림과 하나의 파노라마(예: 가로 세로 비율 20:3) 비디오 스트림을 받을 수 있습니다. 기본적으로 5개의 수신 비디오 스트림은 활성 화자 기록을 기반으로 하지만 사용자는 비디오 스트림을 받을 참가자를 수동으로 선택할 수도 있습니다. 다중 비디오를 사용하도록 설정하면 각 비디오 스트림에 대한 해상도 및 대역폭 요구 사항이 낮아집니다.
사용자의 비디오 스트림 보내기를 켜는 각 참가자는 하나 이상의 비디오 스트림을 보냅니다. 비즈니스용 Skype 서버 최대 5개의 비디오 스트림을 전송하여 모든 수신 클라이언트의 비디오 품질을 최적화할 수 있습니다. 전송되는 실제 비디오 스트림 수는 CPU 기능, 사용 가능한 업링크 대역폭 및 특정 비디오 스트림을 요청하는 수신 클라이언트 수에 따라 발신자에 의해 결정됩니다. 가장 일반적인 경우는 레거시 클라이언트가 회의에 참가하는 경우 하나의 H.264 및 하나의 RTVideo 비디오 스트림이 전송되는 것입니다. 또 다른 일반적인 시나리오는 다양한 수신자 요청을 수용하기 위해 여러 H.264 비디오 스트림(예: 다른 비디오 해상도 포함)이 전송된다는 것입니다.
오디오 및 비디오 미디어의 RTP(실시간 전송 프로토콜) 트래픽에 필요한 대역폭 외에도 RTCP(실시간 전송 제어 프로토콜)에는 대역폭이 필요합니다. RTCP는 RTP 스트림의 통계 및 대역 외 제어를 보고하는 데 사용됩니다. 계획하려면 다음 표의 대역폭 번호를 RTCP 트래픽에 사용합니다. 이러한 값은 RTCP에 사용되는 최대 대역폭을 나타내며 컨트롤 데이터의 차이로 인해 오디오 및 비디오 스트림에 대해 다릅니다.
RTCP 대역폭
| 미디어 | RTCP 최대 대역폭(Kbps) |
|---|---|
| 오디오 |
5 |
| 비디오(H.264 또는 RTVideo만 전송/수신됨) |
10 |
| 비디오(H.264 및 RTVideo가 전송/수신됨) |
15 |
용량 계획의 경우 다음과 같은 두 가지 통계가 중요합니다.
FEC가 없는 최대 대역폭 스트림에서 사용할 최대 대역폭입니다. 여기에는 스트림의 일반적인 활동과 FEC 없이 시나리오에서 사용되는 일반적인 코덱이 포함됩니다. 스트림이 100% 활동이며 FEC 사용을 트리거하는 패킷 손실이 없는 경우의 대역폭입니다. 이는 지정된 시나리오에서 코덱을 사용할 수 있도록 할당해야 하는 대역폭의 양을 계산하는 데 유용합니다. FEC는 관리되는 네트워크에서 요구 사항이 될 것으로 예상되지 않습니다.
FEC를 사용하는 최대 대역폭 스트림에서 사용하는 최대 대역폭입니다. 여기에는 스트림의 일반적인 활동과 FEC를 사용하는 시나리오에서 사용되는 일반적인 코덱이 포함됩니다. 스트림이 100% 활동에 있고 FEC를 사용하여 품질을 개선하는 패킷 손실이 있는 경우의 대역폭입니다. 이는 지정된 시나리오에서 코덱을 사용할 수 있도록 허용하고 패킷 손실 조건에서 품질을 유지하기 위해 FEC를 사용할 수 있도록 할당해야 하는 대역폭의 양을 계산하는 데 유용합니다.
다음 표에는 추가 대역폭 값인 일반 대역폭도 나열되어 있습니다. 스트림에서 사용하는 평균 대역폭입니다. 여기에는 스트림의 일반적인 활동과 시나리오에서 사용되는 일반적인 코덱이 포함됩니다. 이 대역폭은 특정 시간에 미디어 트래픽에서 사용되는 대역폭의 양을 근사화하기 위해 사용할 수 있지만, 작업 수준이 평균보다 클 때 개별 호출이 이 값을 초과하므로 용량 계획에는 사용하지 않아야 합니다. 아래 표의 일반적인 비디오 스트림 대역폭은 측정된 고객 데이터에서 관찰된 다양한 비디오 해상도의 혼합을 기반으로 하며, 설치가 작을수록 테이블 데이터와 다른 실제 숫자가 있을 수 있습니다. 예를 들어 피어 투 피어 세션에서 대부분의 사용자는 기본 비디오 렌더링 창을 사용하는 반면, 일부 사용자는 더 나은 비디오 해상도를 허용하기 위해 비즈니스용 Skype 서버 애플리케이션을 늘리거나 최대화합니다.
다음 표에서는 다양한 시나리오에 대한 값을 제공합니다.
피어 투 피어 세션에 대한 오디오/비디오 용량 계획
| 미디어 | 코덱 | 일반적인 스트림 대역폭(Kbps) | FEC가 없는 최대 스트림 대역폭 | FEC를 사용한 최대 스트림 대역폭 |
|---|---|---|---|---|
| 오디오 |
RTAudio Wideband |
39.8 |
62 |
91 |
| 오디오 |
RTAudio Narrowband |
29.3 |
44.8 |
56.6 |
| 오디오 |
SILK Wideband |
44.3 |
69 |
105 |
| 비즈니스용 Skype 서버 엔드포인트를 호출할 때의 기본 비디오 |
H.264 |
460 |
4010(최대 해상도 1920x1080) |
이미 포함됨 |
| Lync 2010 또는 Office Communicator 2007 R2 엔드포인트를 호출할 때의 기본 비디오 |
RTVideo |
460 |
2510(최대 해상도 1280x720) |
이미 포함됨 |
| 비즈니스용 Skype 서버 엔드포인트를 호출할 때의 파노라마 비디오 |
H.264 |
190 |
2010(최대 해상도 1920x288) |
이미 포함됨 |
| Lync 2010 엔드포인트를 호출할 때의 파노라마 비디오 |
RTVideo |
190 |
510(최대 해상도 960x144) |
이미 포함됨 |
회의를 위한 오디오/비디오 용량 계획
| 미디어 | 일반적인 코덱 | 일반적인 스트림 대역폭(Kbps) | FEC가 없는 최대 스트림 대역폭 | FEC를 사용한 최대 스트림 대역폭 |
|---|---|---|---|---|
| 오디오 |
G.722 |
46.1 |
100.6 |
164.6 |
| 오디오 |
사이렌 |
25.5 |
52.6 |
68.6 |
| 기본 비디오 수신 |
H.264 및 RTVideo해 |
260 |
8015 |
해당 사항 없음 |
| 기본 비디오 보내기 |
H.264 및 RTVideo |
270 |
8015 |
해당 사항 없음 |
| 파노라마 비디오 수신 |
H.264 및 RTVideo |
190 |
2010(최대 해상도 1920x288) |
해당 사항 없음 |
| 파노라마 비디오 보내기 |
H.264 및 RTVideo |
190 |
2515² |
해당 사항 없음 |
RT 비디오는 Lync 2010 클라이언트가 회의에 연결되면 H.264 외에 전송됩니다.
여러 스트림이 있는 경우 할당된 대역폭을 동적으로 공유합니다.
기본 비디오의 경우 일반적인 스트림 대역폭은 수신된 모든 비디오 스트림에 대해 집계된 대역폭이며 최대 스트림은 모든 전송 비디오 스트림의 대역폭입니다. 여러 비디오 스트림이 있더라도 일반적인 비디오 대역폭은 피어 투 피어 시나리오보다 작습니다. 많은 비디오 컨퍼런스에서 훨씬 작은 비디오 창으로 이어지는 콘텐츠 공유를 사용하므로 비디오 해상도가 더 작습니다. 지원되는 최대 집계 비디오 페이로드 대역폭은 둘 다에 대해 8000Kbps이며, 전송 및 수신 스트림은 사용됩니다(예: 들어오는 1920x1080p 비디오 스트림이 두 개 있는 경우). 최대값은 실제 구현에서만 거의 볼 수 없는 경우입니다.
갤러리 보기 기능을 사용하는 다자간 회의를 빌드할 때 참가자가 참가할 때 대역폭 사용률이 처음에는 증가한 다음 해상도가 최대값에 맞게 삭제되면 감소합니다.
| 참가자 2명 | 참가자 3명 | 참가자 4명 | 참가자 5명 | 참가자 6명 | |
|---|---|---|---|---|---|
| 받은 최대 해상도 |
1920x1080 |
1280x720 |
640x360 |
640x360 320x240 |
640x360 320x240 |
| 총 평균 비트 전송률 |
2128 |
4050 |
1304 |
1224 |
1565 |
| 총 최대 비트 전송률 |
4063 |
5890 |
2860 |
2699 |
3017 |
파노라마 비디오의 일반적인 스트림 대역폭은 최대 960x144 파노라마 비디오만 스트리밍하는 디바이스를 기반으로 합니다. 1920x288 파노라마 비디오와 함께 디바이스를 사용할 때 일반적인 스트림 대역폭이 증가할 것으로 예상합니다.
PSTN용 오디오 용량 계획
| 미디어 | 일반적인 코덱 | 일반적인 스트림 대역폭(Kbps) | FEC가 없는 최대 스트림 대역폭 | FEC를 사용한 최대 스트림 대역폭 |
|---|---|---|---|---|
| 오디오 |
G.711(컨퍼런스에 PSTN 참가자 포함) |
64.8 |
97 |
161 |
| 오디오 |
RTAudio Narrowband |
30.9 |
44.8 |
56.6 |
이러한 테이블의 네트워크 대역폭 숫자는 단방향 트래픽만 나타내며 각 스트림에 대한 RTCP 트래픽 오버헤드에 대해 5Kbps를 포함합니다.
서비스 품질 관리
QoS(서비스 품질)는 오디오 및 비디오 통신을 위한 최적의 최종 사용자 환경을 제공하기 위해 일부 조직에서 사용되는 네트워킹 기술입니다. QoS는 대역폭이 제한된 네트워크에서 가장 자주 사용됩니다. 많은 수의 네트워크 패킷이 상당히 적은 양의 사용 가능한 대역폭을 위해 경쟁하므로 관리자는 오디오 또는 비디오 데이터를 전달하는 패킷에 더 높은 우선 순위를 할당할 수 있습니다. 이러한 패킷에 더 높은 우선 순위를 부여하면 파일 전송, 웹 검색 또는 데이터베이스 백업과 같은 네트워크 세션보다 오디오 및 비디오 통신이 더 빠르고 중단이 적어 완료될 수 있습니다. 파일 전송 또는 데이터베이스 백업에 사용되는 네트워크 패킷에 "최선의 노력" 우선 순위가 할당되기 때문입니다.
참고
일반적으로 QoS는 내부 네트워크의 통신 세션에만 적용됩니다. QoS를 구현할 때 인터넷 또는 다른 네트워크에서 지원되지 않을 수 있는 특정 방식으로 패킷 표시를 지원하도록 서버 및 라우터를 구성합니다. 서비스 품질이 다른 네트워크에서 지원되더라도 QoS가 서비스를 구성한 것과 똑같은 방식으로 구성된다는 보장은 없습니다. MPLS를 사용하는 경우 MPLS 공급자와 함께 작업해야 합니다.
비즈니스용 Skype 서버 QoS가 필요하지 않지만 강력하게 권장됩니다. 네트워크에서 패킷 손실 문제가 발생하는 경우 사용 가능한 솔루션은 더 많은 대역폭을 추가하거나 QoS를 구현하는 것입니다. 더 많은 대역폭을 추가할 수 없는 경우 QoS를 구현하는 것이 문제를 resolve 유일한 통행료일 수 있습니다.
비즈니스용 Skype 서버 QoS에 대한 전폭적인 지원을 제공합니다. 즉, 이미 QoS를 사용하고 있는 조직은 기존 네트워크 인프라에 비즈니스용 Skype 서버 쉽게 통합할 수 있습니다. 이렇게 하려면 다음 단계를 수행해야 합니다.
Windows를 기반으로 하지 않는 디바이스에 대해 비즈니스용 Skype 서버 QoS를 사용하도록 설정합니다. 기본적으로 QoS는 다른 운영 체제를 실행하는 컴퓨터 및 기타 장치(예: iPhone)에 대해 사용하지 않도록 설정됩니다. 비즈니스용 Skype 서버 사용하여 디바이스에 대해 서비스 품질을 사용하도록 설정하고 사용하지 않도록 설정할 수 있지만 일반적으로 제품을 사용하여 이러한 디바이스에서 사용하는 DSCP 코드를 수정할 수는 없습니다.
회의, 애플리케이션 및 중재 서버에 대한 포트 범위 및 서비스 품질 정책 구성 오디오 및 비디오와 같은 다양한 패킷 유형에 대해 고유한 포트 집합을 예약해야 합니다. 비즈니스용 Skype 서버 사용하면 속성 값을 True 또는 False로 설정하여 QoS를 사용하거나 사용하지 않도록 설정하지 않습니다. 대신 포트 범위를 구성한 다음 그룹 정책 만들고 적용하여 QoS를 사용하도록 설정합니다. 나중에 QoS를 사용하지 않기로 결정한 경우 적절한 그룹 정책 개체를 제거하여 QoS를 "비활성화"할 수 있습니다.
에지 서버에 대한 포트 범위 및 서비스 품질 정책 구성 필수는 아니지만 다른 서버와 동일한 포트 범위를 사용하도록 Edge 서버를 구성할 수 있습니다. QoS 정책 구성은 Edge 서버의 내부 쪽에 대해서만 수행됩니다. QoS는 인터넷이 아닌 내부 네트워크에서 사용하도록 설계되었기 때문입니다.
비즈니스용 Skype 서버 클라이언트에 대한 포트 범위 및 서비스 품질 정책 구성 이러한 포트 범위는 클라이언트 컴퓨터에만 적용되며 일반적으로 서버에 구성된 포트 범위와 다릅니다. 비즈니스용 Skype 서버 Windows 10 이외의 Windows 운영 체제용 QoS를 지원하지 않습니다.
참고
Windows Server 2012 또는 Windows Server 2012 R2를 사용하는 경우 해당 플랫폼에서 QoS를 관리하는 데 사용할 수 있는 새로운 Windows PowerShell cmdlet 집합에 관심이 있을 수 있습니다. 자세한 내용은 Windows PowerShell Cmdlet을 참조하세요.
QoS는 Lync Server를 사용한 네트워크 계획, 모니터링 및 문제 해결 백서에서 자세한 내용과 깊이를 설명합니다. 콘텐츠가 Lync 2010 및 Lync 2013을 명시적으로 참조하지만 비즈니스용 Skype 서버 대한 고려 사항은 변경되지 않습니다.