실시간 전송 프로토콜

Real-time Transport Protocol
인터넷 프로토콜 스위트
응용 프로그램레이어
트랜스포트 레이어
인터넷 레이어
링크 레이어

Real-time Transport Protocol(RTP)은 IP 네트워크를 통해 오디오 및 비디오를 전송하기 위한 네트워크 프로토콜입니다.RTP는 텔레포니, WebRTC를 포함한 화상회의 애플리케이션, 텔레비전 서비스, Web 베이스의 푸시 투 토크 기능등의 스트리밍 미디어를 수반하는 통신 및 엔터테인먼트시스템에 사용됩니다.

RTP 는, 통상은 UDP 를 사용해 주세요.RTP는 RTP Control Protocol(RTCP)과 함께 사용됩니다.RTP가 미디어 스트림(오디오나 비디오 등)을 전송하는 동안 RTCP는 전송 통계 정보 및 Quality of Service(QoS)를 감시하기 위해 사용되며 여러 스트림의 동기화를 지원합니다.RTP는 Voice over IP의 기술적 기반 중 하나이며, 이 컨텍스트에서는 네트워크상에서 접속을 확립하는 Session Initiation Protocol(SIP) 등의 시그널링 프로토콜과 함께 자주 사용됩니다.

RTP는 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)의 Audio-Video Transport Working Group에 의해 개발되었으며 1996년에 처음 공개되었습니다. RFC1889는 2003년에 RFC3550으로 대체되었습니다.

개요

RTP는 스트리밍 미디어의 엔드 투 엔드의 실시간 전송을 위해 설계되었습니다.이 프로토콜은 특히 IP 네트워크에서의 UDP 전송 중에 공통적으로 발생하는 패킷 손실 및 잘못된 전달의 지터 보정 및 검출 기능을 제공합니다.RTP 를 사용하면, IP 멀티 [1]캐스트를 개입시켜 복수의 행선지에 데이터를 전송할 수 있습니다.RTP는 IP 네트워크에서 음성/비디오 전송의 주요 표준으로 간주되며 관련 프로파일 [2]및 페이로드 형식과 함께 사용됩니다.RTP의 설계는 운영 체제의 프로토콜 스택에 반해 프로토콜 기능이 애플리케이션에 구현되는 애플리케이션 계층 프레이밍으로 알려진 아키텍처 원리에 기초한다.

실시간 멀티미디어 스트리밍 애플리케이션에서는 정보의 적시에 전달이 필요하며, 이 목표를 달성하기 위해 패킷 손실을 허용할 수 있는 경우가 많습니다.예를 들면, 오디오 애플리케이션에서의 패킷의 손실은, 오디오 데이터의 일부분의 손실을 가져오는 경우가 있습니다.이것은, 적절한 에러 [3]은폐 알고리즘에 의해서 눈에 띄지 않게 되는 경우가 있습니다.Transmission Control Protocol(TCP)은 RTP [4]사용을 위해 표준화되었지만 TCP는 적시성보다 신뢰성을 우선하기 때문에 RTP 응용 프로그램에서는 일반적으로 사용되지 않습니다.대신 대부분의 RTP 구현은 UDP([3]User Datagram Protocol)를 기반으로 구축됩니다.멀티미디어 세션을 위해 특별히 설계된 다른 전송 프로토콜로는 SCTP와[5] DCCP가 [6]있지만, 2012년 현재 널리 [7]사용되고 있지는 않습니다.

RTP는 IETF 표준 조직의 Audio/Video Transport 작업 그룹에 의해 개발되었습니다.RTP는 H.323 및 RTSP와 [2]같은 다른 프로토콜과 함께 사용됩니다.RTP 사양은 RTP와 RTCP의 2가지 프로토콜을 기술하고 있습니다.RTP는 멀티미디어 데이터 전송에 사용되며, RTCP는 제어 정보와 QoS [8]파라미터를 정기적으로 송신하기 위해 사용됩니다.

데이터 전송 프로토콜인 RTP는 실시간 데이터를 전송합니다.이 프로토콜에 의해 제공되는 정보에는 타임스탬프(동기용), 시퀀스 번호(패킷 손실 및 순서 변경 검출용) 및 데이터의 [9]인코딩 형식을 나타내는 페이로드 형식이 포함됩니다.제어 프로토콜인 RTCP는 Quality of Service(QoS) 피드백 및 미디어 스트림 간의 동기화에 사용됩니다.RTCP 트래픽의 대역폭은 RTP에 비해 작습니다(통상은 약 5%).[9][10]

RTP 세션은 일반적으로 H.323, Session Initiation Protocol(SIP), RTSP 또는 징글(XMPP) 등의 시그널링 프로토콜을 사용하여 통신 피어 간에 시작됩니다.이러한 프로토콜은 세션 설명 프로토콜을 사용하여 [11]세션에 대한 매개변수를 지정할 수 있습니다.

멀티미디어 스트림별로 RTP 세션이 확립됩니다.오디오 스트림과 비디오스트림에서는 개별 RTP 세션을 사용하여 수신자가 특정 [12]스트림의 컴포넌트를 선택적으로 수신할 수 있습니다.RTP 및 RTCP 설계는 전송 프로토콜과 독립적입니다.일반적으로 응용 프로그램에서는 권한 없는 범위(1024~65535)[13]의 포트 번호를 가진 UDP를 사용합니다.신뢰할 수 있는 전송 프로토콜이 필요한 경우 Stream Control Transmission Protocol(SCTP) 및 Datagram Congestion Control Protocol(DCCP)을 사용할 수 있습니다.RTP 사양에서는 RTP의 짝수 포트 번호와 관련된 RTCP [14]: 68 세션의 다음 홀수 포트 번호를 사용할 것을 권장합니다.프로토콜을 [15]다중화하는 애플리케이션에서 RTP 및 RTCP에 단일 포트를 사용할 수 있습니다.

RTP는 Voice over IP, Audio over IP, WebRTC 및 Internet Protocol TV와 같은 실시간 멀티미디어 애플리케이션에서 사용됩니다.

프로파일 및 페이로드 형식

주요 기사: RTP 페이로드 형식

RTP는 다수의 멀티미디어 포맷을 전송하도록 설계되어 있기 때문에 RTP 표준을 변경하지 않고 새로운 포맷을 개발할 수 있습니다.이를 위해 프로토콜의 특정 애플리케이션에 필요한 정보는 일반 RTP 헤더에 포함되지 않습니다.RTP는 각 애플리케이션 클래스(오디오, 비디오 등)에 대해 프로파일과 관련된 페이로드 [8]형식을 정의합니다.특정 응용 프로그램에서 RTP를 인스턴스화하려면 프로파일 및 페이로드 형식의 [14]: 71 지정이 필요합니다.

프로파일은 RTP 헤더의 프로토콜 필드 Payload Type(PT; 페이로드 유형) 내의 페이로드 데이터 부호화에 사용되는 코덱 및 페이로드 형식 코드에 대한 매핑을 정의합니다.각 프로파일에는 몇 가지 페이로드 형식의 사양이 부속되어 있으며, 각 사양에는 특정 부호화 [2]데이터의 전송이 기술되어 있습니다.오디오 페이로드 형식의 예로는 G.711, G.723, G.726, G.729, GSM, QCELP, MP3, DTMF 등이 있으며 비디오 페이로드의 예로는 H.261, H.263, H.264, H.265 및 MPEG-1/[16]M-2가 있습니다.MPEG-4 오디오/비디오 스트림과 RTP 패킷의 매핑은 RFC 3016에 규정되어 있으며 H.263 비디오페이로드에 대해서는 RFC 2429에 [17]설명되어 있습니다.

RTP 프로파일의 예는 다음과 같습니다.

  • 최소한의 제어를 수반하는 음성 회의 및 화상 회의(RFC 3551)의 RTP 프로파일은, 스태틱한 페이로드 타입의 할당 세트, 및 페이로드 형식과 PT 값과의 매핑을 위한 다이내믹메커니즘을 정의합니다.
  • Secure Real-time Transport Protocol(SRTP)(RFC 3711)은 페이로드 [18]데이터 전송을 위한 암호화 서비스를 제공하는 RTP 프로파일을 정의합니다.
  • 기계간 [19]통신용 RTP(RTP/CDP)의 실험적인 제어 데이터 프로파일.

패킷 헤더

RTP 패킷은 응용 프로그램레이어에서 생성되어 전송을 위해 트랜스포트레이어에 전달됩니다.애플리케이션에 의해 작성된 RTP 미디어 데이터의 각 유닛은 RTP 패킷헤더로 시작합니다.

RTP 패킷헤더
오프셋 옥텟 0 1 2 3
옥텟 비트 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 버전 P X 참조 M PT 시퀀스 번호
4 32 타임스탬프
8 64 SSRC 식별자
12 96 CSRC 식별자
...
12+4×CC 96+32×CC 프로파일 고유의 확장 헤더 ID 확장 헤더 길이
16+4×CC 128+32×CC 확장 헤더
...

RTP 헤더의 최소 사이즈는 12바이트입니다.헤더 뒤에 옵션의 헤더 확장자가 있는 경우가 있습니다.그 뒤에 RTP 페이로드가 이어집니다.이 페이로드의 형식은 특정 응용 [20]프로그램클래스에 따라 결정됩니다.헤더의 필드는 다음과 같습니다.

  • 버전: (2비트)프로토콜의 버전을 나타냅니다.현재 버전은 [21]2입니다.
  • P(Padding): (1비트) RTP 패킷 끝에 추가 패딩 바이트가 있는지 여부를 나타내기 위해 사용합니다.패딩은 예를 들어 암호화 알고리즘에 의해 요구되는 특정 크기의 블록을 채우기 위해 사용할 수 있습니다.패딩의 마지막 바이트에는 추가된 패딩 바이트 수(자체 [14]: 12 [21]포함)가 포함됩니다.
  • X(확장): (1비트) 헤더와 페이로드 데이터 사이에 확장 헤더가 존재함을 나타냅니다.확장 헤더는 응용 프로그램 또는 프로파일 [21]고유합니다.
  • CC(CSRC 카운트): (4비트) SSRC 뒤에 있는 CSRC 식별자(아래 정의됨)의 수를 포함합니다([14]: 12 아래 정의됨).
  • M(마커): (1비트) 어플리케이션레벨에서 프로파일 고유의 방법으로 사용되는 시그널링.설정되어 있는 경우는,[14]: 13 현재의 데이터가 애플리케이션에 특별한 관련성이 있는 것을 의미합니다.
  • PT(페이로드 타입): (7비트)payload의 형식을 나타내며 응용 프로그램에 의한 해석을 결정합니다.값은 프로파일에 따라 [22]다르며 동적으로 할당할 수 있습니다.
  • 시퀀스 번호: (16비트)시퀀스 번호는, 송신되는 RTP 데이터 패킷 마다 증분해, 패킷의[1] 손실을 검출해, 순서외의 전달에 대응하기 위해서, 수신측이 사용합니다.Secure Real-time Transport Protocol에 대한 기존 플레인텍스트 공격을 보다 [14]: 13 어렵게 하기 위해 시퀀스 번호의 초기값을 랜덤화해야 합니다.
  • 타임스탬프: (32비트) 수신자가 수신한 샘플을 적절한 시간과 간격으로 재생하기 위해 사용합니다.여러 미디어 스트림이 존재하는 경우 각 [b]스트림에서 타임스탬프가 독립적일 수 있습니다.타이밍의 세밀도는 어플리케이션에 따라 다릅니다.예를 들어 125μs(8kHz, 디지털텔레포니의 일반적인 샘플링 레이트)마다 데이터를 샘플링하는 오디오애플리케이션에서는, 그 값이 클럭 분해능으로서 사용됩니다.비디오 스트림은 보통 90kHz 클럭을 사용합니다.클럭의 입도는 [23]응용 프로그램의 RTP 프로파일로 지정되어 있는 상세 정보의1개입니다.
  • SSRC: (32비트) 동기화 소스 식별자는 스트림의 소스를 고유하게 식별합니다.같은 RTP 세션내의 동기 송신원은 [14]: 15 일의입니다.
  • CSRC:(각 32비트, 엔트리 수는 CSRC 카운트필드에 의해 표시됩니다) 기여 송신원 ID 는, 복수의 [14]: 15 송신원으로부터 생성된 스트림에 기여하는 송신원을 열거합니다.
  • Header Extension : (옵션, [Extension]필드로 표시되는 존재감)첫 번째 32비트 워드에는 프로파일 고유 식별자(16비트)와 확장 헤더의 32비트를 제외한 32비트 단위의 확장 길이를 나타내는 길이 지정자(16비트)가 포함됩니다.확장 헤더 데이터는 [14]: 18 다음과 같습니다.

응용 프로그램 설계

기능성 멀티미디어 애플리케이션에는 RTP와 함께 사용되는 다른 프로토콜과 표준이 필요합니다. SIP, 징글, RTSP, H.225 및 H.245와 같은 프로토콜은 세션 시작, 제어 및 종료에 사용됩니다.H.264, MPEG, H.263 등의 기타 표준은 해당 RTP [24]프로파일로 지정된 페이로드 데이터의 부호화에 사용됩니다.

RTP 송신측은, 멀티미디어 데이터를 캡쳐 해, 적절한 타임스탬프와 시퀀스 번호를 가지는 RTP 패킷으로서 부호화, 프레임화해 송신합니다.송신측은, 접속 네고시에이션 및 사용중의 RTP 프로파일에 따라서, payload 타입 필드를 설정합니다.RTP 리시버는 누락된 패킷을 검출하여 패킷을 재정렬할 수 있습니다.payload 유형에 따라 패킷 내의 미디어 데이터를 디코딩하여 사용자에게 [24]스트림을 제공합니다.

표준 문서

  • RFC 3550, Standard 64, RTP: 실시간응용 전송 프로토콜
  • RFC 3551, Standard 65, 최소한의 제어로 음성 및 화상 회의를 위한 RTP 프로파일
  • RFC 4855, RTP 페이로드 형식의 미디어 유형 등록
  • RFC 4856, 음성 및 화상 회의용 RTP 프로파일에서의 페이로드 형식의 미디어 유형 등록
  • RFC 7656, RTP(Real-Time Transport Protocol) 소스를 위한 의미론 및 메커니즘 분류법

「 」를 참조해 주세요.

메모들

  1. ^ 비트는 최상위 비트부터 최하위 비트 순서로 정렬됩니다.비트 오프셋0 은 첫 번째 옥텟의 최상위 비트입니다.옥텟은 네트워크 순서로 전송됩니다.비트 전송 순서는 미디엄에 의존합니다.
  2. ^ RFC 7273은 서로 다른 스트림의 미디어 클럭 간의 관계를 시그널링하는 수단을 제공합니다.

레퍼런스

  1. ^ a b Daniel Hardy (2002). Network. De Boeck Université. p. 298.
  2. ^ a b c Perkins 2003, 페이지 55
  3. ^ a b Perkins 2003, 페이지 46
  4. ^ RFC 4571
  5. ^ Farrel, Adrian (2004). The Internet and its protocols. Morgan Kaufmann. p. 363. ISBN 978-1-55860-913-6.
  6. ^ Ozaktas, Haldun M.; Levent Onural (2007). THREE-DIMENSIONAL TELEVISION. Springer. p. 356. ISBN 978-3-540-72531-2.
  7. ^ Hogg, Scott. "What About Stream Control Transmission Protocol (SCTP)?". Network World. Retrieved 2017-10-04.
  8. ^ a b Larry L. Peterson (2007). Computer Networks. Morgan Kaufmann. p. 430. ISBN 978-1-55860-832-0.
  9. ^ a b Perkins 2003, 56페이지
  10. ^ Peterson 2007, 페이지 435 : 2007
  11. ^ RFC 4566: SDP: Session Description Protocol, M. Handley, V. Jacobson, C.Perkins, IETF (2006년 7월)
  12. ^ Zurawski, Richard (2004). "RTP, RTCP and RTSP protocols". The industrial information technology handbook. CRC Press. pp. 28–7. ISBN 978-0-8493-1985-3.
  13. ^ Collins, Daniel (2002). "Transporting Voice by using IP". Carrier grade voice over IP. McGraw-Hill Professional. pp. 47. ISBN 978-0-07-136326-6.
  14. ^ a b c d e f g h i RFC 3550
  15. ^ Multiplexing RTP Data and Control Packets on a Single Port. IETF. April 2010. doi:10.17487/RFC5761. RFC 5761. Retrieved November 21, 2015.
  16. ^ Perkins 2003, 페이지 60
  17. ^ Chou, Philip A.; Mihaela van der Schaar (2007). Multimedia over IP and wireless networks. Academic Press. pp. 514. ISBN 978-0-12-088480-3.
  18. ^ Perkins 2003, 367페이지
  19. ^ Breese, Finley (2010). Serial Communication over RTP/CDP. BoD - Books on Demand. pp. [1]. ISBN 978-3-8391-8460-8.
  20. ^ Peterson 2007, 페이지 430 : 2007
  21. ^ a b c Peterson 2007, 페이지 431 : 2007
  22. ^ Perkins 2003, 59페이지
  23. ^ 피터슨, 페이지 432
  24. ^ a b Perkins 2003, 11-13페이지

추가 정보

외부 링크