실시간 전송 프로토콜

IP스택 섬네일 **실시간 전송 프로토콜**(Real-time Transport Protocol, **RTP**)은 IP 네트워크 상에서 오디오와 비디오를 전달하기 위한 통신 프로토콜이다. RTP는 전화, 그리고 WebRTC, 텔레비전 서비스, 웹 기반 푸시 투 토크 기능을 포함한 화상 통화 분야 등의 스트리밍 미디어를 수반하는 통신, 엔터테인먼트 시스템에 사용된다. RTP는 일반적으로 사용자 데이터그램 프로토콜(UDP)로 동작한다. RTP는 RTCP(RTP Control Protocol)와 결합하여 사용된다. RTP가 오디오/비디오와 같은 미디어 스트림을 전달하는 반면, RTCP는 전송 통계와 QoS를 모니터링하고 다중 스트림의 동기화를 도와준다. RTP는 VoIP의 기술 재단의 하나이며 이 문맥에서 네트워크의 연결을 확립하는 세션 개시 프로토콜(SIP)과 같은 시그널링 프로토콜과 결합해서 사용하기도 한다. RTP는 국제 인터넷 표준화 기구(IETF)의 오디오 비디오 트랜스포트 워킹 그룹이 개발하였으며 RTC 1889로 1996년 처음 출판되었으며 2003년에 RFC 3550가 RTP를 대신하게 되었다.
# 개요
RTP는 스트리밍 미디어의 단대단, 실시간 전송을 위해 설계되었다. 이 프로토콜은 지터 보상, 그리고 패킷 손실, 아웃 오브 오더 딜리버리의 감지(특히 IP 네트워크에서 UDP 전송 시 일반적임)를 위한 기능들을 제공한다. RTP는 IP 멀티캐스트를 통해 여러 장소에 데이터를 전송할 수 있게 한다.year= 2002 RTP는 IP 네트워크의 오디오/비디오 전송의 주된 표준으로 간주되며 연관 프로파일 및 페이로드 포맷과 함께 사용된다. RTP의 설계는 애플리케이션 레이어 프레이밍이라는 이름의 구조적 원칙에 기반을 두며 여기에서 프로토콜 기능들이 운영 체제의 프로토콜 스택이 아닌 애플리케이션에 구현된다. 실시간 멀티미디어 스트리밍 애플리케이션들은 시기적절한 정보 전달을 요구하며 이러한 목적을 달성하기 위해 일부 패킷 손실을 눈감아준다. 이를테면 오디오 부분의 패킷 손실은 1초의 사소한 오디오 데이터 손실을 일으킬 수 있으나 적절한 오류 은닉 알고리즘을 통해 눈치채지 못하게 만들 수 있다.p=46 전송 제어 프로토콜(TCP)이 RTP용으로 표준화되어 있기는 하지만,RFC 4571 RTP에 일반적으로 사용되지는 않는데, 그 이유는 TCP는 시기적절함보다 신뢰성을 더 우선시하기 때문이다. RTP 구현체들 다수는 TCP 대신 사용자 데이터그램 프로토콜(UDP)를 사용한다. 멀티미디어 세션에 특화되어 설계된 그 밖의 전송 프로토콜로는 SCTPisbn=978-1-55860-913-6, DCCP,isbn=978-3-540-72531-2가 있으나 2012년 기준으로 널리 사용되지는 않고 있다.access-date=2017-10-04 RTP는 IETF 표준화 기구의 오디오/비디오 트랜스포트 워킹 그룹에 의해 개발되었다. RTP는 H.323, RTSP 등의 다른 프로토콜들과 결합하여 사용된다.p=55 RTP 사양은 2가지 프로토콜을 기술하고 있다: RTP와 RTCP. RTP는 멀티미디어 데이터의 전송을 위해 사용되며 RTCP는 제어 정보 및 QoS 변수를 주기적으로 송신하기 위해 사용된다.isbn=978-1-55860-832-0 데이터 전송 프로토콜 RTP는 실시간 데이터를 전달한다. 이 프로토콜이 제공하는 정보에는 타임스탬프(동기화를 위해), 시퀀스 번호(패킷 손실 및 재정렬 감지를 위해), 데이터의 인코딩 포맷을 지시하는 페이로드 포맷이 포함된다.p=56 제어 프로토콜 RTCP는 미디어 스트림 간 QoS 피드백과 동기화용으로 사용된다. RTP에 비해 RTCP 트래픽 대역은 적은 편으로, 대개 약 5% 정도이다.p=435 RTP 세션은 일반적으로 H.323, 세션 개시 프로토콜(SIP), RTSP, 또는 징글(XMPP) 등 시그널링 프로토콜을 사용하여 통신 피어 간에 초기화된다. 이러한 프로토콜들은 세션 기술 프로토콜을 사용하여 세션의 변수를 지정할 수 있다.RFC 4566: *SDP: Session Description Protocol*, M. Handley, V. Jacobson, C. Perkins, IETF (July 2006) RTP 세션은 개별 멀티미디어 스트림별로 확립된다. 오디오와 비디오 스트림은 별도의 RTP 세션을 사용할 수 있으며 수상기가 선별적으로 특정 스트림의 컴포넌트를 수신할 수 있게 만들어준다.isbn=978-0-8493-1985-3 세션 하나에는 도착지 IP 주소 + RTP/RTCP 포트 쌍으로 구성된다. 사양에 따르면 RTP 포트 번호는 짝수로 선정할 것, 그리고 각각의 연관되는 RTCP 포트는 그 다음의 홀수 번호로 선정할 것을 권고한다.68 그러나 프로토콜의 멀티플렉싱 상황에서는 RTP와 RTCP에 단일 포트가 선정된다.accessdate=November 21, 2015 RTP와 RTCP는 보통 특권이 없는 UDP 포트(1024 ~ 65535)를 사용하지만,isbn=978-0-07-136326-6 프로토콜 설계가 전송에 독립적이기 때문에 다른 전송 프로토콜들인 SCTP, DCCP을 사용할 수도 있다.
# 프로파일 및 페이로드 포맷
RTP 페이로드 포맷 RTP의 설계적 고려사항 가운데 하나는 일정한 범위의 멀티미디어 포맷을 전달하고 RTSP 표준을 개정하지 않고도 새로운 포맷을 허용하는 것이다. 즉, 특정 프로토콜 애프리케이션에 필요한 정보가 제네릭 RTP 헤더에 포함되지 않는 대신에 별도의 RTP 프로파일 및 관련 페이로드 포맷을 통해 제공된다는 것을 의미한다. 각 애프리케이션 클래스(예: 오디오, 비디오)에 대해 RTP는 프로파일 및 하나 이상의 관련 페이로드 포맷들을 정의한다.isbn=978-1-55860-832-0 특정 애플리케이션 사용을 위한 완전한 RTP 사양은 프로파일과 페이로드 포맷 사양을 요구한다.355071 프로파일은 페이로드 데이터를 인코딩하기 위해 사용되는 코덱 및 페이로드 포맷 코드 매핑을 RTP 헤더의 PT(Payload Type) 필드에 정의한다. 각 프로파일에는 여러 페이로드 포맷 사양이 포함되며 각각은 인코딩된 특정 데이터의 전송 정보를 기술한다. 오디오 페이로드 포맷에는 G.711, G.723, G.726, G.729, GSM, QCELP, MP3, DTMF가 포함되며, 비디오 페이로드 포맷에는 H.261, H.263, H.264, H.265, MPEG-1/MPEG-2가 포함된다.p=60 MPEG-4 오디오/비디오 스트림을 RTP 패킷에 매핑시키는 것에 관한 내용은 3016에 규정되어 있으며 H.263 비디오 페이로드의 경우 2429에 기술되어 있다.isbn=978-0-12-088480-3 RTP 프로파일의 예는 다음과 같다: * 최소한의 제어를 통한 음성 및 화상 회의를 위한 RTP 프로파일(RTP profile for Audio and video conferences with minimal control, 3551)은 정적 페이로드 타입 할당들, 그리고 페이로드 포맷 간 매핑을 위한 동적 구조, 그리고 세션 기술 프로토콜(SDP)을 사용한 PT 값을 정의한다. * SRTP(Secure Real-time Transport Protocol, 3711)는 페이로드 데이터의 전송을 위한 암호화 서비스를 제공하는 RTP 프로파일을 정의한다.p=367 * 기계 대 기계 통신을 위한 실험적인 RTP/CDP(Control Data Profile for RTP).isbn=978-3-8391-8460-8
# 패킷 헤더
RTP 패킷은 응용 계층에서 만들어지며 전달을 위해 전송 계층에 전달된다. 애플리케이션이 만드는 RTP 미디어 데이터의 각 단위는 RTP 패킷 헤더로 시작한다. {| class="wikitable" |+RTP 패킷 헤더 |- ! 비트 오프셋 ! colspan="2"| 0-1 ! colspan="1"| 2 ! colspan="1"| 3 ! colspan="4"| 4-7 ! colspan="1" | 8 ! colspan="6" | 9-15 ! colspan="15" | 16-31 |- align="center" ! 0 | colspan="2"|버전 | colspan="1"|P | colspan="1"|X | colspan="4"|CC | colspan="1"|M | colspan="6"|PT | colspan="15"|일련 번호 |- align="center" ! colspan="1"|32 | colspan="32"|타임스탬프 |- align="center" ! 64 | colspan="32"|SSRC 식별자 |- align="center" ! 96 | colspan="32" bgcolor="#FFBBBB"|CSRC 식별자들
... |- align="center" ! 96+32×CC | colspan="16" bgcolor="#FFBBBB"|프로파일에 따른 확장 헤더 ID | colspan="16" bgcolor="#FFBBBB"|확장 헤더 길이 |- ! 128+32×CC | colspan="32" bgcolor="#FFBBBB"|확장 헤더
... |}
# 표준 문서
* RFC 3550, Standard 64, *RTP: A Transport Protocol for Real-Time Applications* * RFC 3551, Standard 65, *RTP Profile for Audio and Video Conferences with Minimal Control* * RFC 4855, *Media Type Registration of RTP Payload Formats* * RFC 4856, *Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences* * RFC 7656, *A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources* * RFC 3190, *RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio* * RFC 6184, *RTP Payload Format for H.264/MPEG-4 AVC Video* * RFC 3640, *RTP Payload Format for Transport of MPEG-4 Elementary Streams* * RFC 6416, *RTP Payload Format for MPEG-4 Audio/Visual Streams* * RFC 2250, *RTP Payload Format for MPEG-1/MPEG2 Video* * RFC 4175, *RTP Payload Format for Uncompressed Video* * RFC 6295, *RTP Payload Format for MIDI* * RFC 4696, *An Implementation Guide for RTP MIDI* * RFC 7587, *RTP Payload Format for the Opus Speech and Audio Codec* * RFC 7798, *RTP Payload Format for 고효율 비디오 코딩 (HEVC)*