[Network기초] 6. RTP

12 Jan 2020

RTP 개요

RTP는 Real-time Transport Protocol의 약어로 실시간 음성, 영상 및 데이터를 IP네 트워크로 전송하는 표준 프로토콜이다
RTP는 IETF RFC 3350 A Transport Ptorocol for Real-Time Application권고안에서 정의
RTP는 RTCP(Real-time Control Protocol)를 이용하여 데이터의 전달 상황을 감시 및 최소한의 제어 기능과 미디어 식별 등을 제공
RTCP의 사용은 옵션

RTP는 전송 프로토콜로 UDP와 네트워크 프로토콜로 IP를 이용한다
- RTP가 신뢰할 수 있는 TCP를 이용하지 않고 UDP를 이용하는 이유는, 실시간 음성 및 영상은 패킷 에러나 손실이 발생하더라도 TCP재전송 메커니즘을 활용할 수 없기 때문이며, TCP보다 UDP가 빠르기 때문
데이터그램의 분실이나 도착순서 변경 등의 오류를 RTP에서 해결하는 구조
포트주소 기능을 이용하여 송수긴 프로세스간의 연결을 관리한다
프로그램 하나를 단위로 하지 않고, 일부 기능이 개별적으로 구현된다
응용 서비스의 종류에 따라 요구 조건이 다른 기능을 추가하는 형식을 취한다
다수의 사용자가 하나의 세션을 사용하여 실시간 데이터 전송이 가능하게 만들어져있다
재전송된 패킷은 수신 단말이 재생해야 할 시점을 이미 지나가 버린 이후가 될 확률이 높아 패킷을 폐기
오버헤드는 40바이트로 IP(20 바이트), UDP(8바이트), RTP(12바이트)이다

릴레이는 데이터전송 과정에서 송수긴 프로세스가 직접 데이터를 전송할 수 없는 상황인 방화벽 사용이나 데이터 형식이 상이한 경우 데이터를 중개하는 기능을 의미한다
RTP가 지원하는 릴레이는 ‘믹서’와 ‘트랜슬레이터’ 두개다
믹서
- 여러 송신 프로세스의 데이터그램을 적절히 조합하여 새로운 데이터그램을 생성한다
- 예) 영상과 음성을 믹싱하여 새로운 동영상을 만드는 것
트랜슬레이터
- 각 입력된 RTP데이터그램을 하나 이상의 출력용 데이터그램으로 만들어주는 것
  - 수신자의 환경에 맞게 바꿔주는 것을 의미

V (version) : 2bit
- RTP의 Version표시 (현재 버전은 2)
P (padding) : 1bit
- 패킷의 마지막 부분에 하나 이상의 패딩 바이트 무 표시
- 패딩 비트는 의미가 없는 비트로 헤더나 패킷의 크기를 일정하게 유지하기 위해서 사용하는 비트
X (Extension) : 1bit
- 고정 헤더 이후의 하나 이상의 확장 헤더 유무 표시
CC (CSRC Count) : 4bit
- RTP 12바이트 고정 헤더 뒤에 CSRC identifier의 수 표시
M (Marker) : 1bit
- 패킷 내에서 프레임 경계와 같은 중요한 이벤트들을 표시
- Payload Type필드의 확장을 위해 무시되기도 함
PT (Payload Type) : 7bit
- 페이로드의 타입은 RTP가 전송하고 있는 실시간 데이터의 압축 코덱을 명시
- 페이로드 타입은 Capability Exchange 협상에서 상호 인지 필수
Sequence number : 16bit
- 보안을 이유로 랜덤 번호에서 시작하고 패킷이 늘어날 때마다 1씩 증가
- 수신 측이 패킷 손실 여부 확인 가능
Timestamp : 32bit
- RTP 패킷의 첫 번째 바이트의 샘플링 순간을 표시
- 초기값은 랜덤 넘버로 결저오디지만 샘플링 레이트에 따라 증가량은 상이
SSRC (Synchronized Source) Idendifier : 32bit
- 동기화 소스로 랜덤 넘버로 결정
CSRC (Contributing Source) Identifiers : 32bit
- 다수의 음원이 Audio Mixer를 통해 하나로 통합될 경우 원래 음원의 목록을 표시

응용층의 프로토콜
Video/Audio “데이터”를 전송하기 위한 프로토콜
헤더는 코덱정보, 순서정보, 타임스탬프, SSRC(Synchronized Source Identifier)양 단말간 여러 RTP세션을 구분 - 한 웹브라우저에서 2개 동영상 재생
- 헤더마다 코덱이 들어가므로 네트워크 상황에 따라 코덱을 바꿀 수 있다. 품질이 떨어지는 코덱
UDP/IP로 패킷 전송

응용층의 프로토콜
RTP데이터 전송 상태 감시, 세션 관련 정보 존송을 위한 프로토콜
- 상태 점검을 위한 것이므로 Server, Client간 양방향 통신으로 이루어진다
주기적으로 송수신자가 리포트 패킷을 서로 주고 받는다
보낸 패킷, 손실된 패킷, 패킷 수신 간격 변화 정도
- 재전송해서 늦게 도착하면 손실과 다름 없으므로 재전송은 안함
- 그래서 어떤 패킷이 손실됐는지는 포내지 않는다
RTP에 대한 Flow Control을 위해 사용
표준에눈 RTCP로 수집된 정보에 대해 어떻게 처리하는가에 대한 병시는 없다. 응용개발자 마음이다
- 네트워크 상태가 안 좋아지면 코텍을 바꾼다거나, 너무 많이 보내서 손실이 발생하는 것이라 판단되면 전송속도를 줄이는 증의 처리가 필요하다

응용층의 프로토콜
스트림이 데이터를 베어하기 위한 방법을 제공
재생, 일시정지, 빨리감기, 되감기, 재생 위치 변경 같은 명령 전송
표준에는 TCP나 UDP중 어느 것을 쓸지 정해져 있지 않음. 보통 UDP를 많이 사용
데이터 전송 포트와 다른 포트(554)를 사용한다
- FTP가 포트 2개를 써서 파일 전송과 명령 전송에 다른 커넥션을 사용하는 것과 같다
UDP 를 쓸 때는 어떻게 커넥션을 맺는가?
- SETUP 패킷 (커넥션 요청)의 내용에 받을 어떤 파일을 재생할 건지(URL), 포트 번호와 응용층의 프로토콜은 무엇을 사용할 건지 (RTP/UDP같은)를 알려주면 서버에서 session 번호를 알려준다. 그 세션번호를 가지고 클라이언트를 구분한다. 소켓(IP, Port)만 가지고 구분할 수 있지 않을까 생각할 수 있는데, 한 웹브라우저에서 한 화면에 두 개의 동영상을 재생하는 경우 IP와 Port만으로는 구분할 수 없다, 따라서 세션 번호가 필요하다.