제임스딘딘의
Tech & Life

수행 프로젝트 이력/참여자주도형 정보공유 시스템 [2011.12~2012.02]

자료조사(8) - RTP (real Time Procotol)

제임스-딘딘 2011. 11. 27. 20:05

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 패킷헤더 필드
 


-부하타입, 순서번호, 타임스탬프, 근원지식별자 필드가 있다.
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 세션에 속하게 된다.