보안에 대한 네트워크 요구 비즈니스용 Skype
요약: 네트워크 구성 요소를 구현하기 전에 아래 네트워크 구성 요소 고려 사항을 비즈니스용 Skype 서버.
이러한 항목의 정보는 추가 세부 정보와 깊이가 있는 Lync Server 의 네트워크 계획, 모니터링 및 문제 해결 백서에서도 설명됩니다. 콘텐츠가 명시적으로 Lync 2010 및 Lync 2013을 참조하는 동안 콘텐츠에 대한 고려 비즈니스용 Skype 서버 변경되지 않습니다.
마찬가지로 네트워크가 유선 액세스뿐만 아니라 Wi-Fi와 관련된 경우 Wi-Fi를 통해 Lync 2013 Real-Time Communications over Wi-Fi를 전달하는 백서도 참조하는 것이 좋기 때문에 Lync 2013과 동일하게 비즈니스용 Skype 서버.
서버 하드웨어
토폴로지에서 각 서버의 네트워크 비즈니스용 Skype 서버 초당 1GBps 이상을 지원해야 합니다. 일반적으로 낮은 대기 시간 및 높은 대역폭 LAN(local Area Network)을 사용하여 비즈니스용 Skype 서버 토폴로지 내의 모든 서버 역할을 연결해야 합니다. LAN의 크기는 토폴로지의 크기에 따라 다를 수 있습니다.
Standard Edition 토폴로지에서 서버는 1Gbps 이더넷 또는 이에 상응하는 네트워크를 지원해야 합니다.
Enterprise Edition 토폴로지에서 대부분의 서버는 1Gbps 이상을 지원하는 네트워크에 있습니다( 특히 A/V(오디오/비디오) 회의 및 응용 프로그램 공유를 지원하는 경우).
공중 전화망(PSTN) 통합의 경우에는 T1/E1 회선 또는 SIP 트렁크를 사용하여 통합할 수 있습니다.
오디오/비디오 네트워크 요구 사항
비즈니스용 Skype 서버 A/V(오디오/비디오)에 대한 네트워크 요구 사항은 다음과 같습니다.
DNS 부하 분산을 사용하여 단일 에지 서버 또는 에지 풀을 배포하는 경우 NAT(네트워크 주소 변환)를 수행하도록 외부 방화벽을 구성할 수 있습니다. NAT를 수행하도록 내부 방화벽을 구성할 수 없습니다. 자세한 내용은 Port and firewall planning을 참조합니다.
중요
에지 풀이 있으며 하드웨어 부하 균형 장치를 사용하는 경우 에지 서버에서 공용 IP 주소를 사용하고 NAT 지원 장치의 서버 또는 풀(예: 방화벽 어플라이언스 또는 LAN 스위치)에는 NAT를 사용할 수 없습니다. 자세한 내용은 에지 서버 시나리오를 비즈니스용 Skype 서버.
조직에서 QoS(서비스 품질) 인프라를 사용하는 경우 미디어 하위 시스템은 이러한 기존 인프라 내에서 작동하도록 설계됩니다.
IPsec(인터넷 프로토콜 보안)를 사용하는 경우 A/V 트래픽에 사용되는 포트 범위에서 IPSec를 사용하지 않도록 설정하는 것이 좋습니다. 자세한 내용은 IPsec 예외를 참조합니다.
최적의 미디어 품질을 제공하도록 다음을 합니다.
최대 사용 기간 동안 오디오 스트림당 65킬로비트(Kbps) 및 비디오 스트림당 500킬로비트(사용하도록 설정된 경우)의 프로세스를 지원하기 위해 네트워크 링크를 프로비전합니다. 양측 오디오 또는 비디오 세션에서는 두 개의 스트림을 사용하며, 따라서 각 스트림을 다루기 위해 간단한 오디오/전화 연결을 사용하려면 130Kbps가 필요합니다. 비디오도 마찬가지로 총 1000 Kbps를 사용하여 업스트림 및 다운스트림 연결을 전달합니다.
시간이 지날 때 예기치 않은 트래픽 증가 및 사용량 증가에 대응하기 위해 비즈니스용 Skype 서버 미디어 끝점은 다양한 네트워크 조건에 적응하고 허용 가능한 품질을 유지하면서 오디오 및 비디오의 3배에 대한 지원이 가능합니다. 네트워크가 프로비전되지 않은 경우 이러한 적응성이 문제를 마스킹하는 것으로 가정하지 않습니다. 프로비전된 네트워크에서는 다양한 네트워크 조건(예: 일시적인 높은 패킷 손실)을 동적으로 처리하기 위한 비즈니스용 Skype 서버 미디어 끝점의 능력이 감소합니다.
프로비저닝이 매우 많이 드는 네트워크 링크의 경우 더 낮은 트래픽 볼륨에 대한 프로비전을 고려해야 할 수 있습니다. 이 시나리오에서는 음성 품질이 일부 감소하는 비용으로 비즈니스용 Skype 서버 미디어 끝점이 트래픽 볼륨과 최대 트래픽 수준 간의 차이를 탄력적으로 감당하게 합니다. 또한 헤드룸이 감소하여 트래픽의 갑작스러운 최대 사용률을 감당할 수 있습니다.
단기적으로 올바르게 프로비전할 수 없는 링크(예: 매우 불량 WAN 링크를 사용하는 사이트)의 경우 특정 사용자에 대해 비디오를 사용 안 하게 설정하는 것이 좋습니다.
최대 부하에서 150밀리초(밀리초)의 최대 종단-종단 시간 지연(대기 시간)을 보장하기 위해 네트워크를 프로비전합니다. 대기 시간은 미디어 구성 요소의 비즈니스용 Skype 서버 수 없는 네트워크 장애 중 하나일 수 있으며, 취약한 지점을 찾아서 제거하는 것이 중요합니다.
바이러스 백신 소프트웨어를 실행하는 서버의 경우 예외 비즈니스용 Skype 서버 실행 중인 모든 서버를 예외 목록에 포함하여 최적의 성능과 오디오 품질을 제공합니다.
IPsec 예외
IPsec(인터넷 프로토콜 보안)(IETF RFC 4301-4309 참조)이 배포된 엔터프라이즈 네트워크의 경우 오디오, 비디오 및 파노라마 비디오 배달에 사용되는 포트 범위에서 IPsec를 사용하지 않도록 설정해야 합니다. IPsec 협상으로 인해 미디어 포트 할당이 지연되지 않도록 해야 하는 필요성이 권장됩니다.
다음 표에서는 권장되는 IPsec 예외 설정에 대해 설명하고 있습니다.
권장 IPsec 예외
| 규칙 이름 | 원본 IP | 대상 IP | Protocol(프로토콜) | 원본 포트 | 대상 포트 | 인증 요구 사항 |
|---|---|---|---|---|---|---|
| A/V 에지 서버 내부 인바운드 | 모두 | A/V 에지 서버 내부 | UDP 및 TCP | 모두 | 모두 | 인증 안 |
| A/V 에지 서버 외부 인바운드 | 모두 | A/V 에지 서버 외부 | UDP 및 TCP | 모두 | 모두 | 인증 안 |
| A/V 에지 서버 내부 아웃바운드 | A/V 에지 서버 내부 | A/V 에지 서버 외부 | UDP 및 TCP | 모두 | 모두 | 인증 안 |
| A/V 에지 서버 외부 아웃바운드 | A/V 에지 서버 외부 | 모두 | 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 Stereo |
피어 투 피어 회의 |
128.0 |
144.0 |
159.6 |
223.6 |
| G.711 |
PSTN, 회의 |
64.0 |
80.0 |
92.0 |
156.0 |
| Siren |
전화 회의 |
16.0 |
32.0 |
47.6 |
63.6 |
| 10진수 |
피어 투 피어 |
36.0 |
52.0 |
64.0 |
100.0 |
| 10진수 |
피어 투 피어 |
26.0 |
42.0 |
54.0 |
80.0 |
| 10진수 |
피어 투 피어 |
20.0 |
36.0 |
48.0 |
68.0 |
| WIDE 광대역/협대역 |
피어 투 피어 |
13.0 |
29.0 |
41.0 |
54.0 |
참고
비즈니스용 Skype 클라이언트에서 걸린 PSTN 통화는 일반적으로 높은 대역폭이 필요한 G.711 코덱을 사용합니다. 해당 코덱에 충분한 대역폭을 사용할 수 없는 경우 미디어 로그에서 Atleast 하나의 코덱을 사용하도록 설정해야 합니다. hr: c0042004 와 같은 오류로 호출이 실패할 수 있습니다. 미디어 로그(.blog 파일)는 암호화되며 Microsoft 지원 담당자만 디코딩할 수 있습니다.
이전 표의 대역폭 번호는 20ms 패킷화(초당 50 패킷)를 기반으로 하며 Siren 및 G.722 코덱에는 회의 시나리오의 추가 SRTP(실시간 전송 프로토콜) 오버헤드가 포함되고 스트림이 100% 활성 상태인 것으로 가정합니다. FEC(정방 오류 수정)는 오디오 스트림의 품질을 유지하기 위해 링크에 패킷 손실이 있을 때 동적으로 사용됩니다.
G.722 코덱의 스테레오 버전은 단일 스테레오 마이크 또는 모노 마이크 쌍을 사용하여 수신기에서 회의실의 여러 스피커를 보다 잘 구분할 수 있도록 하는 Lync 룸 시스템을 기반으로 하는 시스템에서 사용됩니다.
비디오 해상도 대역폭
| 비디오 코덱 | 해상도 및 가로 세로 비율 | 최대 비디오 페이로드 비트 속도(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 파트 10 고급 비디오 코딩 표준과 임시 확장성을 위한 확장 가능한 비디오 코딩 확장입니다. 레거시 클라이언트와의 상호 운영성을 유지하기 위해 RTVideo 코덱은 클라이언트와 레거시 클라이언트 간의 피어 투 피어 비즈니스용 Skype 서버 사용됩니다. 비즈니스용 Skype 서버 클라이언트와 레거시 클라이언트가 모두 있는 회의 세션에서 비즈니스용 Skype 서버 끝점은 비디오 코덱을 모두 사용하여 비디오를 인코딩하고 H.264 비트스트림을 비즈니스용 Skype 서버 클라이언트로 보내고 RTVideo 비트스트림을 레거시 클라이언트로 보낼 수 있습니다.
필요한 대역폭은 해상도, 품질, 프레임 속도, 그림의 동작 또는 변경 정도에 따라 다를 수 있습니다. 각 해상도에 대해 다음 두 가지의 서로 다른 비트 비율이 있습니다.
최대 페이로드 비트 속도 끝점에서 최대 프레임 속도의 해상도에 사용할 비트 속도입니다. 이 값은 최고 비디오 및 사운드 품질을 허용하는 값입니다.
최소 페이로드 비트 속도 이 비트 속도는 비즈니스용 Skype 서버 끝점이 다음 낮은 해상도로 전환되는 비트 속도입니다. 특정 해상도를 보장하기 위해 사용 가능한 비디오 페이로드 비트 속도는 해당 해상도에 대한 최소 비트 속도 미만이 아니어도 됩니다. 이 값은 최대 비트 비율을 사용할 수 없는 경우 또는 실용적이지 않은 경우 가능한 가장 낮은 값을 이해하는 데 도움이 됩니다. 일부 사용자의 경우 이러한 낮은 비트 속도 비디오는 받아들일 수 없는 비디오 환경을 제공할 수 있으므로 이러한 최소 비디오 페이로드 비트레이트에 주의해야 합니다. 정적 비디오 장면의 경우 실제 비트 속도는 일시적으로 최소 비트 속도 미만으로 떨어질 수 있습니다.
비즈니스용 Skype 서버 여러 가지 해상도를 지원할 수 있습니다. 이를 통해 비즈니스용 Skype 서버 및 수신 클라이언트 기능에 맞게 조정할 수 있습니다. 기본 화면 비율은 비즈니스용 Skype 서버 16:9입니다. 레거시 4:3 세로 비율은 16:9의 화면 비율로 캡처를 허용하지 않는 웹캠에 대해 계속 지원됩니다.
비디오 FEC는 사용 시 항상 비디오 페이로드 비트 속도에 포함되어 있으므로 비디오 FEC와 비디오 FEC가 없는 별도의 값이 없습니다.
끝점에서는 오디오 또는 비디오 패킷을 지속적으로 스트리밍하지 않습니다. 시나리오에 따라 패킷이 스트림에 대해 전송되는 빈도를 나타내는 스트림 작업 수준이 다릅니다. 스트림 작업은 미디어 및 시나리오에 따라 달라지면 사용되는 코덱과는 관련이 없습니다. 피어 투 피어 시나리오의 경우:
끝점은 사용자가 말할 때만 오디오 스트림을 전송합니다.
두 참가자 모두 오디오 스트림을 받습니다.
비디오를 사용하는 경우 두 끝점 모두 통화 중에 비디오 스트림을 보내고 받을 수 있습니다.
정적 비디오 장면의 경우 비디오 코덱이 이전 샘플 이후 변경 없이 비디오의 인코딩 지역을 건너뛰기 때문에 실제 비트 속도는 일시적으로 매우 낮을 수 있습니다.
회의 시나리오의 경우:
끝점에서 사용자가 발표할 때만 스트림을 보냅니다.
모든 참가자가 오디오 스트림을 받습니다.
비디오를 사용하는 경우 모든 참가자는 최대 5개의 수신 비디오 스트림과 1개의 파노라마(예: 가로 세로 비율 20:3) 비디오 스트림을 수신할 수 있습니다. 기본적으로 5개의 수신 비디오 스트림은 현재 발언자 기록을 기반으로 하지만 사용자가 비디오 스트림을 수신하려는 참가자를 수동으로 선택할 수도 있습니다. 다중 비디오가 사용하도록 설정된 경우 각 비디오 스트림에 대한 해상도 및 대역폭 요구 사항이 더 낮아집니다.
사용자의 송신 비디오 스트림을 켜는 각 참가자는 하나 이상의 비디오 스트림을 전송합니다. 비즈니스용 Skype 서버 모든 수신 클라이언트에 대해 비디오 품질을 최적화하기 위해 최대 5개의 비디오 스트림을 전송할 수 있습니다. 전송되는 비디오 스트림의 실제 개수는 CPU 성능, 사용 가능한 업링크 대역폭 및 특정 비디오 스트림을 요청하는 수신 클라이언트 수를 기반으로 전송자에 의해 결정됩니다. 가장 일반적으로 레거시 클라이언트가 회의에 참가할 때는 한 개의 H.264와 한 개의 RTVideo 비디오 스트림이 전송됩니다. 또 다른 일반적인 시나리오에서는 서로 다른 수신자 요청을 수용할 수 있도록 여러 개의 H.264 비디오 스트림(예: 서로 다른 비디오 해상도 사용)이 전송됩니다.
오디오 및 비디오 미디어의 RTP(Real-Time Transport Protocol)에 필요한 대역폭 외에 RTCP(Real-time Transmission Control Protocol)에도 대역폭이 필요합니다. 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 |
| 오디오 |
10진수 |
44.3 |
69 |
105 |
| 끝점을 호출할 비즈니스용 Skype 서버 기본 비디오 |
H.264 |
460 |
4010(최대 해상도 1920x1080) |
이미 포함되어 있습니다. |
| Lync 2010 또는 2007 R2 끝점에 Office Communicator 기본 비디오 |
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 |
| 오디오 |
Siren |
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 미터 |
해당 없음 |
Lync 2010 클라이언트가 회의에 연결되면 H.264 외에 RT 비디오가 전송됩니다.
스트림이 여러 개 있는 경우 할당된 대역폭을 동적으로 공유합니다.
기본 비디오의 경우 일반적인 스트림 대역폭은 수신된 모든 비디오 스트림에 대해 집계된 대역폭이고 최대 스트림은 모든 송신 비디오 스트림에 대한 대역폭입니다. 여러 비디오 스트림을 사용하는 경우에도 많은 비디오 회의가 콘텐츠 공유를 사용하므로 비디오 창이 훨씬 작아지기 때문에 일반적인 비디오 대역폭은 피어 투 피어 시나리오보다 작습니다. 지원되는 집계된 비디오 페이로드 대역폭의 최대값은 사용되는 송신 및 수신 스트림(예: 들어오는 1920x1080p 비디오 스트림이 두 개 있는 경우)에 대해 모두 8000 Kbps입니다. 최대값은 실제 구현에서만 거의 볼 수 없습니다.
갤러리 보기 기능을 사용하는 다중 회의를 구축할 때 참가자가 참가하면 처음에 대역폭 사용률이 증가한 다음 최대값 내에 맞게 해상도가 삭제될 때 대역폭 사용률이 감소합니다.
| 참가자 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 |
이러한 표의 네트워크 대역폭은 단방향 트래픽만 나타내며 각 스트림에 대해 5Kbps의 RTCP 트래픽 오버헤드를 포함합니다.
서비스 품질 관리
QoS(서비스 품질)는 오디오 및 비디오 통신에 대한 최적의 최종 사용자 환경을 제공하기 위해 일부 조직에서 사용되는 네트워킹 기술입니다. QoS는 대역폭이 제한된 네트워크에서 가장 자주 사용됩니다. 많은 수의 네트워크 패킷이 사용 가능한 적은 대역폭을 경쟁하고 있는 경우 관리자는 QoS를 사용하여 오디오 또는 비디오 데이터를 전달하는 패킷에 더 높은 우선 순위를 지정할 수 있습니다. 이러한 패킷에 더 높은 우선 순위를 지정하면 파일 전송, 웹 검색 또는 데이터베이스 백업과 같은 네트워크 세션보다 오디오 및 비디오 통신이 더 빠르고 중단 없이 완료될 수 있습니다. 파일 전송 또는 데이터베이스 백업에 사용되는 네트워크 패킷에 "최선의 노력" 우선 순위가 할당되어 있기 때문에입니다.
참고
일반적으로 QoS는 내부 네트워크의 통신 세션에만 적용됩니다. QoS를 구현할 때 인터넷이나 다른 네트워크에서 지원되지 않을 수 있는 특정 방식으로 패킷 표시를 지원하도록 서버 및 라우터를 구성합니다. 다른 네트워크에서 서비스 품질이 지원되는 경우에도 QoS가 서비스를 구성한 방식과 정확히 동일하게 구성된다고 보장할 수 없습니다. MPLS를 사용하는 경우 MPLS 공급자와 함께 작업해야 합니다.
비즈니스용 Skype 서버 QoS는 필요하지 않지만 권장됩니다. 네트워크에서 패킷 손실 문제가 있는 경우 사용 가능한 솔루션은 대역폭을 추가하거나 QoS를 구현하는 것입니다. 대역폭을 더 추가할 수 없는 경우 QoS를 구현하면 문제를 해결할 수 있습니다.
비즈니스용 Skype 서버 QoS에 대한 모든 지원을 제공합니다. 즉, 이미 QoS를 사용하고 있는 조직은 QoS를 기존 네트워크 인프라에 비즈니스용 Skype 서버 수 있습니다. 이렇게하려면 다음 단계를 따라야 합니다.
사용자 기반이 아닌 비즈니스용 Skype 서버 장치에서 QoS를 사용하도록 Windows. 기본적으로 다른 운영 체제를 실행하는 컴퓨터 및 기타 장치(예: iPhone)에 대해서는 QoS를 사용하지 않도록 설정됩니다. 디바이스에 대한 비즈니스용 Skype 서버 및 사용하지 않도록 설정할 수는 있습니다. 그러나 일반적으로 제품을 사용하여 이러한 장치에서 사용되는 DSCP 코드를 수정할 수는 없습니다.
회의, 응용 프로그램 및 중재 서버에 대한 포트 범위 및 서비스 품질 정책 구성 오디오 및 비디오와 같은 여러 패킷 유형에 대해 고유한 포트 집합을 예약해야 합니다. 이 비즈니스용 Skype 서버 속성 값을 True 또는 False로 설정하여 QoS를 설정하거나 사용하지 않도록 설정하지 않습니다. 대신 포트 범위를 구성한 다음 그룹 정책을 만들어 적용하여 QoS를 사용하도록 설정할 수 있습니다. 나중에 QoS를 사용하지 않도록 결정한 경우 적절한 그룹 정책 개체를 제거하여 QoS를 "사용하지 않도록 설정"할 수 있습니다.
에지 서버에 대한 포트 범위 및 서비스 품질 정책 구성 반드시 필요한 것은 아니지만 다른 서버와 동일한 포트 범위를 사용하도록 에지 서버를 구성할 수 있습니다. QoS 정책 구성은 에지 서버의 내부 쪽에만 수행됩니다. QoS는 인터넷이 아닌 내부 네트워크에서 사용하기 위한 것이기 때문에 그 이유는 바로 QoS입니다.
클라이언트에 대한 포트 범위 및 서비스 품질 정책을 구성하는 비즈니스용 Skype 서버. 이러한 포트 범위는 클라이언트 컴퓨터에만 적용하며 일반적으로 서버에 구성된 포트 범위와 다릅니다. 이 비즈니스용 Skype 서버 다른 운영 체제에 대해 QoS를 Windows 지원하지 Windows 10.
참고
R2 또는 Windows Server 2012 Windows Server 2012 경우 해당 플랫폼에서 QoS를 관리하는 데 사용할 수 있는 새로운 Windows PowerShell cmdlet 집합에 관심이 있을 수 있습니다. 자세한 내용은 Windows PowerShell Cmdlets for Networking을 참조하십시오.
QoS는 추가 세부 정보 및 깊이와 함께 Lync Server 를 사용하여 백서 네트워크 계획, 모니터링 및 문제 해결에서도 설명되어 있습니다. 콘텐츠가 명시적으로 Lync 2010 및 Lync 2013을 참조하는 동안 콘텐츠에 대한 고려 비즈니스용 Skype 서버 변경되지 않습니다.