VoIP

상위 문서: Multimedia Networking

개요

인터넷을 통한 실시간 음성 대화는 종종 인터넷 전화(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

IP(Internet Protocol)는 Best-Effort 서비스를 제공한다. 즉, IP는 각 데이터그램을 출발지에서 목적지로 가능한 한 빨리 전송하려고 노력하지만, 지연 시간이나 패킷 손실 등에 대한 보장은 하지 않는다. 이는 큰 문제가 될 수 있는데, VoIP 애플리케이션은 지연(delay), 지터(jitter), 손실(loss)에 매우 민감하기 때문이다. 이때 VoIP 애플리케이션이 reliable data transfer를 위해서 TCP를 사용하지 않는 이유는 TCP의 재전송 메커니즘이 end system 사이의 지연을 증가시키기 때문이다. 또한 TCP의 혼잡 제어는 패킷 손실이 발생했을 때 전송 속도를 낮추므로 수신 속도보다 송신 속도가 느려질 수 있고, 이에 따라 버퍼 고갈(buffer starvation)이 발생하여 수신자 측에서 음성 이해 가능성(intelligibility)이 심각하게 저하될 수 있다. 이에 따라 대부분의 VoIP 애플리케이션은 기본적으로 UDP를 사용한다.

해당 문서에서는 best-effort 네트워크 환경에서도 application layer에서 VoIP 성능을 향상시킬 수 있는 방법들을 다룬다. 이에 대한 논의를 구체적으로 하기 위해서, 다음의 VoIP 예시를 사용한다:

• 송신자는 초당 8,000 바이트를 생성한다.
• 송신자는 20ms마다 바이트들을 모아 하나의 청크로 만든다.
• 이 chunk는 특수 헤더와 함께 UDP 세그먼트에 캡슐화되어 전송된다.
  • 계산하면, 20ms × 8,000 bytes/sec = 160 bytes. 즉, 20ms마다 160바이트 UDP 세그먼트가 전송된다.

Packet Loss

이 상황에서 수신자는 언제 청크를 재생할지, 누락된 청크에 대해서 어떻게 대응할지에 대해서 결정해야 한다. VoIP 애플리케이션에서 생성된 UDP 세그먼트는 IP 데이터그램으로 캡슐화되어 전송된다. 이 데이터그램은 전송 중에 라우터의 버퍼(큐)를 거치는데, 이 중 하나라도 버퍼가 가득 차 있다면, 해당 IP 데이터그램은 폐기(dropped)되고 수신자에게 도달하지 못한다. 하지만 패킷 손실은 생각보다 치명적이지 않을 수도 있는데, 실제로 VoIP 애플리케이션에서 1~20% 정도의 손실률은 허용 가능하며, 이는 음성의 인코딩 방식과, 패킷 손실을 은폐하는 기술에 따라 달라진다. 예를 들어 FEC(Forward Error Correction) 기법은 중복되는 정보를 담은 비트를 추가적으로 전송하여, 일부 손실된 데이터를 복구할 수 있다. 하지만 손실률이 10~20% 이상이거나 링크가 매우 혼잡하면 QoS를 더 이상 유지할 수 없다.

End-to-End Delay

VoIP 애플리케이션에게는 종단 간 지연(end-to-end delay)도 매우 중요한 요소이며, 종단 간 지연은 다음의 총 합이다:

• transmission delay
• processing delay
• queueing delay
• propagation delay
• end-system processing delays

이때 VoIP 애플리케이션 기준으로, 150ms 미만의 지연은 사용자에게 감지되지 않으며, 150~400ms의 지연 시간은 받아들일 수 있는 수준의 지연시간이다. 또한 400ms 이상의 지연 시간은 현실적으로 대화가 더 이상 불가능한 수준이다. 이에 따라 수신 측은 보통 400ms 초과된 패킷은 무시하며, 이는 결과적으로 패킷 손실과 유사하다.

Packet Jitter

Packet jitter란 패킷 간 도착 간격의 불규칙성을 의미한다. 예를 들어 송신자는 20ms 간격으로 패킷 전송을 하지만, 수신 시점의 간격은 20ms보다 크거나 작을 수 있다는 것이다. 예를 들어 첫 패킷이 라우터의 거의 빈 큐에 도착하고, 두 번째 패킷은 도착 후 다른 패킷들과 겹친다면, 두 패킷은 20ms 간격으로 전송됐지만, 실제 수신 간격은 20ms보다 더 길어진다. 이 경우 오디오가 끊기거나 느려진 느낌을 줄 수 있다.
반대로 첫 번째 패킷은 라우터의 큐 뒤쪽에 도착해서 오래 기다리고, 두 번째 패킷은 거의 곧바로 뒤따라 도착해서 바로 처리된다면 실제 수신 간격은 20ms보다 짧아진다. 이 경우 음성이 너무 빨리 나와 들리기도 전에 다음 소리가 덮을 수 있다. 따라서 jitter를 완화하는 것이 QoS를 위해서 필요하다.

Removing Jitter at the Receiver for Audio

VoIP 애플리케이션에서는 패킷이 주기적으로 생성되기 때문에, 수신자는 랜덤한 네트워크 jitter가 존재하더라도, 음성 청크의 주기적인 재생(playout)을 제공해야 한다. 이는 일반적으로 아래의 두가지 메커니즘을 결합하여 수행한다:

1. 각 chunk에 타임스탬프를 추가한다.
   • 송신자는 각 chunk에 그것이 생성된 시점의 시간 정보(timestamp)를 붙인다.
2. 수신 측에서 재생을 지연시킨다.
   • Streaming Stored Video 문서에서 논의한 것처럼, 수신된 오디오 chunk의 재생 지연(playout delay)은, 대부분의 패킷이 예정된 재생 시점 전에 도착할 수 있도록 충분히 길어야 한다.
   • 이 재생 지연은 세션 내내 고정된 값일 수도 있고, 세션 동안 adaptive하게 변화할 수도 있다.

이러한 메커니즘을 조합하여, jitter의 영향을 완화하거나 제거할 수 있다.

Fixed Playout Delay

Figure 1. Packet loss for different fixed playout delays

이 전략에서는 수신자가 각 청크를 생성 시점에서 정확히 q 밀리초 후에 재생하려고 시도한다. 예를 들어, 송신자가 어떤 청크를 시간 t에 timestamp했다면, 수신자는 그 청크를 시점 t + q에 재생한다. 하지만 청크가 예정된 재생 시점 이후에 도착하였다면, 해당 청크를 담은 패킷은 버려지며 손실로 간주된다.

이때 q 값을 설정해야 한다. VoIP는 약 400ms까지의 지연은 허용 가능하지만, 하지만, 더 작은 q 값을 사용할수록 대화 품질이 향상된다. 하지만 단, q를 너무 작게 하면 jitter 때문에 많은 패킷이 제시간에 도착하지 못한다. 따라서 종단 간 지연의 변화 폭이 큰 경우에는 q는 크게 설정하는 것이 좋고, 지연 시간과 jitter가 모두 작은 경우에는 q를 작게 설정하는 것이 좋다. Figure 1은 재생 지연과 패킷 손실 간의 trade-off를 보여준다. 송신자는 20ms 간격으로 패킷을 전송하며, 첫 패킷은 r에 도착하고 이후의 패킷은 jitter에 의해 고르지 않게 도착한다. 첫 번째 스케쥴에서는 초기 재생 지연이 p - r인데, 이는 4번째 패킷이 제시간에 도착하지 않아 손실이 일어난다. 하지만 두 번째 스케쥴에서는 초기 재생 지연이 p' - r에 해당하고, 모든 패킷이 제시간에 도착하여 손실이 일어나지 않는 것을 볼 수 있다.

Adaptive Playout Delay

Fixed Playout Delay에서는 지연 시간과 패킷 손실 간의 trade-off 관계가 나타난다. 하지만 이상적으로는, 패킷의 손실률이 임계치 이하로 유지되면서도 지연 시간은 최소화하고자 한다. 따라서 이를 위해서는 네트워크 딜레이와 딜레이의 분산(variability)를 측정하고 발화 구간(talk spurt)의 시작마다 재생 지연을 조정하는 것이 좋다.

따라서 중요한 것은 재생 지연을 계산하는 알고리즘이다. 이를 위해서 다음과 같은 정의를 사용한다:

• t_i: i번째 패킷의 타임스탬프(생성 시각)
• r_i: i번째 패킷이 수신자에게 도착한 시간
• p_i: i번째 패킷의 재생 시각
• r_i − t_i: i번째 패킷의 종단 간 지연(지터 때문에 값이 패킷마다 다름)

위의 정의를 바탕으로 평균 지연의 추정치인 di를 계산하면 아래와 같다:

di = (1 − u)·di-1 + u·(ri − ti)

u는 smoothing 계수이며, 해당 계수를 통해서 최근 딜레이 시간에 더 많은 가중치를 부여한다. 이를 통해 딜레이 분산(편차)의 추정치인 v_i를 아래와 같이 계산한다:

vi = (1 − u)·vi-1 + u·|ri − ti − di|

이는 실제 딜레이 시간이 평균적인 딜레이 시간과 얼마나 차이나는지를 측정하기 위해서 사용된다. 이를 통해서 첫 번째 패킷의 재생 시각 p_i를 계산하면 아래와 같다:

pi = ti + di + K·vi (K는 상수)

위에서 K·v_i는 미래 시점으로 재생을 늦추는 역할을 하며, 이를 통해 지연된 패킷 중 대부분이 제시간에 도착하게 한다. 같은 talk spurt 내의 다음 패킷 j의 재생 시각 p_j는 아래와 같이 계산된다:

qi = pi − ti  (첫 패킷이 생성된 후 재생될 때까지 걸린 시간)
pj = tj + qi

Recovering from Packet Loss

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

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

FEC(Forward Error Correction)

Figure 2. Piggybacking lower-quality redundant information

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

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

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

Interleaving

Figure 3. Sending interleaved audio

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

Chunk	스트림 단위 번호
1	1, 5, 9, 13
2	2, 6, 10, 14
3	3, 7, 11, 15
4	4, 8, 12, 16

위와 같이 청크를 구성하면 하나의 패킷이 손실되어도 하나의 큰 공백이 아니라, 여러 개의 작은 공백이 발생하므로 청감상의 QoS가 개선된다. 이는 대역폭 증가가 없으므로 낮은 오버헤드를 지닌다는 장점이 있지만, 재생 지연(latency)이 증가한다는 단점이 있다.

Error Concealment

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

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

Case Study: VoIP with Skype

스카이프(Skype)는 한 시대를 풍미했던 VoIP 애플리케이션이다. 그런 스카이프를 구현한 Skype 프로코콜은 독점적(proprietary)이며, 모든 제어/미디어 패킷이 암호화(encryted)되어 있어 해당 프로토콜의 작동 방식을 정확히 아는 것은 매우 어렵다. 하지만 그럼에도 여러 노력과 역공학을 통해서 Skype 프로토콜의 대략적인 원리는 밝혀졌고, 아래에 그 대략적인 작동 방식을 소개한다.

음성과 비디오 모두에 대해, Skype 클라이언트는 다양한 코덱을 사용할 수 있으며, 이 코덱들은 여러 가지 전송률과 품질로 미디어를 인코딩할 수 있다. 예를 들어, Skype의 비디오는 낮은 품질 세션에서는 30kbps까지, 높은 품질 세션에서는 거의 1Mbps까지 측정된 바 있다. 이에 따라 일반적으로 Skype의 오디오 품질은 유선 전화 시스템(POTS)보다 더욱 우수하다.

기본적으로 Skype는 오디오 및 비디오 패킷을 UDP로 전송한다. 그러나 제어 패킷은 TCP를 통해 전송되며, 방화벽이 UDP 스트림을 차단할 경우 미디어 패킷도 TCP를 통해 전송된다. Skype는 UDP로 전송되는 음성 및 비디오 스트림에 대해 FEC(Forward Error Correction)을 사용하여 손실을 복구한다. 또한 Skype 클라이언트는 네트워크 상태에 따라 오디오 및 비디오 스트림의 품질과 FEC 오버헤드를 조정한다.

Skype는 P2P 기술을 여러 창의적인 방식으로 활용하는데, 이는 P2P가 콘텐츠 배포나 파일 공유를 넘어서 어떻게 응용될 수 있는지를 잘 보여준다. 카카오톡과 같은 인스턴트 메시징과 마찬가지로, 호스트 간 인터넷 전화는 본질적으로 P2P이다. 왜냐하면 애플리케이션의 핵심에서, 사용자 쌍(즉, peer들)이 서로 실시간으로 통신하기 때문이다. 하지만 Skype는 사용자 위치 탐색과 NAT traversal이라는 두 가지 중요한 기능에서도 P2P 기술을 사용한다.

Figure 4에 나타난 것과 같이, Skype 내의 peer(호스트)들은 계층적인 오버레이 네트워크

Figure 4. Skype overay network

를 구성하며, 각 피어는 SP(super peer) 또는 SC(Skype Client)로 분류된다. Skype는 Skype 사용자 이름을 현재의 IP 주소(및 포트 번호)에 매핑하는 인덱스를 관리하는데, 이 인덱스는 슈퍼 피어들 사이에 분산되어 있다. 예를 들어 준영이 승빈에게 전화를 걸고자 할때, 준영의 Skype 클라이언트는 분산되어 있는 인덱스를 검색하여 승빈의 현재 IP 주소를 알아내는 방식이다. 또한 사용자의 로그인 인증을 담당하는 로그인 서버가 존재하며, 이는 Skype 프로토콜에서 유일하게 중앙화된 요소이다.

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

준영이의 입장에서 Skype 프로토콜을 이용한 통화는 아래와 같이 진행된다:

1. 준영이는 SN에 접속하여, TCP를 통해 Skype 네트워크에 접근한다.
2. 준영이는 중앙의 Skype Login Server에 로그인 요청을 한다.
3. 로그인이 완료되면 SN을 통해 승빈이의 IP 주소를 알아낸다.
4. IP 주소를 알게 되면, 통화 대상자와 직접 P2P 연결을 만든다. 이후 음성 데이터는 중앙 서버를 거치지 않고 바로 통신된다.

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)

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만큼 사용 가능하다. 이러한 구조는 figure 5에 잘 나타나 있다.

SIP

SIP(Session Initiation Protocol)은 아래와 같은 장기적인 목표를 가지는 applicaiton layer의 프로토콜이다:

• 모든 음성, 영상의 통신이 IP(인터넷) 기반으로 이루어진다.
• 사람들은 전화번호 대신, 이메일 주소 또는 사용자 ID(예: alice@example.com) 같은 사람 중심의 식별자를 통해 구분된다.
• 피통화자가 노트북, 스마트폰, 태블릿 등 어떤 기기를 쓰든 상관없이, 그리고 지금 어디 있든지 간에, 그 사람에게 전화나 메시지를 연결할 수 있다.

이러한 목표를 가지는 SIP은 아래와 같은 기능을 제공한다:

• IP 네트워크 상에서 발신자와 수신자 간의 통화 설정 메커니즘을 제공한다.
  • 발신자가 통화를 시작하고 싶다는 것을 수신자에게 알릴 수 있다.
  • 참가자들은 미디어 인코딩에 합의할 수 있고, 통화를 종료할 수도 있다.
• 발신자는 수신자의 현재 IP 주소를 알아낼 수 있는 메커니즘을 제공한다.
  • 이때 사용자는 고정된 IP 주소를 갖지 않는다. 이는 DHCP로 동적으로 할당될 수 있고, 각기 다른 IP 주소를 갖는 여러 장치를 동시에 사용할 수도 있기 때문이다.
• 통화 중에 새로운 미디어 스트림 추가, 인코딩 변경, 새 참가자 초대, 통화 전환, 통화 보류 등 통화 관리 기능도 제공한다.

Name translation, user location

발신자는 피통화자에게 전화를 걸고 싶지만, 일반적으로 발신자는 피통화자의 이름이나 이메일 주소만 알고 있다. 따라서 발신자는 피통화자가 현재 사용 중인 호스트의 IP 주소를 얻어야 하는데, 이는 사용자가 이동하며 DHCP 프로토콜에 따라 유동적인 IP 주소를 가지거나, 여러 디바이스를 소유하고 있기 때문이다. 이때 연결해주어야 하는 IP 주소는 아래와 같이 상황에 따라 다를 수 있다:

기준	설명
시간대	회사에서만 통화 허용, 집에서는 차단
발신자	상사는 집에선 못 걸게 하고, 친구는 되게 할 수 있음
통화 상태	피통화자가 이미 누군가랑 통화 중이면 음성사서함(Voicemail)으로 보냄

SIP Proxy

SIP 서버의 또 다른 기능은 프록시(Proxy)이다. SIP Proxy는 SIP 기반 통화를 할 때, 발신자와 수신자 사이의 중개자 역할을 하며, 단순히 메시지를 중간에서 전달(relay)하는 역할을 한다. 아래와 같은 예시를 통해 대략적으로 알아보자:

1. 예를 들어 준영이가 승빈이에게 전화를 걸고 싶다. 준영이는 승빈이의 SIP 주소(예: sb0415@example.com)을 가지고 있다.
2. 준영이는 자신의 프록시 서버에게 초대 메시지(invite)를 보내며, 해당 메시지는 승빈이를 목적지로 하는 SIP 요청 메시지이다.
3. 프록시 서버는 이 메시지를 승빈이에게 전달해준다.
4. 승빈이는 이 메시지를 받아보고, 응답 메시지를 보낸다. 응답도 같은 경로를 거꾸로 밟는다.
5. 이 응답에는 승빈이의 IP 주소가 포함되어 있어서, 준영이는 승빈이와 직접 음성/영상 데이터 연결을 할 수 있게 된다.

Comparison with H.323

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