VoIP - 편집 역사

Pinkgo: /* Adaptive Playout Delay */

2025-06-18T05:02:38Z

Adaptive Playout Delay

← 이전 판		2025년 6월 18일 (수) 05:02 판
61번째 줄:		61번째 줄:
	p<sub>i</sub> = t<sub>i</sub> + d<sub>i</sub> + K·v<sub>i</sub> (K는 상수)		p<sub>i</sub> = t<sub>i</sub> + d<sub>i</sub> + K·v<sub>i</sub> (K는 상수)
	위에서 K·v<sub>i</sub>는 미래 시점으로 재생을 늦추는 역할을 하며, 이를 통해 지연된 패킷 중 대부분이 제시간에 도착하게 한다. 같은 talk spurt 내의 다음 패킷 j의 재생 시각 p<sub>j</sub>는 아래와 같이 계산된다:		위에서 K·v<sub>i</sub>는 미래 시점으로 재생을 늦추는 역할을 하며, 이를 통해 지연된 패킷 중 대부분이 제시간에 도착하게 한다. 같은 talk spurt 내의 다음 패킷 j의 재생 시각 p<sub>j</sub>는 아래와 같이 계산된다:
	q<sub>i</sub> = p<sub>i</sub> − t<sub>i</sub> (첫 패킷이 생성된 후 재생될 때까지 걸린 시간)		q<sub>i</sub> = p<sub>i</sub> − t<sub>i</sub> (패킷이 생성된 후 재생될 때까지 걸린 시간)
	p<sub>j</sub> = t<sub>j</sub> + q<sub>i</sub>		p<sub>j</sub> = t<sub>j</sub> + q<sub>i</sub>

Pinkgo: /* SIP */

2025-06-15T19:17:24Z

SIP

← 이전 판		2025년 6월 15일 (일) 19:17 판
160번째 줄:		160번째 줄:
	** 이때 사용자는 고정된 IP 주소를 갖지 않는다. 이는 DHCP로 동적으로 할당될 수 있고, 각기 다른 IP 주소를 갖는 여러 장치를 동시에 사용할 수도 있기 때문이다.		** 이때 사용자는 고정된 IP 주소를 갖지 않는다. 이는 DHCP로 동적으로 할당될 수 있고, 각기 다른 IP 주소를 갖는 여러 장치를 동시에 사용할 수도 있기 때문이다.
	* 통화 중에 새로운 미디어 스트림 추가, 인코딩 변경, 새 참가자 초대, 통화 전환, 통화 보류 등 통화 관리 기능도 제공한다.		* 통화 중에 새로운 미디어 스트림 추가, 인코딩 변경, 새 참가자 초대, 통화 전환, 통화 보류 등 통화 관리 기능도 제공한다.

			===Name translation, user location===
	발신자는 피통화자에게 전화를 걸고 싶지만, 일반적으로 발신자는 피통화자의 이름이나 이메일 주소만 알고 있다. 따라서 발신자는 피통화자가 현재 사용 중인 호스트의 IP 주소를 얻어야 하는데, 이는 사용자가 이동하며 [[IPv4 Addressing#DHCP\|DHCP]] 프로토콜에 따라 유동적인 IP 주소를 가지거나, 여러 디바이스를 소유하고 있기 때문이다. 이때 연결해주어야 하는 IP 주소는 아래와 같이 상황에 따라 다를 수 있다:		발신자는 피통화자에게 전화를 걸고 싶지만, 일반적으로 발신자는 피통화자의 이름이나 이메일 주소만 알고 있다. 따라서 발신자는 피통화자가 현재 사용 중인 호스트의 IP 주소를 얻어야 하는데, 이는 사용자가 이동하며 [[IPv4 Addressing#DHCP\|DHCP]] 프로토콜에 따라 유동적인 IP 주소를 가지거나, 여러 디바이스를 소유하고 있기 때문이다. 이때 연결해주어야 하는 IP 주소는 아래와 같이 상황에 따라 다를 수 있다:
	{\| class="wikitable"		{\| class="wikitable"
177번째 줄:		179번째 줄:

	===SIP Proxy===		===SIP Proxy===
			SIP 서버의 또 다른 기능은 프록시(Proxy)이다. SIP Proxy는 SIP 기반 통화를 할 때, 발신자와 수신자 사이의 중개자 역할을 하며, 단순히 메시지를 중간에서 전달(relay)하는 역할을 한다. 아래와 같은 예시를 통해 대략적으로 알아보자:
			# 예를 들어 준영이가 승빈이에게 전화를 걸고 싶다. 준영이는 승빈이의 SIP 주소(예: sb0415@example.com)을 가지고 있다.
			# 준영이는 자신의 프록시 서버에게 초대 메시지(invite)를 보내며, 해당 메시지는 승빈이를 목적지로 하는 SIP 요청 메시지이다.
			# 프록시 서버는 이 메시지를 승빈이에게 전달해준다.
			# 승빈이는 이 메시지를 받아보고, 응답 메시지를 보낸다. 응답도 같은 경로를 거꾸로 밟는다.
			# 이 응답에는 승빈이의 IP 주소가 포함되어 있어서, 준영이는 승빈이와 직접 음성/영상 데이터 연결을 할 수 있게 된다.

			===Comparison with H.323===
			H.323이란 ITU에서 개발된 프로토콜이며, 전화망 기반의 설계가 반영되었다. 이는 "완전하고 수직 통합된 프로토콜 모음"으로서 멀티미디어 VoIP 애플리케이션에 필요한 거의 모든 것을 포함한다. 반면 SIP은 IETF에서 개발되어 인터넷 친화적이고, HTTP 스타일의 설계이다. HTTP처럼 텍스트 기반 메시지를 주고받으며, 필요한 기능만 단순하게 정의한 것이 특징이다.

	==각주==		==각주==

Pinkgo: /* SIP */

2025-06-15T19:06:49Z

SIP

@@ 148번째 줄: / 148번째 줄: @@
 하나의 RTP 세션은 해당 VoIP 애플리케이션 연결에 참여하고 있는 모든 호스트들에게 패킷을 멀티캐스트 하기 위해 하나의 멀티캐스트 주소를 사용한다. 즉, 모든 RTP/RTCP 패킷들은 하나의 멀티캐스트 주소를 통해 해당 세션에서 전송된다. 이때 RTP/RTCP 패킷은 서로 다른 포트 번호를 사용하여 구분된다. 이때 참여자가 많아질 수록 RTCP 트래픽을 줄이기 위해 각 참가자는 전송 빈도를 낮춘다. RTCP는 전체 세션 대역폭의 5% 이하만 사용하도록 제한된다. 예를 들어 2Mbps의 RTP 스트림이 존재한다면, RTCP는 100kbps로 제한된다. 이때 이 중 75%는 수신측에게, 25%는 송신측에게 할당된다. 이때 수신측은 75kbps를 참가자 수 R로 나누어 각각 75/R kbps만큼 사용 가능하다.<ref>통화에 참가하는 참가자들은 평균 RTCP 패킷 크기를 기반으로 전송 주기를 계산한다.</ref> 이러한 구조는 figure 5에 잘 나타나 있다.
-== SIP ==
+==SIP==
 ==각주==

Pinkgo: /* RTP */

2025-06-15T18:53:11Z

RTP

← 이전 판		2025년 6월 15일 (일) 18:53 판
129번째 줄:		129번째 줄:

	== RTP ==		== RTP ==
			VoIP 애플리케이션의 송신측은 오디오 청크에 시퀸스 번호와 타임스탬프 등의 헤더 필드를 덧붙힌 후 이를 transport layer로 넘긴다. 이때 애플리케이션이 시퀀스 번호, 타임스탬프, 페이로드 유형(payload type)을 위한 독자적인 방식을 사용하는 대신 표준적인 프로토콜은 도입한다면, 해당 애플리케이션은 해당 프로토콜을 이용하는 다른 네트워크 기반 멀티미디어 애플리케이션들과 더 쉽게 상호 운용될 수 있다. 이러한 역할을 하기 위해서 개발된 프로토콜이 application layer에서 동작하는 RTP(Real-time Transport Protocol)이다. 예를 들어, 두 개의 다른 회사가 각각 VoIP 소프트웨어를 개발하는데 둘 다 RTP를 도입한다면, 한 VoIP 제품을 사용하는 사용자가 다른 VoIP 제품을 사용하는 사용자와 통신할 수 있다. 또한 RTP는 SIP과 같은 다른 프로토콜과도 상호 보완적으로 작동한다.

			RTP는 기본적으로 UDP 위에서, end system에서 동작한다. 송신 측은 미디어 청크를 RTP 패킷에 캡슐화하고, 그 RTP 패킷을 UDP 세그먼트에 담아 IP에 넘긴다. 수신 측은 UDP 세그먼트에서 RTP 패킷을 꺼내고, 그 RTP 패킷에서 미디어 청크를 추출한 후 이를 디코딩 및 재생을 위해 미디어 플레이어에 전달한다. 수신 측의 애플리케이션은 소켓 인터페이스를 통해 RTP 패킷을 수신한다. 애플리케이션은 RTP 패킷에서 오디오 청크를 추출하고 RTP 헤더 필드를 사용하여 해당 오디오 청크를 올바르게 디코딩하고 재생한다. RTP 패킷은 오디오 청크와 RTP 헤더로 구성되며, 다음과 같은 필드를 포함한다:
			* payload type: 어떤 형식의 미디어인지 구분 (예: 오디오/비디오 코덱)
			* sequence number: 패킷 순서를 알아야 재조립 가능
			* timestamp: 재생 시점을 알기 위해 필요
			RTP 라이브러리는 UDP를 확장한 transport layer에 대한 인터페이스를 제공한다. 이에 따라 RTP 라이브러리는 다음과 같은 기능을 제공한다:
			* 포트 번호, IP 주소 처리
			* payload type 식별
			* 패킷 순서 지정
			* 타임스탬핑
			중요한 점은, RTP는 데이터의 적시 전송을 보장하거나 QoS(서비스 품질)를 보장하는 어떠한 메커니즘도 제공하지 않는다는 점이다. 즉 패킷의 도착 보장도 없고, 순서 보장도 없는 단순한 데이터를 formatting하는 규칙일 뿐이다. 따라서 RTP 프로토콜은 end system에서만 작동하며, 라우터는 RTP 패킷을 담은 IP 데이터그램과 그렇지 않은 것을 구별하지 않는다.

			===RTCP(Real-Time Control Protocol)===
			[[파일:RTCP- multiple multicast senders.png\|섬네일\|Figure 5. RTCP: multiple multicast senders]]
			RTCP는 RTP와 함께 작동하며, 퍼포먼스를 제어하는데 사용되는 피드백(feedback)을 제공한다. VoIP 애플리케이션의 각 참가자는 주기적으로 RTCP 제어 패킷을 보내며, 해당 패킷에는 송신자/수신자의 패킷 수, 손실된 패킷의 수, jitter등에 대한 정보가 포함된다. 송신자는 이 피드백을 통해 자신의 전송 동작을 조절(adaptive)할 수 있다.

			하나의 RTP 세션은 해당 VoIP 애플리케이션 연결에 참여하고 있는 모든 호스트들에게 패킷을 멀티캐스트 하기 위해 하나의 멀티캐스트 주소를 사용한다. 즉, 모든 RTP/RTCP 패킷들은 하나의 멀티캐스트 주소를 통해 해당 세션에서 전송된다. 이때 RTP/RTCP 패킷은 서로 다른 포트 번호를 사용하여 구분된다. 이때 참여자가 많아질 수록 RTCP 트래픽을 줄이기 위해 각 참가자는 전송 빈도를 낮춘다. RTCP는 전체 세션 대역폭의 5% 이하만 사용하도록 제한된다. 예를 들어 2Mbps의 RTP 스트림이 존재한다면, RTCP는 100kbps로 제한된다. 이때 이 중 75%는 수신측에게, 25%는 송신측에게 할당된다. 이때 수신측은 75kbps를 참가자 수 R로 나누어 각각 75/R kbps만큼 사용 가능하다.<ref>통화에 참가하는 참가자들은 평균 RTCP 패킷 크기를 기반으로 전송 주기를 계산한다.</ref> 이러한 구조는 figure 5에 잘 나타나 있다.

			== SIP ==

	==각주==		==각주==

Pinkgo: /* Case Study: VoIP with Skype */

2025-06-15T17:45:04Z

Case Study: VoIP with Skype

← 이전 판		2025년 6월 15일 (일) 17:45 판
119번째 줄:		119번째 줄:
	<ref>기존 인터넷 위에 논리적으로 구성된 가상 네트워크를 의미한다.</ref>를 구성하며, 각 피어는 SP(super peer) 또는 SC(Skype Client)<ref>일반 피어(ordinary peer)라고도 한다.</ref>로 분류된다. Skype는 Skype 사용자 이름을 현재의 IP 주소(및 포트 번호)에 매핑하는 인덱스를 관리하는데, 이 인덱스는 슈퍼 피어들 사이에 분산되어 있다. 예를 들어 준영이 승빈에게 전화를 걸고자 할때, 준영의 Skype 클라이언트는 분산되어 있는 인덱스를 검색하여 승빈의 현재 IP 주소를 알아내는 방식이다. 또한 사용자의 로그인 인증을 담당하는 로그인 서버가 존재하며, 이는 Skype 프로토콜에서 유일하게 중앙화된 요소이다.		<ref>기존 인터넷 위에 논리적으로 구성된 가상 네트워크를 의미한다.</ref>를 구성하며, 각 피어는 SP(super peer) 또는 SC(Skype Client)<ref>일반 피어(ordinary peer)라고도 한다.</ref>로 분류된다. Skype는 Skype 사용자 이름을 현재의 IP 주소(및 포트 번호)에 매핑하는 인덱스를 관리하는데, 이 인덱스는 슈퍼 피어들 사이에 분산되어 있다. 예를 들어 준영이 승빈에게 전화를 걸고자 할때, 준영의 Skype 클라이언트는 분산되어 있는 인덱스를 검색하여 승빈의 현재 IP 주소를 알아내는 방식이다. 또한 사용자의 로그인 인증을 담당하는 로그인 서버가 존재하며, 이는 Skype 프로토콜에서 유일하게 중앙화된 요소이다.

	P2P 기술은 Skype 릴레이에서도 사용되는데, 이는 [[NAT]]를 통해 인터넷에 접속하는 호스트 간의 통화를 설정하는데 유용하다. 일반적으로 NAT는 외부에서 가정 네트워크 내부 호스트로의 연결 시작을 막고, 이에 따라 두 Skype 사용자가 모두 NAT 뒤에 있다면, 서로가 세션을 시작할 수 없게 되어 통화가 불가능해 보일 수 있다. 이러한 문제는 SP와 RP(relay peer)의 사용을 통해 이 문제를 해결한다. 예를 들어 준영이가 Skype에 로그인한다면, 준영이는 NAT뒤에 있지 않은 SP에 연결되며 해당 SP에 세션을 시작한다. 이 세션은 통해 준영이와 SP는 서로 제어 메시지를 교환할 수 있다. 이는 승빈이도 마찬가지이다.<br>		P2P 기술은 Skype 릴레이에서도 사용되는데, 이는 [[Internet Protocol#Network Address Translation (NAT)\|NAT]]를 통해 인터넷에 접속하는 호스트 간의 통화를 설정하는데 유용하다. 일반적으로 NAT는 외부에서 가정 네트워크 내부 호스트로의 연결 시작을 막고, 이에 따라 두 Skype 사용자가 모두 NAT 뒤에 있다면, 서로가 세션을 시작할 수 없게 되어 통화가 불가능해 보일 수 있다. 이러한 문제는 SP와 RP(relay peer)의 사용을 통해 이 문제를 해결한다. 예를 들어 준영이가 Skype에 로그인한다면, 준영이는 NAT뒤에 있지 않은 SP에 연결되며 해당 SP에 세션을 시작한다. 이 세션은 통해 준영이와 SP는 서로 제어 메시지를 교환할 수 있다. 이는 승빈이도 마찬가지이다.<br>
	이때 준영이가 승빈이에게 전화를 건다면, 준영이는 SP에게 이를 알리고, 해당 SP는 승빈의 SP에게 이를 전달하며, 승빈의 SP는 승빈이에게 이를 알린다. 승빈이 전화를 수락하면, 두 SP는 제 3의 NAT이 없는 SP(RP)를 선택한다. 해당 RP는 준영과 승빈이 사이의 데이터를 중계하는 역할을 한다. 그리고 각 SP는 준영이와 승빈이에게 각각 RP와 세션을 시작할 것을 지시한다.		이때 준영이가 승빈이에게 전화를 건다면, 준영이는 SP에게 이를 알리고, 해당 SP는 승빈의 SP에게 이를 전달하며, 승빈의 SP는 승빈이에게 이를 알린다. 승빈이 전화를 수락하면, 두 SP는 제 3의 NAT이 없는 SP(RP)를 선택한다. 해당 RP는 준영과 승빈이 사이의 데이터를 중계하는 역할을 한다. 그리고 각 SP는 준영이와 승빈이에게 각각 RP와 세션을 시작할 것을 지시한다.

127번째 줄:		127번째 줄:
	# 로그인이 완료되면 SN을 통해 승빈이의 IP 주소를 알아낸다.<ref>또는 클라이언트가 저장해둔 연락처(buddy list)에서 직접 가져올 수도 있다.</ref>		# 로그인이 완료되면 SN을 통해 승빈이의 IP 주소를 알아낸다.<ref>또는 클라이언트가 저장해둔 연락처(buddy list)에서 직접 가져올 수도 있다.</ref>
	# IP 주소를 알게 되면, 통화 대상자와 직접 P2P 연결을 만든다. 이후 음성 데이터는 중앙 서버를 거치지 않고 바로 통신된다.		# IP 주소를 알게 되면, 통화 대상자와 직접 P2P 연결을 만든다. 이후 음성 데이터는 중앙 서버를 거치지 않고 바로 통신된다.

			== RTP ==

	==각주==		==각주==

Pinkgo: /* Error Concealment */

2025-06-15T17:43:04Z

Error Concealment

@@ 105번째 줄: / 105번째 줄: @@
 이를 구현하기 위한 대표적인 기법 중 하나는 패킷 반복(Packet Repetition)이다. 이는 손실된 패킷을 직전에 도착한 패킷으로 대체하는 것이다. 이는 매우 간단하고 계산 비용이 낮으며, 생각보다 괜찮은 QoS를 제공한다는 장점이 있다.<br>
 또한 보간법(Interpolation)이라는 기법도 존재한다. 이는 손실된 구간의 앞뒤 오디오 데이터를 사용해 중간값을 생성하여 대체하는 것이다. 이는 패킷 반복 기법보다 더 좋은 QoS를 제공하지만, 계산량이 많아진다는 단점이 존재한다.
 ==각주==

Pinkgo: /* 개요 */

2025-06-15T17:20:23Z

개요

← 이전 판		2025년 6월 15일 (일) 17:20 판
3번째 줄:		3번째 줄:
	==개요==		==개요==
	인터넷을 통한 실시간 음성 대화는 종종 인터넷 전화(Internet telephony)라고 불리는데, 사용자 관점에서는 전통적인 회선 교환 전화 서비스와 유사하기 때문이다. 또한 실시간 음성 대화는 일반적으로 VoIP(Voice-over-IP)라고 불린다. 화상 대화(conversational video)는 VoIP와 많은 면에서 유사하지만, 음성뿐 아니라 참가자의 영상도 포함된다는 점에서 차이가 있다.		인터넷을 통한 실시간 음성 대화는 종종 인터넷 전화(Internet telephony)라고 불리는데, 사용자 관점에서는 전통적인 회선 교환 전화 서비스와 유사하기 때문이다. 또한 실시간 음성 대화는 일반적으로 VoIP(Voice-over-IP)라고 불린다. 화상 대화(conversational video)는 VoIP와 많은 면에서 유사하지만, 음성뿐 아니라 참가자의 영상도 포함된다는 점에서 차이가 있다.

			VoIP는 사람의 음성이 말하는 구간(talk spurts)과 침묵 구간(silent periods)이 번갈아 나타난다는 점을 이용한다. 말하는 동한 VoIP 애플리케이션은 64kbps 속도로 데이터를 생성하며, 20ms마다 하나의 청크(160 바이트)를 생성한다. 또한 각 청크에는 application layer의 헤더가 붙으며, 전체 메시지(message)는 보통 UDP로 캡슐화된다. 이에 따라 애플리케이션은 말하는 구간 동안 20ms 간격으로 소켓에 데이터를 전송한다.

	==Limitations of the Best-Effort IP Service==		==Limitations of the Best-Effort IP Service==

Pinkgo: /* 개요 */

2025-06-15T17:16:45Z

개요

← 이전 판		2025년 6월 15일 (일) 17:16 판
2번째 줄:		2번째 줄:

	==개요==		==개요==

	인터넷을 통한 실시간 음성 대화는 종종 인터넷 전화(Internet telephony)라고 불리는데, 사용자 관점에서는 전통적인 회선 교환 전화 서비스와 유사하기 때문이다. 또한 실시간 음성 대화는 일반적으로 VoIP(Voice-over-IP)라고 불린다. 화상 대화(conversational video)는 VoIP와 많은 면에서 유사하지만, 음성뿐 아니라 참가자의 영상도 포함된다는 점에서 차이가 있다.		인터넷을 통한 실시간 음성 대화는 종종 인터넷 전화(Internet telephony)라고 불리는데, 사용자 관점에서는 전통적인 회선 교환 전화 서비스와 유사하기 때문이다. 또한 실시간 음성 대화는 일반적으로 VoIP(Voice-over-IP)라고 불린다. 화상 대화(conversational video)는 VoIP와 많은 면에서 유사하지만, 음성뿐 아니라 참가자의 영상도 포함된다는 점에서 차이가 있다.

Pinkgo: /* Recovering from Packet Loss */

2025-06-15T16:54:51Z

Recovering from Packet Loss

← 이전 판		2025년 6월 15일 (일) 16:54 판
72번째 줄:		72번째 줄:
	FEC(Forward Error Correction) 기법은 원래의 패킷 스트림에 중복 정보(redundant data)를 추가하여 손실된 패킷을 근사하게 혹은 완전히 복구할 수 있도록 하는 기법이다. 따라서 요구되는 데이터 전송률의 크기는 조금 증가되지만, 손실을 복구할 수 있게 되는 것이다.		FEC(Forward Error Correction) 기법은 원래의 패킷 스트림에 중복 정보(redundant data)를 추가하여 손실된 패킷을 근사하게 혹은 완전히 복구할 수 있도록 하는 기법이다. 따라서 요구되는 데이터 전송률의 크기는 조금 증가되지만, 손실을 복구할 수 있게 되는 것이다.

	FEC을 구현하는 방식 중 하나는 n개의 패킷마다 1개의 중복 패킷을 추가하는 것이다. 예를 들어, 3개의 오디오 청크마다 3개의 청크를 XOR하여서 만든 1개의 중복되는 청크를 생성하는 것이다. 이 경우 총 4개의 패킷 중 하나의 패킷은 손실되어도 완전히 복구를 할 수 있다.<ref>하지만 2개 이상의 청크가 손실되면 복구가 불가능하다.</ref> 따라서 그룹의 크기(n + 1)을 작게 유지하면, 패킷 손실이 심하지 않은 경우 대부분 복구할 수 있다. 하지만 그룹 크기가 작을 수록 요구되는 전송률의 크기는 커진다. 예를 들어 n = 3이면 요구되는 전송률은 33% 증가한다. 또한 전체 그룹을 수신하기 전까지 재생을 하지 못하므로, 재생의 지연 시간이 증가한다는 단점이 있다.		FEC을 구현하는 방식 중 하나는 n개의 패킷마다 1개의 중복 패킷을 추가하는 것이다. 예를 들어, 3개의 오디오 청크마다 3개의 청크를 XOR하여서 만든 1개의 중복되는 청크를 생성하는 것이다. 이 경우 총 4개의 패킷 중 하나의 패킷은 손실되어도 완전히 복구를 할 수 있다.<ref>하지만 2개 이상의 청크가 손실되면 복구가 불가능하다.</ref> 따라서 그룹의 크기<code>(n + 1)</code>을 작게 유지하면, 패킷 손실이 심하지 않은 경우 대부분 복구할 수 있다. 하지만 그룹 크기가 작을 수록 요구되는 전송률의 크기는 커진다. 예를 들어 n = 3이면 요구되는 전송률은 33% 증가한다. 또한 전체 그룹을 수신하기 전까지 재생을 하지 못하므로, 재생의 지연 시간이 증가한다는 단점이 있다.

	FEC을 구현하는 또다른 방식은 저해상도의 오디오 스트림을 함께 전송하는 방식이다. 송신자는 두 종류의 고품질 스트림과, 저해상도의 스트림을 생성한다. 이를 위해서 각 n 번째 패킷은 고품질 스트림의 n 번째 청크와, 저해상도 스트림의 n - 1 번째 청크를 결합하여 전송한다. 이렇게 하면 비연속적인 패킷 손실(non-consecutive loss)이 발생했을 때, 다음 패킷에서 이전 청크의 저해상도 버전을 재생하여 손실을 은폐할 수 있다. 이는 손실이 발생하더라도 성공적으로 낮은 품질의 대체 음성을 제공할 수 있다는 점, 전체의 재생 품질이 개선된다는 점, 저해상도의 청크는 작기 때문에 추가적인 전송 부담이 적다는 점, 두 개의 패킷만 있으면 재생이 시작되므로 재생 지연이 작다는 점에서 장점을 가진다.<br>		FEC을 구현하는 또다른 방식은 저해상도의 오디오 스트림을 함께 전송하는 방식이다. 송신자는 두 종류의 고품질 스트림과, 저해상도의 스트림을 생성한다. 이를 위해서 각 n 번째 패킷은 고품질 스트림의 n 번째 청크와, 저해상도 스트림의 <code>n - 1</code> 번째 청크를 결합하여 전송한다. 이렇게 하면 비연속적인 패킷 손실(non-consecutive loss)이 발생했을 때, 다음 패킷에서 이전 청크의 저해상도 버전을 재생하여 손실을 은폐할 수 있다. 이는 손실이 발생하더라도 성공적으로 낮은 품질의 대체 음성을 제공할 수 있다는 점, 전체의 재생 품질이 개선된다는 점, 저해상도의 청크는 작기 때문에 추가적인 전송 부담이 적다는 점, 두 개의 패킷만 있으면 재생이 시작되므로 재생 지연이 작다는 점에서 장점을 가진다.<br>
	이 방식을 변형하여, (n−1)뿐 아니라 (n−2), (n−3) 등의 chunk도 함께 붙이면 연속되는 패킷의 손실까지 커버가 가능하다. 하지만 이는 요구되는 데이터 전송률과 재생 지연이 증가한다는 장점이 있다.		이 방식을 변형하여, <code>(n−1)</code>뿐 아니라 <code>(n−2), (n−3)</code> 등의 chunk도 함께 붙이면 연속되는 패킷의 손실까지 커버가 가능하다. 하지만 이는 요구되는 데이터 전송률과 재생 지연이 증가한다는 장점이 있다.

	===Interleaving===		===Interleaving===
	[[파일:Sending interleaved audio.png\|섬네일\|400x400픽셀\|Figure 3. Sending interleaved audio ]]		[[파일:Sending interleaved audio.png\|섬네일\|400x400픽셀\|Figure 3. Sending interleaved audio ]]
	Interleaving은 오디오 데이터의 순서를 재배열하여 전송하는 방식이다. 이는 인접한 오디오 단위들을 멀리 떨어지게 배치하여 하나의 패킷이 손실되더라도 여러 지점에 짧은 간격의 손실만이 발생하도록 하는 원리이다. 예를 들어, 오디오 스트림이 5ms 단위의 데이터 조각으로 나뉘고, 하나의 청크가 20ms 분량이라고 가정하자. 이 경우 각 청크에 저장되는 오디오 스트림 단위의 번호는 아래와 같다:		Interleaving은 오디오 데이터의 순서를 재배열하여 전송하는 방식이다. 이는 인접한 오디오 단위들을 멀리 떨어지게 배치하여 하나의 패킷이 손실되더라도 여러 지점에 짧은 간격의 손실만이 발생하도록 하는 원리이다. 예를 들어, 오디오 스트림이 5ms 단위의 데이터 조각으로 나뉘고, 하나의 청크가 20ms 분량이라고 가정하자. 이 경우 각 청크에 저장되는 오디오 스트림 단위의 번호는 아래와 같다:
			{\| class="wikitable"
			\|+
			!Chunk
			!스트림 단위 번호
			\|-
			\|1
			\|1, 5, 9, 13
			\|-
			\|2
			\|2, 6, 10, 14
			\|-
			\|3
			\|3, 7, 11, 15
			\|-
			\|4
			\|4, 8, 12, 16
			\|}
	위와 같이 청크를 구성하면 하나의 패킷이 손실되어도 하나의 큰 공백이 아니라, 여러 개의 작은 공백이 발생하므로 청감상의 QoS가 개선된다. 이는 대역폭 증가가 없으므로 낮은 오버헤드를 지닌다는 장점이 있지만, 재생 지연(latency)이 증가한다는 단점이 있다.<ref>따라서 VoIP같은 대화형 서비스에는 부적합한 측면이 있으며, 오히려 저장형 오디오 스트리밍에 더욱 적합하다.</ref>		위와 같이 청크를 구성하면 하나의 패킷이 손실되어도 하나의 큰 공백이 아니라, 여러 개의 작은 공백이 발생하므로 청감상의 QoS가 개선된다. 이는 대역폭 증가가 없으므로 낮은 오버헤드를 지닌다는 장점이 있지만, 재생 지연(latency)이 증가한다는 단점이 있다.<ref>따라서 VoIP같은 대화형 서비스에는 부적합한 측면이 있으며, 오히려 저장형 오디오 스트리밍에 더욱 적합하다.</ref>

Pinkgo: /* Recovering from Packet Loss */

2025-06-15T16:52:38Z

Recovering from Packet Loss

← 이전 판		2025년 6월 15일 (일) 16:52 판
64번째 줄:		64번째 줄:

	==Recovering from Packet Loss==		==Recovering from Packet Loss==
			VoIP 애플리케이션은 jitter 외에도 패킷 손실에도 적절한 대응을 하여 수용 가능한 오디오 품질을 유지하여야 한다. 이렇게 패킷 손실이 발생했을 때도 수용 가능한 오디오 품질을 유지하려는 여러 기법들을 손실 복구 기법(loss recovery schemes)이라고 한다. 이때 패킷 손실은 수신자에게 도착하지 않은 패킷은 물론, 예정된 재생 시간 이후에 도착하여 무시된 패킷들을 포함한다.

			VoIP에서 TCP 기반의 reliable date transfer 서비스를 이용하지 않는 이유는 재생 시점을 놓친 패킷을 재전송해봐야 의미가 없기 때문이다. 또한 congestion으로 인해 폐기된 패킷도 충분히 빨리 복구하기 어렵다. 따라서 VoIP 애플리케이션들은 미리 손실을 예측하고 대비하는 전략을 사용한다. 이를 손실 예측(loss anticipation) 기법<ref>손실 예측 기법은 패킷 손실에 대비해 송신측에서 수행하는 기법이고, 손실 복구 기법은 이미 발생한 손실을 수신측에서 완화하고 복원하는 기법이다.</ref>이라고 한다.

			===FEC(Forward Error Correction)===
			[[파일:Piggybacking lower-quality redundant information.png\|섬네일\|400x400픽셀\|Figure 2. Piggybacking lower-quality redundant information ]]
			FEC(Forward Error Correction) 기법은 원래의 패킷 스트림에 중복 정보(redundant data)를 추가하여 손실된 패킷을 근사하게 혹은 완전히 복구할 수 있도록 하는 기법이다. 따라서 요구되는 데이터 전송률의 크기는 조금 증가되지만, 손실을 복구할 수 있게 되는 것이다.

			FEC을 구현하는 방식 중 하나는 n개의 패킷마다 1개의 중복 패킷을 추가하는 것이다. 예를 들어, 3개의 오디오 청크마다 3개의 청크를 XOR하여서 만든 1개의 중복되는 청크를 생성하는 것이다. 이 경우 총 4개의 패킷 중 하나의 패킷은 손실되어도 완전히 복구를 할 수 있다.<ref>하지만 2개 이상의 청크가 손실되면 복구가 불가능하다.</ref> 따라서 그룹의 크기(n + 1)을 작게 유지하면, 패킷 손실이 심하지 않은 경우 대부분 복구할 수 있다. 하지만 그룹 크기가 작을 수록 요구되는 전송률의 크기는 커진다. 예를 들어 n = 3이면 요구되는 전송률은 33% 증가한다. 또한 전체 그룹을 수신하기 전까지 재생을 하지 못하므로, 재생의 지연 시간이 증가한다는 단점이 있다.

			FEC을 구현하는 또다른 방식은 저해상도의 오디오 스트림을 함께 전송하는 방식이다. 송신자는 두 종류의 고품질 스트림과, 저해상도의 스트림을 생성한다. 이를 위해서 각 n 번째 패킷은 고품질 스트림의 n 번째 청크와, 저해상도 스트림의 n - 1 번째 청크를 결합하여 전송한다. 이렇게 하면 비연속적인 패킷 손실(non-consecutive loss)이 발생했을 때, 다음 패킷에서 이전 청크의 저해상도 버전을 재생하여 손실을 은폐할 수 있다. 이는 손실이 발생하더라도 성공적으로 낮은 품질의 대체 음성을 제공할 수 있다는 점, 전체의 재생 품질이 개선된다는 점, 저해상도의 청크는 작기 때문에 추가적인 전송 부담이 적다는 점, 두 개의 패킷만 있으면 재생이 시작되므로 재생 지연이 작다는 점에서 장점을 가진다.<br>
			이 방식을 변형하여, (n−1)뿐 아니라 (n−2), (n−3) 등의 chunk도 함께 붙이면 연속되는 패킷의 손실까지 커버가 가능하다. 하지만 이는 요구되는 데이터 전송률과 재생 지연이 증가한다는 장점이 있다.

			===Interleaving===
			[[파일:Sending interleaved audio.png\|섬네일\|400x400픽셀\|Figure 3. Sending interleaved audio ]]
			Interleaving은 오디오 데이터의 순서를 재배열하여 전송하는 방식이다. 이는 인접한 오디오 단위들을 멀리 떨어지게 배치하여 하나의 패킷이 손실되더라도 여러 지점에 짧은 간격의 손실만이 발생하도록 하는 원리이다. 예를 들어, 오디오 스트림이 5ms 단위의 데이터 조각으로 나뉘고, 하나의 청크가 20ms 분량이라고 가정하자. 이 경우 각 청크에 저장되는 오디오 스트림 단위의 번호는 아래와 같다:

			위와 같이 청크를 구성하면 하나의 패킷이 손실되어도 하나의 큰 공백이 아니라, 여러 개의 작은 공백이 발생하므로 청감상의 QoS가 개선된다. 이는 대역폭 증가가 없으므로 낮은 오버헤드를 지닌다는 장점이 있지만, 재생 지연(latency)이 증가한다는 단점이 있다.<ref>따라서 VoIP같은 대화형 서비스에는 부적합한 측면이 있으며, 오히려 저장형 오디오 스트리밍에 더욱 적합하다.</ref>

			===Error Concealment===
			오류 은폐(Error Concealment) 기법은 수신자가 손실된 패킷을 유사하게 대체하여 재생하는 기법이다. 이는 음성 신호(사람의 말)은 단기적으로 자기 유사성(self-similarity)이 크므로 가능하다. 이는 패킷의 손실률이 낮고(15% 미만) 패킷의 크기가 짧을 때(4~40ms 분량) 유효하게 작동한다. 반면, 패킷이 손실된 길이가 5~100ms에 가까워 질수록 해당 기법이 유효하게 작동하기 힘들다.

			이를 구현하기 위한 대표적인 기법 중 하나는 패킷 반복(Packet Repetition)이다. 이는 손실된 패킷을 직전에 도착한 패킷으로 대체하는 것이다. 이는 매우 간단하고 계산 비용이 낮으며, 생각보다 괜찮은 QoS를 제공한다는 장점이 있다.<br>
			또한 보간법(Interpolation)이라는 기법도 존재한다. 이는 손실된 구간의 앞뒤 오디오 데이터를 사용해 중간값을 생성하여 대체하는 것이다. 이는 패킷 반복 기법보다 더 좋은 QoS를 제공하지만, 계산량이 많아진다는 단점이 존재한다.

	==각주==		==각주==