비즈니스용 Skype의 네트워크 요구 사항 계획

 

마지막으로 수정된 항목: 2016-12-20

비즈니스용 Skype 서버 토폴로지에 있는 각 서버의 네트워크 어댑터는 1Gbps 이상을 지원해야 합니다. 일반적으로 대기 시간이 낮고 대역폭이 높은 LAN을 사용하여 비즈니스용 Skype 서버 토폴로지 내의 모든 서버 역할을 연결해야 합니다. LAN의 크기는 토폴로지 크기에 따라 달라집니다.

  • Standard Edition 토폴로지의 경우 서버가 1Gbps 또는 이에 상응하는 이더넷을 지원하는 네트워크에 있어야 합니다.

  • Enterprise Edition 토폴로지의 경우, 특히 A/V(오디오/비디오) 회의와 응용 프로그램 공유를 지원할 경우에는 대부분의 서버가 1Gbps 이상을 지원하는 네트워크에 있어야 합니다.

공중 전화망(PSTN) 통합의 경우에는 T1/E1 회선 또는 SIP 트렁크를 사용하여 통합할 수 있습니다.

비즈니스용 Skype 서버 배포의 A/V(오디오/비디오)에 대한 네트워크 요구 사항은 다음과 같습니다.

  • DNS 부하 분산을 사용하여 단일 에지 서버 또는 에지 풀을 배포하는 경우 external 방화벽을 구성하여 네트워크 주소 변환(NAT)을 수행할 수 있습니다. internal 방화벽은 NAT를 수행하도록 구성할 수 없습니다. 자세한 내용은 Lync Server 2013에 대한 외부 A/V 방화벽 및 포트 요구 사항 확인을 참조하세요.

    important중요:
    에지 풀이 있으며 하드웨어 부하 분산 장치를 사용하는 경우에는 에지 서버에서 공용 IP 주소를 사용해야 하며 NAT 지원 장치(예: 방화벽 어플라이언스 또는 LAN 스위치)에서 서버나 풀에 NAT를 사용할 수 없습니다. 자세한 내용은 Lync Server 2013의 포트 요약 - 하드웨어 부하 분산 장치를 사용하는 조정된 통합 에지를 참조하세요.
  • 조직에서 QoS(서비스 품질) 인프라를 사용하는 경우 미디어 하위 시스템은 이러한 기존 인프라 내에서 작동하도록 설계됩니다.

  • IPsec(인터넷 프로토콜 보안)를 사용하는 경우 A/V 트래픽에 사용되는 포트 범위에서 IPSec를 사용하지 않도록 설정하는 것이 좋습니다. 자세한 내용은 Lync Server 2013의 IPsec 예외를 참조하세요.

최적의 미디어 품질을 제공하려면 다음을 수행합니다.

  • 최대 사용 기간 동안 오디오 스트림당 65Kbps 및 비디오 스트림(사용 가능한 경우)당 500Kbps의 처리량을 지원하도록 네트워크 링크를 프로비전합니다. 양방향 오디오 또는 비디오 세션은 두 개의 스트림을 사용하므로, 단순한 오디오/전화 연결에는 각 스트림을 처리하는 데 130Kbps가 필요합니다. 마찬가지로 비디오는 총 1000Kbps를 사용하여 업스트림 및 다운스트림 연결을 수행합니다.

  • 예상치 않은 급격한 트래픽 증가 및 시간에 따라 증가하는 사용량을 처리하기 위해 비즈니스용 Skype 서버 미디어 끝점은 다양한 네트워크 조건에 맞게 조정될 수 있고, 오디오 및 비디오에 대한 처리량의 세 배를 지원합니다. 이러한 적응 가능성 때문에 네트워크를 충분하지 않게 프로비전해도 되는 것으로 간주해서는 안 됩니다. 충분하지 않게 프로비전된 네트워크의 경우, 비즈니스용 Skype 서버 미디어 끝점에서 일시적으로 높은 패킷 손실과 같은 다양한 네트워크 조건을 동적으로 처리할 수 있는 기능이 떨어집니다.

  • 프로비전이 상당히 어렵고 비용이 많이 드는 네트워크 링크의 경우 낮은 트래픽 볼륨에 대해 프로비전하는 것을 고려할 수 있습니다. 이러한 경우 음성 품질은 약간 저하되지만 비즈니스용 Skype 서버 미디어 끝점에서 해당 트래픽 볼륨과 최고 트래픽 수준 사이의 차이를 탄력적으로 줄일 수 있게 됩니다. 이 경우, 트래픽의 급격한 증가를 수용하는 데 사용할 수 있는 헤드 공간도 감소합니다.

  • 매우 불량한 WAN 링크를 사용하는 사이트 등과 같이 단기간에 올바로 프로비전할 수 없는 링크의 경우 특정 사용자에 대해 비디오를 비활성화하는 것을 고려해 보세요.

  • 최대 종단 간 지연(대기 시간)이 최대 부하에서 150ms가 되도록 네트워크를 프로비전합니다. 대기 시간은 비즈니스용 Skype 서버 미디어 구성 요소에서 줄일 수 없는 네트워크 장애 중 하나이므로 취약한 부분을 찾아서 제거하는 것이 중요합니다.

  • 바이러스 백신 소프트웨어를 실행하는 서버의 경우에는 최적의 성능과 오디오 품질을 제공할 수 있도록 비즈니스용 Skype 서버를 실행하는 모든 서버를 예외 목록에 포함합니다.

IIS(인터넷 정보 서비스) 서버에서 회의 콘텐츠를 다운로드하는 데 사용되는 대역폭은 콘텐츠의 크기에 따라 다릅니다. 실제 사용량을 모니터링하고 이에 맞게 대역폭 계획을 조정할 수 있습니다.

네트워크 계획에서 중요한 부분은 네트워크가 비즈니스용 Skype 서버로 생성되는 미디어 트래픽을 처리할 수 있도록 보장하는 것입니다. 이 섹션에서는 이러한 미디어 트래픽을 계획하는 데 도움을 줍니다.

미디어 트래픽 대역폭 사용량은 코덱 사용, 해상도, 작업 수준과 같은 다양한 변수로 인해 계산하기 어려울 수 있습니다. 대역폭 사용량은 사용된 코덱과 스트림 작업의 영향을 받으며, 이는 시나리오마다 다를 수 있습니다. 다음 표에는 비즈니스용 Skype 서버 시나리오에서 일반적으로 사용되는 오디오 코덱이 나열되어 있습니다.

오디오 코덱 대역폭

오디오 코덱 시나리오 오디오 페이로드 비트 전송률(KBPS) 대역폭 오디오 페이로드 및 IP 헤더만(Kbps) 대역폭 오디오 페이로드, IP 헤더, UDP, RTP 및 SRTP(Kbps) 대역폭 오디오 페이로드, IP 헤더, UDP, RTP, SRTP 및 정방향 오류 정정(Kbps)

RTAudio 광대역

피어 투 피어

29.0

45.0

57.0

86.0

RTAudio 협대역

피어 투 피어 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

SILK 광대역

피어 투 피어

36.0

52.0

64.0

100.0

SILK 광대역

피어 투 피어

26.0

42.0

54.0

80.0

SILK 광대역

피어 투 피어

20.0

36.0

48.0

68.0

SILK 광대역/협대역

피어 투 피어

13.0

29.0

41.0

54.0

위 표의 대역폭은 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 Part 10 고급 비디오 코딩 표준입니다. 레거시 클라이언트와의 상호 운용성을 유지 관리하기 위해서는 비즈니스용 Skype 서버 및 레거시 클라이언트 사이의 피어 투 피어 통화에 RTVideo 코덱이 계속 사용됩니다. 비즈니스용 Skype 서버와 레거시 클라이언트를 모두 포함하는 회의 세션에서 비즈니스용 Skype 서버 끝점은 두 비디오 코덱을 모두 사용해서 비디오를 인코딩하고 H.264 비트스트림은 비즈니스용 Skype 서버 클라이언트로, RTVideo 비트스트림은 레거시 클라이언트로 전송합니다.

필요한 대역폭은 해상도, 품질, 프레임 속도, 움직임의 양 또는 그림의 변화 등에 따라 달라집니다. 각 해상도에 대해 두 개의 관련 비트 전송률이 있습니다.

  • 최대 페이로드 비트 전송률   끝점에서 최대 프레임 속도로 이 해상도에 사용할 비트 전송률입니다. 최고의 비디오 및 사운드 품질을 허용하는 값입니다.

  • 최소 페이로드 비트 전송률   비즈니스용 Skype 서버 끝점에서 그 다음으로 낮은 해상도로 전환하는 데 기준으로 사용되는 하위 비트 전송률입니다. 특정 해상도를 보장하기 위해서는 사용 가능한 비디오 페이로드 비트 전송률이 해당 해상도에 대한 최소 비트 전송률 아래로 떨어져서는 안됩니다. 이 값은 최대 비트 전송률이 가능하지 않거나 실용적이지 않을 경우 가능한 최저 값을 이해하는 데 도움이 됩니다. 일부 사용자의 경우 이렇게 낮은 비트 전송률의 비디오는 허용할 수 없는 비디오 환경을 제공할 수 있으므로 이러한 최소 비디오 페이로드 비트 전송률을 사용할 때는 주의가 필요합니다. 움직임이 거의 없는 정적인 비디오 장면에서는 실제 비트 전송률이 일시적으로 최소 비트 전송률보다 아래로 떨어질 수 있습니다.

비즈니스용 Skype 서버에서는 많은 해상도가 지원됩니다. 이를 통해 비즈니스용 Skype 서버에서 여러 가지 네트워크 대역폭 및 수신 클라이언트 기능에 맞게 조정할 수 있습니다. 비즈니스용 Skype 서버의 기본 가로 세로 비율은 16:9입니다. 16:9 가로 세로 비율의 캡처를 허용하지 않는 웹 캠에서는 기존 가로 세로 비율인 4:3이 여전히 지원됩니다.

비디오 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 광대역

39.8

62

91

오디오

RTAudio 협대역

29.3

44.8

56.6

비즈니스용 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

오디오

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 ²

해당 사항 없음

1. RT 비디오는 Lync 2010 클라이언트가 회의에 연결되면 H.264에 추가하여 전송됩니다.

2. 여러 스트림이 있는 경우 할당된 대역폭을 동적으로 공유합니다.

기본 비디오의 경우 일반 스트림 대역폭은 수신된 모든 비디오 스트림에 대해 집계된 대역폭이고 최대 스트림은 모든 송신 비디오 스트림에 대한 대역폭입니다. 다중 비디오 스트림의 경우에는 여러 비디오 회의에서 사용되는 콘텐츠 공유로 인해 비디오 창이 훨씬 작아지고 따라서 비디오 해상도도 작아지기 때문에 피어 투 피어 시나리오보다 일반 비디오 대역폭이 더 작습니다. 지원되는 최대 집계된 비디오 페이로드 대역폭은 송신 및 수신 스트림 모두 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

64.8

97

161

오디오

RTAudio 협대역

30.9

44.8

56.6

이러한 표의 네트워크 대역폭은 단방향 트래픽만 나타내며 각 스트림에 대해 5Kbps의 RTCP 트래픽 오버헤드를 포함합니다.

QoS(서비스 품질)는 음성 및 화상 통신의 최종 사용자 경험을 최적화하기 위해 일부 조직에서 사용되는 네트워킹 기술입니다. QoS는 대역폭 제약이 있는 네트워크에서 흔히 사용됩니다. 다수의 네트워크 패킷이 상당히 적은 양의 가용 대역폭을 놓고 경합하는 경우 관리자가 QoS를 사용하여 오디오 또는 비디오 데이터를 전송하는 패킷에 보다 높은 우선 순위를 할당할 수 있습니다. 이러한 패킷에 보다 높은 우선 순위를 지정하면 음성 및 화상 통신이 파일 전송, 웹 브라우징, 데이터베이스 백업 등이 포함된 네트워크 세션보다 더욱 빠르게 수행되며 중단이 줄어듭니다. 파일 전송 또는 데이터베이스 백업에 사용되는 네트워크 패킷에 "최상의 노력" 우선 순위가 할당되어 있기 때문입니다.

note참고:
대체로 QoS는 내부 네트워크의 통신 세션에만 적용됩니다. QoS를 구현할 때는 인터넷이나 기타 네트워크에서 지원되지 않을 수도 있는 특정 방식으로 패킷 표시가 되도록 서버와 라우터를 구성합니다. 다른 네트워크에서 QoS가 지원되는 경우에도 서비스를 구성한 것과 정확히 같은 방식으로 QoS가 구성된다는 보장은 없습니다. MPLS를 사용 중인 경우 MPLS 제공업체에 문의하여 작업해야 합니다.

비즈니스용 Skype 서버에는 QoS가 필요 없지만, 강력히 권장됩니다. 네트워크에서 패킷 손실 문제가 발생하는 경우 사용할 수 있는 솔루션은 대역폭을 추가하거나 QoS를 구현하는 것입니다. 대역폭을 추가하는 것이 불가능한 경우에는 QoS 구현이 문제 해결을 위한 유일한 방법일 수 있습니다.

비즈니스용 Skype 서버는 QoS를 완벽히 지원합니다. 즉, QoS를 이미 사용하고 있는 조직에서는 비즈니스용 Skype 서버를 기존 네트워크 인프라에 손쉽게 통합할 수 있습니다. 이렇게 하려면 다음 단계를 따라야 합니다.

note참고:
Windows Server 2012 또는 Windows Server 2012 R2를 사용 중인 경우 해당 플랫폼에서 QoS 관리에 사용할 수 있는 새 Windows PowerShell cmdlet 집합이 필요할 수 있습니다. 자세한 내용은 Windows PowerShell의 네트워크 QoS cmdlet(http://go.microsoft.com/fwlink/p/?LinkId=285379)을 참조하세요.
 
표시: