RTP(Real Time Protocol) RTCP(RTP Control Protocol) 개요

   지연에 대한 제약이 거의 없거나 아주 없는 기존의 네트웍 응용 서비스들(FTP, Email, etc.)을 위해서는 TCP와 같은 안전한 방법의 전송 프로토콜이 적당하였으나 실시간 멀티미디어 네트웍 응용서비스들이 등장하기 시작하면서 TCP의 지연 유발 정책(재전송 기법, 네트웍 폭주 시 "Slow Start")은 심각한 문제점으로 대두되며 이것은 지연이 오디오나 비디오 같은 실시간 매체들의 적시 재생(On Time Playback)을 불가능하게 하기 때문이다. 이러한 이유로 많은 실시간 응용 서비스들이 TCP 보다는 비교적 지연의 가능성이 적은 UDP를 이용해 왔다. 그러나 UDP의 경우에도 패킷의 분실, 전송 순서 위반과 같은 매체의 품질에 크게 영향을 미치는 문제점들을 가지고 있다.

 

   실시간 응용 서비스들에 대한 수요가 점차로 늘어나면서 IETF와 같은 단체에서는 TCP/UDP를 대신할 수 있는 실시간 응용들을 위한 전용 프로토콜의 개발을 시작하였고, 그 결과가 RTP/RTCP, RSVP, RSTP와 같은 프로토콜들이다. 인터넷을 통한 실시간 데이터 전송 서비스에 RTP/RTCP는 거의 표준처럼 이용되고 있는 실정이다. 그러나 RTP/RTCP는 TCP의 지연 문제를 피하기 위해 UDP 전송 프로토콜로 이용하고 있기 때문에 패킷의 분실과 같은 전송 품질의 문제는 해결하지 못하고 있으며 또한 UDP를 쓴다고 해서 지연 문제가 완전히 해결되는 것은 아니다. 따라서 실시간 데이터 전송을 위한 채널에는 적시 전송과 패킷 분실 방지가 보장되어야 한다. 이를 위해 제시된 프로토콜이 RSVP이다. RSVP는 수신자-송신자 경로상에 위치하는 모든 노드들이 특정 RTP 연결이 요구하고 있는 QoS가 보장될 수 있을 경우에만 연결 설정을 허가하도록 함으로써 위에 언급된 문제점들을 해결할 수 있다. 그러나 RSVP를 실현하기 위해서는 RTP 연결상의 모든 노드들이 RSVP를 구현하고 있어야 한다는 단점이 있다. 이러한 프로토콜과는 접근 방법이 조금은 다른 RTSP는 일-대-다 또는 일-대-일의 단방향 멀티미디어 전송 프로토콜로 송신 측에서 유용 가능한 대역폭에 알맞은 크기로 멀티미디어 데이터를 자른 후 패킷화하여 전송하는 프로토콜이다. 수신 측에서는 일정량의 패킷이 쌓이면 매체의 재생을 시작한다. 이때 매체의 재생과 동시에 수신 및 디코딩이 이루어지기 때문에 수신 측에서는 전체 매체 파일을 받아보지 않고도 연결과 거의 동시에 매체를 재생할 수 있게 된다.

 

 

 

RTP (Real Time Protocol)

>> RFC 3550

 

☛ 개요

   RTP는 오디오, 비디오 및 시뮬레이션 데이터와 같은 실시간 데이터를 멀티캐스트 또는 유니캐스트 네트웍을 이용해서 전송하는 응용 서비스에 알맞은 단말-대-단말 네트웍 전송 기능을 제공한다.  RTP는 자원 예약을 수행하지 않으며, 따라서 적시 전달, 순차 전달과 같은 서비스 품질도 보장하지 않는다. RTP 데이터 전송 기능은 제어 프로토콜에 의해 확장되는데, RTCP라 불리우는 이 제어 프로토콜은 데이터의 전달 상황을 감시하며, 최소한의 제어 기능과 매체 식별 기능을 제공한다. RTP와 RTCP는 하위의 전송 및 네트웍 계층에 무관하게 설계되었다.

   RTP는 별개의 독립 계층으로 구현되기 보다는 특정 응용에서 요구되는 정보를 제공하여 프로토콜의 처리가 응용의 처리 과정으로 통합될 수 있도록 설계되었다. 따라서 기존의 프로토콜들과는 달리 RTP는 응용의 필요에 따라 헤더를 변경하거나 추가하여 응용에 맞는 프로토콜이 될 수 있도록 하는 일종의 맞춤형 프로토콜이다. 이 문서에서는 RTP를 이용할 수 있을 것으로 추정되는 모든 응용들이 공통적으로 필요로 할 기능들 만을 명시하고 있다. 따라서, 특정 응용 서비스에 필요한 RTP를 구현하기 위해서는 이 문서 이외에 RTP 페이로드의 종류와 형식을 정의하는 프로파일 문서(Profile Specification)와 페이로드의 전송 방법을 정의한 페이로드 형식 문서(Payload Format Specification)가 필요하다. 

☛ 특징

- UDP상에서 실행

  UDP는 TCP에 비해 신뢰성이 낮은 반면, 더 빠르게 데이터를 전달함. 이러한 UDP의 특성을 이용하여 RTP가 등장하였다. 그래서, RTP는 그 자체로 QoS 보장이나 신뢰성을 제공하지 못한다.(RTCP를 통해 QoS를 보장)

- 송신자는 데이터 단위를 RTP 패킷으로 캡슐화한 후 그 패킷을 UDP 세그먼트로 캡슐화해서 IP에게 넘겨준다.

- RTP 세션 다중화

  효과적인 프로토콜 처리를 위해서 다중화 점의 수는 최소화되어져야 한다. RTP의 경우에 다중화는 목적지 전송 주소에 의해 수행된다.. 예를 들어 오디오와 비디오로 이루어지는 회의에서 각 매체는 자신만의 목적지 전송 주소를 가지는 독자의 RTP 세션으로 전송되어야 한다.  

- 수신자는 UDP 세그먼트로부터 RTP 패킷을 추출한 후에 RTP 패킷으로부터 데이터 단위를 추출해서 디코딩 및 렌더링을 위해 미디어 플레이어에게 전달한다.

- RTP는 다른 3계층, 4계층 프로토콜과도 같이 사용이 가능하며,

  하위 프로토콜에 별로 의존하지 않음.

☛ RTP 패킷헤더 필드

  그림 RTP header field

-부하타입, 순서번호, 타임스탬프, 근원지식별자 필드가 있다.

 

1. 페이로드타입필드의 길이는 7비트이다. 오디오 스트림의 경우, 사용되는 오디오 인코딩타입을 타나내기 위해 사용한다. 만일 송신자가 세션 중간에 인코딩을 변경하면, 송신자는 수신자에게 페이로드 타입 필드를 사용해서 이 변경사항을 알려준다. 예컨대, 송신자는 오디오 품질을 향상시키거나 RTP스트림 비트율을 감소시키기 위해 인코딩을 변경하고자 할 수도 있다.

표 RTP에서 제공하는 오디오 페이로드 타입

 

페이로드 타입 번호	오디오 포맷	샘플링 비율	비율
0	PCM μ-law	8 kHz	64 kbps
1	1016	8 kHz	4.8 kbps
3	GSM	8 kHz	13 kbps
7	LPC	8 kHz	2.4 kbps
9	G.722	16 kHz	48-64 kbps
14	MPEG 오디오	90 kHz	-
15	G.728	8 kHz	16 kbps

 

   비디오 스트림의 경우에 페이로드 타입은 비디오 인코딩 타입을 나타내기 위해 사용된다. 이 때도 송신자    는 세션 중에 비디오 인코딩을 변경할 수 있다.

표 RTP에서 제공하는 비디오 페이로드 타입

페이로드 타입 번호	비디오 포맷
26	Motion JPEG
31	H.261
32	MPEG 1 비디오
33	MPEG 2 비디오

 

 

2. 순서번호필드의 길이는 16비트이다. 순서번호는 전송되는 RTP 패킷마다 하나씩 증가하며, 패킷 손실을 감지하고 패킷 순서를 회복하기 위해 수신자가 사용할 수 있다. 예를 들어, 만일 애플리케이션의 수신자가 순서번호 86과 89사이에 공백이 있는 RTP패킷 스트림을 수신하면, 수신자는 패킷 87과 88을 잃어버렸음을 알게 된다. 그러면 수신자는 손실된 데이터를 막기l 위해 시도할 수 있다.

 

3. 타임스탬프 필드의 길이는 32비트 이다. 이 필드는 RTP 데이터 패킷의 첫 번째 바이트의 샘플링 시점을 나타낸다. 수신자는 네트워크에 의해 만들어진 패킷 지터를 제거하고 수신자가 동기적인 재생을 가능하도록 타임스탬프를 사용할 수도 있다. 타임스탬프는 송신자 샘플링 클록으로부터 생성된다. 예를 들어, 오디오의 경우에는 타임스탬프의 클록은 각 샘플링 주기마다 하나 증가한다. 만일 오디오 애플리케이션이 160개의 인코딩된 샘플로 구성된 chunk를 생성한다면, 근원지가 활성일 때 타임스탬프는 각 RTP 세션마다 160씩 증가한다. 타임스탬프 클록은 근원지가 비활성일 때 조차도 일정 비율로 계속 증가한다.

그림 RTP layer

 

4. 동기근원지 식별자(SSRC): SSRC 필드의 길이는 32비트 이다. 이 필드는 RTP 스트림의 근원지를 식별한다, 대개, RTP 세션의 각 스트림은 상이한 SSRC를 갖는다. SSRC는 송신자의 IP 주소 대신에 새로운 스트림이 시작될 때 근원지에서 임의 할당한 숫자이다. 두 스트림이 동일한 SSRC를 할당받을 확률은 매우 작다. 만일 이런 일이 발생하면 두 근원지는 새로운 SSRC 값을 선택한다.

  

 

☛ RTP로 소프트웨어 애플리케이션 개발방법

 

1. 애플리케이션 개발자가 RTP 캡슐화를 수행하는 송신자의 코드와 RTP 패킷을 풀어보는 수신자의 코드를 직접 작성해서 RTP를 추가하는 것.

 

2. 캡슐화 및 역캡슐화를 수해앟는 기존 RTP 라이브러리와 자바 클래스들을 애플리케이션 개발자가 사용하는 것이다.

  

   예를들어, 음성을 전달하기 위해 RTP를 사용하는 것에 대해 생각해보자. 음성 데이터는 64kpbs의 PCM으로 인코딩된다고 가정하자. 또한 애플리케이션이 인코딩된 데이터를 20밀리초의 데이터 단위(즉, 한 데이터 단위에 160바이트)로 모은다고 가정하자. 송신자는 오디오 데이터의 각 데이터 단위 앞에 오디오 인코딩 종류, 순서번호, 타임스탬프 등을 가진 RTP 헤더를 덧붙인다. RTP 헤더는 보통 12바이트이다. 오디오 데이터 단위에 RTP 헤더를 덧붙여서 RTP 패킷을 구성한 후, UDP 소켓 인터페이스로 전송한다. 수신자의 애플리케이션은 소켓 인터페이스에서 RTP 패킷을 수신한 후, RTP 패킷에서 오디오 데이터 단위를 추출하고, 추출된 RTP 패킷의 헤더 필드를 살핀 후에 오디오 데이터 단위를 적절히 디코드 및 재생한다.

   페이로드 타입이나 순서번호, 타임스탬프를 제공하는 개인 기법 대신에, 애플리케이션이 RTP를 사용하면 훨씬 쉽게 다른 네트워킹 멀티미디어 애플리케이션을 통합할 수 있다. 예를 들어. 만일 두 회사에서 인터넷 폰 애플리케이션을 개발할 때 RTP를 사용한다면, 한 회사의 인터넷 폰 제품을 사용하는 사용자가 다른 회사의 인터넷 폰 제품을 사용하는 사용자와 통신 가능할 거라고 기대할 수 있다.

   RTP 자체가 시간에 맞춘 데이터 전달을 보장하거나 다른 서비스 품질 보장을 제공하는 기법을 지원하지 않는다는 것이다. 즉, RTP는 패킷 전달을 보장하거나 패킷 전달 순서를 보장하지 않는다. 실제로 RTP 캡슐화는 종단 시스템에서만 된다. 라우터는 RTP 패킷을 전달하는 IP 데이터그램과 RTP 패킷을 전달하지 않는 IP 데이터 그램을 구분하지 않는다.

   RTP는 각각의 근원지(예:마이크로폰, 카메라)에게 자신만의 RTP 패킷 스트림을 생성할 수 있도록 허용한다. 예를 들어, 두명의 참여자가 있는 화상회의의 경우, 두 개의 오디오 송신용 스트림(각 방향으로 하나의 스트림)과 두 개의 비디오 송신용 스트림(각 방향으로 하나의 스트림)등 총 네 개의 RTP 스트림이 만들어질 수 있다. 그러나 MPEG1이나 MPEG2 같은 대다수 많이 사용되는 인코딩 기법은 인코딩 과정에서 오디오와 비디오를 하나의 단일 스트림으로 합친다. 인코더에서 오디오와 비디오를 합치면 각 방향으로 하나의 스트림만 생성된다.

   RTP 패킷은 유니캐스트 애플리케이션에 한정되지 않는다. RTP 패킷은 일대다 EH는 다대다 멀티캐스트 트리로 전송될 수도 있다. 다대다 멀티캐스트 세션에 대해, 세션의 모든 송신자와 근원지는 RTP 스트림을 전송하는 데 있어서 일반적으로 동일한 멀티캐스트 그룹을 사용한다. 화상회의 애플리케이션에서 다수의 송신자들에 의해 전송되는 오디오, 비디오 스트림과 같이 함께 포함된 RTP 멀티캐스트 스트림들은 하나의 RTP 세션에 속하게 된다.

 

 

 

RTCP (RTP Control Protocol)

>> RFC 3550

  

☛ 개요 

- 멀티미디어 네트워킹 애플리케이션에서 RTP와 함께 사용할 수 있는 프로토콜

- RTP세션의 각 참여자는 IP멀티캐스트를 사용해서 세션안의 모든 참여자들에게 RTCP 패킷을 전송한다. 보통 RTP 세션마다 멀티캐스트 주소가 하나씩 사용되며, 세션에 속한 모든 RTP 패킷과 RTCP 패킷들은 이 멀티캐스트 주소를 사용한다. RTP 패킷과 RTCP 패킷들은 다른 포트번호를 사용해서 서로 구분된다.(RTCP 포트번호는 RTP 포트번호에 1을 더한 값으로 설정된다.)

- RTCP 패킷은 오디오나 비디오 청크를 캡슐화 하지 않는다 대신에 RTCP 패킷은 주기적으로 전송되며, 애플리케이션에 의해 유용하게 사용될 수 있는 통계 값을 제공하는 송신자 보고 및/ 또는 수신자 보고를 포함한다. 이 통계 값에는 전송된 패킷 수, 손실된 패킷 수, 도착들 간의 지터를 포함한다. RFC에는 이 피드백 정보를 애플리케이션이 어떻게 해야 하는지에 대해 지정하지 않는다. 이것은 애플리케이션 개발자에게 달려있다.

☛ 기능

RTCP는 RTP와 같이 동작하는 제어 프로토콜로 RTP 세션에 참여한 각 참가자들은 주기적으로 다른 모든 참가자들에게 RTCP 제어 패킷을 전송해야 한다.

1. 응용 서비스에 정보 제공 : RTCP는 주기적인 제어 패킷 전송을 통해서 응용 서비스에 RTP 세션의 데이터 전송에 관계되는 정보를 제공한다. 각 RTCP 제어 패킷은 송신자 또는 수신자의 상태 정보를 포함하고 있으며, 이러한 상태 정보에는 전송 패킷 수, 수신 패킷 수, 지터 등이 포함된다. 

2. RTP 소스 식별 : RTCP는 하나의 RTP 소스에 대해 Canonical Name(CNAME)이라 부르는 전송 계층의 식별자를 가진다. 이 CNAME은 RTP 세션의 참가자들을 추적하는데 이용된다. 

3. RTP 전송 간격 제어 : 제어 트래픽이 네트워크 자원을 너무 많이 이용하지 못하도록 하고 RTP 세션에 많은 참가자들이 참가할 수 있도록 하기 위해서 제어 트래픽은 전체 세션 트래픽의 5%를 초과할 수 없도록 한정된다. 이에 대한 내용은 참가자 수의 함수로 결정된다.

4. 최소한의 세션 제어 정보 수송 : 부가적인 기능으로 RTCP는 모든 세션 참가자들에 대해 최소한의 정보를 수송하기 위한 편리한 방법으로 이용될 수 있다.

☛ RTCP 패킷 타입

세션의 일부로서 수신자가 수신한 RTP 스트림에 대해, 수신자는 수신 보고를 만든다. 수신자는 자신의 수신 보고들을 하나의 RTCP 패킷으로 모은다. 그 뒤 이 패킷은 세션의 모든 참여자가 연결된 멀티캐스트 트리로 전송된다. 수신 보고에는 여러 필드가 포함되는데 이는 다음과 같다.

 

- 수신 보고가 생성되는 RTP 스트림의 SSRC

- RTP 스트림 안에서 손실된 패킷의 비율. 수신자는 손실된 RTP 패킷 수를 전송된 RTP 패킷 수로 나눈다. 만일 송신자가 전송한 패킷의 아주 일부만을 수신자가 수신한다는 거을 나타내는 수신 보고를 받으면, 송신자는 네트워크 혼잡을 줄이고 수신율을 높이기 위해 낮은 인코딩의 비율로 변경할 수 있다.

- RTP 패키 스트림에서 마지막으로 수신된 순서번호

- RTP 스트림 안의 연속 패킷들의 평균 도착 간의 지터

  송신자가 전송하는 RTP 스트림마다 송신자는 RTCP 송신자 보고 패킷을 만들어서 전송한다. 이들 패킷은 RTP 스트림에 관한 정보를 포함하며 이들 정보는 다음과 같다.

- RTP의 스트림의 SSRC

- 스트림에서 가장 최근에 생성된 RTP 패킷의 타임스탬프와 실제 시간

- 스트림에서 전송된 패킷 수

- 스트림에서 전송된 바이트 수

   송신자 보고는 RTP 세션 안의 서로 다른 미디어 스트림들은 동기화 하는 데 사용할 수 있다. 예를 들어, 송신자가 두 개의 독립 RTP 스트림(하나는 비디오용 스트림, 또 다른 하나는 오디오용 스트림)을 생성하는 화상회의 애플리케이션을 생각하자. RTP 패킷의 타임스탬프는 비디오 및 오디오 샘플링 클록과 관련 있으나 실제 시간과는 무관하다. RTCP 송신자 보고에는 관련 스트림에서 가장 최근에 생성된 패킷의 타임스탬프와 이 패킷이 생성된 실제 시간이 포함된다. 따라서 RTCP 송신자 보고 패킷은 샘플링 클록과 실제 클록을 연관시키며, 수신자는 오디오와 비디오 재생을 동기화하는 데 RTCP 송신자 보고의 클록 연관 정보를 사용할 수 있다.

   송신자가 전송하는 RTP 스트림에 대해, 송신자는 근원지 기술 패킷을 만들어서 전송한다. 이 패킷은 송신자의 전자메일 주소, 송신자 이름, RTP 스트림을 생성하는 애플리케이션 등과 같은 근원지에 대한 정보를 포함한다. 또한 이 패킷은 연관된 RTP 스트림의 SSRC를 포함한다. 이 패킷은 근원지 식별자(즉 SSRC)와 사용자/호스트 네임 사이의 매핑을 처리한다.

   RTCP 패킷은 쌓일 수 있다. 즉, 수신자 수신 보고, 송신자 보고, 근원지 기술자들을 패킷 하나에 통하해서 넣을 수 있다. 이렇게 만들어진 패킷은 UDP 세그먼트에 캡슐화되어 멀티캐스트 트리로 전달된다.

 

☛  RTCP대역폭 확장

RPCP는 확장 문제르 가지고 있다. 예를 들어, 하나의 송신자와 다수의 수신자로 구성된 RTP 세션을 생각해 h자. 만일 각 수신자가 주기마다 RTCP 패킷을 생성한다면, RTCP패킷의 총 전송률은 송신자에 의해 전송되는 RTP 패킷의 전송률을 상당히 초과할 수 있다. 멀티캐스트 트리로 전송되는 RTP 트래픽 양은 수신자 수가 증가해도 변하지 않는 반면, RTCP 트래픽 양은 수신자 수에 선행으로 증가한다. 이 같은 확장 문제를 해결하기 위해, RTCP는 세션 내의 참여자 수에 따라 멀티캐스트 트리로 전송할 수 있는 RTCP 패킷의 전송률을 조절한다. 또한, 차여자는 제어 패킷을 다른 모든 참여자에게 전송하므로 각 참여자는 세션 안의 총 차명자 수를 추정할 수 있다. 또한 참여자는 동적으로 평균 RTCP패킷 크기를 계산하고 이 크기를 자신에게 할당된 전송률로 나눔으로써 RTCP 패킷의 전송 주기를 결정한다. 요컨대, 송신자가 RTCP 패킷을 전송하는 주기는 다음과 같다.