[2기 부산 최은진] RTP(Real-time Transport Protocol)의 이해

안녕하세요. 부산 삼성소프트웨어 멤버십 21-2기로 활동 중인 최은진 입니다. 제가 이번에 설명드릴 것은 Internet 프로토콜 중 하나인 RTP(Real-time Transport Protocol)에 관한 내용입니다. 실시간으로 비디오나 오디오 스트리밍을 하기 위해서는 RTP, RTCP, RTSP, SDP 등 다양한 프로토콜이 적용됩니다. 저는 이 프로토콜 중 실시간 미디어 데이터 전달을 위한 프로토콜인 RTP에 대해서 설명 드리겠습니다.

RTP(Real-time Transport Protocol)는 주로 인터넷을 통해 실시간으로 비디오 또는 오디오 데이터를 전송하기 위해서 사용하는 프로토콜입니다. MP3나 H.264과 같은 표준화된 미디어 포맷이나 표준화 되지 않은 미디어 포맷 등 다양한 종류의 미디어 형식을 전달하는 데 사용할 수 있습니다. RTP는 패킷에 순서번호와 타임스탬프, 미디어 포맷 등 각종 정보를 포함하는 헤더를 가지고 있으며, 이를 이용해 응용계층의 어플리케이션은 전송받은 미디어 파일을 재생합니다. RTP는 유니캐스트 및 멀티캐스트방식의 전송이 가능합니다. 이 프로토콜을 이용해 실시간 영상 스트리밍 서비스나, 다자간 영상/음성 회의 등을 할 수 있습니다. 

RTP는 QoS를 유지하거나 세션 관리 및 미디어 동기화를 가능하도록 하는 RTCP(Real-time Transport Control Protocol) 프로토콜과 함께 사용합니다. 또한 이 프로토콜을 위한 특정 포트번호가 지정되어 있지 않습니다. 일반적으로 RTP는 짝수 번 포트를, RTCP는 그 다음 홀수 번 포트를 사용합니다.

RTP는 트랜스포트 계층의 UDP(User Datagram Protocol) 상에서 수행됩니다. 프로토콜 스택 구조는 아래 그림과 같습니다.

미디어 파일을 보내는 송신측은 각종 코덱으로 압축된 미디어 단위 데이터를 RTP 패킷으로 만든 뒤 UDP를 이용해 수신측으로 보냅니다. UDP를 이용해 전송되기 때문에 RTP는 특정 시간 내 패킷이 전달되는 것이나 패킷이 손실되지 않는 것을 보장하지는 못합니다. 이 때문에 Video/Audio 어플리케이션에서 RTP 패킷의 헤더에 포함된 각종 정보들을 이용해 적절하게 처리해 주어야 합니다. RTCP를 사용해 RTP의 QoS를 유지하고 미디어 스트림이 동기화 되도록 할 수 있습니다.

RTP 패킷 헤더의 구조는 다음과 같습니다.

RTP 헤더는 헤더의 처음부터 SSRC 부분까지 최소 12Byte 크기의 고정 헤더를 가지며, 선택사항인 확장 헤더도 존재합니다. 이 RTP 헤더 뒤에 RTP 페이로드가 따라오게 됩니다. 

RTP 헤더의 각 부분들의 설명은 다음과 같습니다.

• V(Version) : 2 bits. 프로토콜의 버전을 나타낸다. 현재 버전은 2이다.

• P(Padding) : 1 bit. 패딩 바이트가 있는지를 나타낸다. 이 필드가 세트되면 RTP 패킷의 끝에 패딩바이트들이 포함되어 있다. 이 패딩 바이트들은 암호화 알고리즘에 사용하거나 패킷 길이를 맞추는 데 사용된다.

• X(Extension) : 1bit. 고정 헤더와 페이로드 사이에 확장 헤더가 있는지를 나타낸다.

• CC(CSRC Count) : 4bits. 고정 헤더 뒤에 CSRC identifier가 몇 개 포함되어 있는지를 나타낸다.

• M(Marker) : 1bit. 프로파일에 의해서 정의되어 있으며, 페이로드 타입에 따라 사용 방법이 정해져있다. 미디어의 프레임 경계등과 같은 것을 표시하기 위해 사용한다.

• PT(Payload Type) : 7bits. 페이로드의 형식을 나타낸다. 오디오나 비디오의 인코딩 타입을 나타낼 수 있다.

• Sequence Number : 16bits. 패킷의 순서 번호를 나타낸다. 전송되는 RTP 패킷마다 1씩 증가하며 수신측이 이 필드를 통해 패킷 손실을 감지할 수 있고 패킷 순서를 복원할 수 있다. 이 작업은 어플리케이션 계층에서 이루어진다. Sequence Number의 초기 값은 무작위로 설정되어야 한다.

• Timestamp : 32bits. RTP 데이터 패킷의 첫 번째 바이트의 샘플링 시점을 나타낸다. 수신자가 이 필드를 이용해 수신된 미디어의 동기적인 재생이 가능하게 할 수 있다. Timestamp는 송신자의 미디어 샘플링 클럭에서 생성된다. 이 필드의 단위는 페이로드 타입에 따라 달라지며, 어플리케이션을 위한 RTP 프로파일에 의해 지정되어 있다. 이 필드의 초기 값 또한 무작위로 설정된다.

• SSRC(Synchronization Source) : 32bits. RTP 스트림의 소스를 식별한다. 하나의 RTP 세션 내에서 이 필드 값들은 고유한 값을 갖는다. 이 필드의 값은 무작위로 설정된다.

• CSRC(Contributing Source) list : 각각 32bits씩 0~15개. 이 패킷에 포함 된 미디어를 구성한 소스들을 식별한다. Mixer를 통해 합쳐진 원 소스의 SSRC identifier들이 나열되어 있다.

• Extension header : 선택사항. 어플리케이션이 지정한 임의의 정보들을 나타낸다.
  

페이로드 타입, 순서 번호, 타임스탬프, SSRC는 RTP 헤더에서 중요한 역할을 합니다. 이 네 필드에 대해서 자세하게 설명해 보겠습니다. 

페이로드 타입(PT)은 RTP 패킷이 전송하고 있는 미디어의 종류를 나타냅니다. RTP 페이로드에 실린 데이터가 어떤 데이터인지, 오디오인지, 비디오인지, 인코딩 타입이 무엇인지 어플리케이션은 이 필드를 통해 알 수 있습니다. RTP는 정말 다양한 종류의 페이로드 타입을 지원하며 몇몇 표준화된 미디어 포맷의 경우 RFC 문서를 통해 해당 미디어의 RTP 전송을 위한 페이로드 포맷이 정의되어 있습니다. 송신자는 전송 중에 이 필드의 값을 변경시켜 미디어 전송률이 좋은 포맷으로 바꾸거나 좀 더 좋은 화질을 가지는 포맷으로 바뀌었다는 것을 수신측에 알려 줄 수 있습니다. 수신측은 페이로드 타입을 이해할 수 없을 경우 무시하도록 해야 합니다. 각종 오디오와 비디오 인코딩을 위한 RTP 페이로드 타입은 RFC 3551에 정의되어 있습니다. 페이로드 타입은 미리 지정된 127개의 미디어 타입으로 정해져 있으며 그 종류는 아래 표와 같습니다. 정해진 미디어 타입 이외에 다른 타입을 사용하고 싶다면 페이로드 타입을 96-127 사이의 dynamic payload type로 설정하여 사용해야 합니다.

순서 번호(Sequence Number)는 RTP 패킷의 순서를 나타냅니다. UDP를 통해 전송된 패킷이 순서대로 도착하지 않더라도 수신측은 이 필드의 값을 이용해 순서를 정렬하거나, 손실된 패킷이 있을 경우에 패킷을 복구하거나 재전송을 요청하는 등의 작업을 할 수 있습니다. 실시간 서비스에서는 재전송 요청보다는 패킷을 복구하는 방법을 사용해야 할 것입니다. 순서 번호는 패킷 당 1씩 순차적으로 증가합니다.

타임스탬프(Timestamp)는 이 패킷이 샘플링 된 시점을 나타냅니다. 이 필드의 값으로 이 패킷의 페이로드 데이터가 재생되어야 하는 타이밍을 알 수 있습니다. 샘플링 클럭에 따라 이 필드 값의 증가 폭이 정해지며 이 클럭 주파수 값은 페이로드 타입에 따라 지정되어 있으며 이는 RFC 3551(링크)에서 확인할 수 있습니다. 예를 들어서 8000Hz로 샘플링 되고 있는 미디어가 있다고 합시다. 즉 초당 8000개의 샘플이 샘플링 되고 있으며, 샘플 하나당 125μs가 걸립니다. 이 샘플 하나당 타임스탬프 값이 1씩 증가하게 됩니다. 한 패킷의 페이로드를 구성하는 샘플이 160개가 있다면 타임스탬프는 패킷마다 160씩 증가하게 될 것입니다. 대용량 미디어인 비디오의 경우에는 연속된 패킷들이 같은 타임스탬프 값을 가질 수 있는데 이는 같은 타임스탬프 값을 가지는 패킷들의 페이로드가 하나의 프레임을 구성하는 경우일 것입니다. 또한 이 필드의 값은 패킷이 전달되지 않더라도 실제 시간에 맞추어 지속적으로 증가합니다.

SSRC(Synchronization Source)는 수신되는 각각의 미디어 스트림 소스를 구별할 수 있도록 합니다. 하나의 세션에서 여러 개의 미디어가 동시에 스트림 될 수 있으며 이들을 구분하기 위해 이 필드의 값을 사용합니다. 예를 들어 비디오와 오디오를 동시에 RTP를 통해 전송받고 있다고 했을 때 어플리케이션이 두 미디어를 구분하기 위해서 SSRC가 필요합니다. 이 때문에 한 세션에서는 미디어 소스마다 서로 다른 SSRC값을 가져야 합니다.

 

실시간 음성 대화 어플리케이션이 있다고 가정하고 RTP 패킷 사용 예를 들어보도록 하겠습니다. 보통의 실시간 음성 대화 어플리케이션의 경우 약 20ms간격으로 음성 데이터를 모아 패킷으로 만든다고 합니다. 음성 데이터의 페이로드 타입에 따른 클럭 주파수 값이 8000Hz라고 했을 때 한 패킷은 20ms당 160개의 샘플이 포함되어 있을 것입니다. 이 경우에 타임스탬프는 160씩 증가합니다.

이 패킷들을 만들어진 순서대로 수신자에게 전달하면 이상적인 네트워크 환경에서는 수신자는 20ms 마다 수신되는 패킷을 즉시 재생하면 될 것입니다. 하지만 실제 네트워크에서는 패킷 손실이나 패킷 간 지연시간(패킷 지터)이 생기게 됩니다. 이 때문에 순서번호와 타임스탬프가 필요하며 이를 이용해 음성 재생을 동기화 시킬 수 있습니다.

먼저 패킷 손실에 대해서 설명하겠습니다. UDP상에서 패킷 전달이 이루어지게 되면 패킷 손실이 발생할 수 있습니다. UDP 데이터그램이 네트워크 라우터들을 지나갈 때 이 라우터의 버퍼에 쌓인 뒤 처리가 됩니다. 이 때 이 버퍼가 가득 차있다면 데이터그램을 받아들일 수 없으므로 해당 데이터그램은 폐기됩니다. TCP의 경우에는 재전송을 요청하여 패킷 손실을 막지만 UDP는 그러한 작업을 하지 않기 때문에 패킷의 손실이 발생하게 되는 것입니다. RTP의 순서 번호를 확인하여 패킷이 손실되었는지를 알 수 있습니다.

손실된 것을 확인하면 수신측은 손실된 패킷을 복구하는 등의 작업을 할 수 있습니다.

다음으로 패킷 지터에 대해서 설명하겠습니다. 중, 고등학교 때 수학여행을 가면 버스 여러 대가 동시에 출발하지만 가는 도중에 신호에 걸려 앞차와 뒤차와의 간격이 점점 달라져서 도착할 때는 도착 시간이 서로 다른 것을 많이 봐왔을 것입니다. 이런 상황과 비슷하게 수신측이 패킷을 생성하여 패킷을 연속으로 보낸다 하더라도 수신측에서는 수신되는 패킷들 사이에 네트워크상의 큐잉 지연과 같은 지연들로 인해서 수신될 때까지의 시간이 패킷마다 달라질 수 있습니다. 이런 현상을 지터(jitter)라고 합니다. 미디어를 재생할 때는 이 패킷 지터를 고려해야 합니다.

다시 처음의 예로 돌아가 설명하겠습니다. 수신측은 패킷 지터와 패킷 손실을 고려하여 음성을 재생해야 합니다. 따라서 패킷 손실이 일어나 패킷이 도착하지 않더라도 해당 기다리지 않고 패킷 복구를 시도하거나, 다음 패킷이 도착하면 재생해야 하며 특정 지연시간 내에 도착하지 않는 패킷은 무시해 실시간 음성 재생이 가능하도록 해야 합니다.

송신측에서 타임스탬프가 100인 패킷을 만들어서 전송했을 때 타임스탬프가 의미하는 것은 이 패킷의 페이로드 첫 부분이 샘플링 된 시점이 100이라는 것이고 수신측에서 재생되어야 하는 시점 또한 100이어야 합니다. 하지만 네트워크 지연 및 패킷 지터로 인해 패킷이 도착하기를 기다려야 할 수 있습니다. 이 때문에 실제 재생되는 시점은 100보다 조금 늦춰질 수 있습니다. 하지만 기다리는 시간이 너무 길다고 생각되면 실시간성을 위해 해당 패킷을 손실된 것으로 간주하고 다음 패킷을 기다려야 합니다. RTP 패킷의 타임스탬프와 실제 패킷 도착 시간을 이용해 패킷의 지연 시간을 알 수 있고 이 값을 이용해 패킷을 기다려야 하는 적당한 시간(α)을 정할 수 있을 것입니다.

 

이상으로 RTP에 대해 알아보았습니다. RTP를 사용하여도 실제 실시간 스트리밍 서비스가 가능하도록 하려면 응용계층의 어플리케이션에서 인코딩 및 디코딩, 미디어 동기화, 패킷 손실 복구 처리와 같은 것을 직접 구현해 주어야 합니다. 더 자세한 내용은 RTP의 RFC문서(RFC 3550)를 참조하시기 바랍니다.

---

• 참고 문헌

컴퓨터 네트워킹 –하향식 접근-, James F. Kurose, Keith W. Ross

RTP: A Transport Protocol for Real-Time Applications, http://www.ietf.org/rfc/rfc3550.txt

RTP Profile for Audio and Video Conferences with Minimal Control, http://www.ietf.org/rfc/rfc3551.txt

Real-time Transport Protocol, Wikipedia, http://en.wikipedia.org/wiki/Real-time_Transport_Protocol

Real-Time Transport Protocol (RTP) Parameters, http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml