RTP 및 RSVP 프로토콜,

http://www.isuct.ru/~ivt/books/NETWORKING/NET10/269/pa.html

최신 응용 프로그램늦게 도착하는 패키지를 용납할 수 없습니다. 두 가지 프로토콜(RTP 및 PSVP)은 서비스 품질로 적시 제공을 보장합니다.

인터넷과 사설 네트워크의 지속적인 성장은 대역폭에 대한 새로운 요구를 제기합니다. 클라이언트-서버 응용 프로그램은 전송되는 데이터의 양 측면에서 Telnet보다 훨씬 우수합니다. World Wide Web은 그래프의 엄청난 증가로 이어졌습니다. 그래픽 정보. 또한 오늘날 음성 및 비디오 애플리케이션은 이미 과부하된 네트워크에 대해 고유한 특정 요구 사항을 제시합니다.

이러한 모든 요구 사항을 충족하려면 네트워크 용량을 한 번 늘리는 것만으로는 충분하지 않습니다. 실제로 필요한 것은 일정 관리 및 작업 부하 제어를 위한 스마트하고 효율적인 방법입니다.

역사적으로 IP 기반 네트워크는 모든 애플리케이션에 가능한 가장 단순한 데이터 전달 서비스만 제공했습니다. 그러나 시간이 지남에 따라 요구 사항이 변경되었습니다. 데이터를 전송하기 위해 IP 기반 네트워크를 설치하는 데 수백만 달러를 지출한 조직 로컬 네트워크, 그들은 이제 그러한 구성이 새로운 멀티캐스트 실시간 멀티미디어 애플리케이션을 효율적으로 지원할 수 없다는 사실에 직면해 있습니다.

ATM은 원래 실시간 트래픽과 함께 일반 TCP 및 UDP 트래픽을 지원하도록 설계된 유일한 네트워크 기술입니다. 그러나 ATM으로 전환한다는 것은 실시간 트래픽을 위한 새로운 네트워크 인프라를 생성하거나 기존 IP 기반 구성을 교체하는 것을 의미하며 이 두 가지 모두 매우 비용이 많이 듭니다.

따라서 TCP/IP 아키텍처 내에서 서비스 품질 요구 사항이 서로 다른 여러 유형의 트래픽을 지원해야 하는 필요성이 매우 시급합니다. 이 문제는 두 가지 방법으로 해결하기 위한 것입니다. 핵심 도구: 실시간 전송 프로토콜(RTP) 및 리소스 예약 프로토콜(RSVP).

RTP는 지정된 제한 내에서 지연된 데이터를 하나 이상의 대상으로 전달하도록 보장합니다. 즉, 데이터를 실시간으로 재생할 수 있습니다. RSVP를 통해 최종 시스템은 네트워크 리소스를 예약하여 필요한 서비스 품질, 특히 RTP 프로토콜을 통한 실시간 트래픽 리소스를 확보할 수 있습니다.

가장 널리 사용되는 전송 계층 프로토콜은 TCP입니다. TCP는 다양한 분산 응용 프로그램을 지원할 수 있지만 실시간 응용 프로그램에는 적합하지 않습니다.

실시간 애플리케이션에서 발신자는 일정한 속도로 데이터 스트림을 생성하고 수신자는 해당 데이터를 동일한 속도로 애플리케이션에 제공해야 합니다. 이러한 응용 프로그램에는 오디오 및 화상 회의, 라이브 비디오 배포(즉시 재생용), 공유 작업 공간, 의료 원격 진단, 컴퓨터 전화 통신, 분산 대화형 시뮬레이션, 게임 및 실시간 모니터링이 포함됩니다.

이러한 응용 프로그램의 전송 프로토콜로 TCP를 사용하는 것은 여러 가지 이유로 불가능합니다. 첫째, 이 프로토콜을 사용하면 둘 사이에만 연결을 설정할 수 있습니다. 끝점따라서 멀티캐스팅에 적합하지 않습니다. 실시간 애플리케이션이 더 이상 기다리지 않을 때 도착하는 손실된 세그먼트의 재전송을 제공합니다. 또한 TCP에는 실시간 응용 프로그램의 요구 사항이기도 한 세그먼트와 타이밍 정보를 연결하는 편리한 메커니즘이 없습니다.

널리 사용되는 또 다른 전송 계층 프로토콜인 UDP에는 처음 두 가지가 없습니다.

제한 사항(점대점 연결 및 손실된 세그먼트 전송)을 제공하지 않습니다. 중요한 정보동기화에 대해. 따라서 UDP 자체에는 실시간 응용 프로그램을 위한 범용 도구가 없습니다.

각 실시간 응용 프로그램에는 실시간 전송을 지원하는 자체 메커니즘이 있을 수 있지만 단일 프로토콜을 정의하는 것이 매우 바람직한 많은 공통 기능을 공유합니다. 이러한 종류의 표준 프로토콜은 RFC 1889에 정의된 RTP입니다.

일반적인 실시간 환경에서 발신자는 일정한 속도로 패킷을 생성합니다. 그것들은 일정한 간격으로 그들에게 전송되고, 네트워크를 통해 이동하고, 수신기에 의해 수신되며 수신된 데이터를 실시간으로 재생합니다.

그러나 패킷이 네트워크를 통해 이동할 때 대기 시간의 변화로 인해 불규칙한 간격으로 도착합니다. 이 효과를 보상하기 위해 들어오는 패킷은 버퍼링되고 잠시 동안 유지된 다음 출력 생성 소프트웨어에 일정한 속도로 제공됩니다. 이 체계가 작동하도록 하기 위해 각 패킷에 타임스탬프가 지정되어 수신자가 발신자와 동일한 속도로 수신 데이터를 재생할 수 있습니다.

RTP는 세션의 여러 참가자 간의 실시간 데이터 전송을 지원합니다. (세션은 데이터 전송 기간 동안 유지되는 둘 이상의 RTP 사용자 간의 논리적 관계입니다. 세션을 여는 프로세스는 RTP 범위를 벗어납니다.)

RTP는 실시간 유니캐스트에도 사용할 수 있지만 장점은 멀티캐스트 지원에 있습니다. 이를 위해 각 RTP 데이터 블록에는 데이터를 생성하는 참가자를 나타내는 발신자 식별자가 포함되어 있습니다. RTP 데이터 블록에는 수신 측에서 정확한 간격으로 데이터를 재생할 수 있도록 타임스탬프도 포함되어 있습니다.

또한 RTP는 전송되는 데이터의 페이로드 형식을 정의합니다. 이것과 직접적으로 관련된 것은 동기화의 개념이며, 이는 부분적으로 믹서의 책임인 RTP 변환 메커니즘입니다. 하나 이상의 소스에서 RTP 패킷 스트림을 수신하면 이를 결합하고 하나 이상의 수신자에게 새로운 RTP 패킷 스트림을 보냅니다. 믹서는 단순히 데이터를 결합하고 형식을 변경할 수 있습니다.

믹서 응용 예 - 여러 오디오 소스 결합. 예를 들어, 주어진 오디오 세션의 일부 시스템이 각각 고유한 RTP 스트림을 생성한다고 가정합니다. 대부분의 경우 하나의 소스만 활성화되지만 때로는 여러 소스가 동시에 "대화"합니다.

만약 새로운 시스템세션에 참여하기를 원하지만 네트워크에 대한 링크가 모든 RTP 스트림을 지원할 만큼 정확한 용량이 충분하지 않은 경우 믹서는 이러한 모든 스트림을 수신하여 하나로 병합하고 마지막 스트림을 새 세션 구성원에게 전달합니다. 여러 스트림이 수신되면 믹서는 PCM 값을 추가합니다. 믹서에 의해 생성된 RTP 헤더에는 패킷에 데이터가 있는 발신자의 식별자가 포함됩니다.

더 간단한 장치는 들어오는 RTP 패킷마다 하나의 나가는 RTP 패킷을 만듭니다. 변환기라고 하는 이 메커니즘은 패킷의 데이터 형식을 변경하거나 다른 저수준 프로토콜 집합을 사용하여 한 도메인에서 다른 도메인으로 데이터를 전송할 수 있습니다. 예를 들어, 잠재적 수신자는 세션의 다른 참가자가 사용하는 고속 비디오 신호를 처리하지 못할 수 있습니다. 그런 다음 변환기는 비디오를 더 낮은 비트 전송률이 필요한 더 낮은 품질의 형식으로 변환합니다.

각 RTP 패킷에는 기본 헤더와 추가 응용 프로그램별 필드가 있을 수 있습니다. 쌀. 도 4는 메인 헤더의 구조를 나타낸다. 처음 12개의 옥텟은 다음 필드로 구성됩니다.

  • 버전 필드(2비트): 현재 버전- 초;
  • 패딩 필드(1비트): 이 필드는 페이로드 끝에 패딩 옥텟이 있음을 나타냅니다. (패딩은 애플리케이션에서 페이로드 크기가 예를 들어 32비트의 배수가 되도록 요구할 때 적용됩니다.) 이 경우 마지막 옥텟은 패딩 옥텟의 수를 나타냅니다.
  • 헤더 확장 필드(1비트): 이 필드가 설정되면 기본 헤더 뒤에 실험적 RTP 확장에 사용되는 추가 헤더가 옵니다.
  • 발신자 카운트 필드(4비트): 이 필드는 데이터가 패킷에 있는 발신자의 식별자 수를 포함하며 식별자 자체는 메인 헤더 다음에 있습니다.
  • 마커 필드(1비트): 마커 비트의 의미는 페이로드 유형에 따라 다릅니다. 마커 비트는 일반적으로 데이터 스트림의 경계를 나타내는 데 사용됩니다. 동영상의 경우 프레임의 끝을 설정합니다. 음성의 경우 일정 시간 침묵 후 말의 시작을 지정합니다.
  • 페이로드 유형 필드(7비트): 이 필드는 압축 및 암호화를 포함한 페이로드 유형 및 데이터 형식을 식별합니다. 정지 상태에서 발신자는 세션당 하나의 페이로드 유형만 사용하지만 실시간 전송 제어 프로토콜(Real-Time Transport Control Protocol)에 의해 신호를 받으면 변화하는 조건에 따라 변경할 수 있습니다.
  • 필드 일련 번호(16비트): 각 소스는 임의의 번호에서 패킷 번호를 매기기 시작한 다음 RTP 데이터 패킷이 전송될 때마다 1씩 증가합니다. 이를 통해 패킷 손실을 감지하고 동일한 타임스탬프를 가진 패킷의 순서를 결정할 수 있습니다. 여러 개의 연속 패킷이 논리적으로 동일한 순간에 생성되는 경우 동일한 타임스탬프를 가질 수 있습니다(예: 동일한 비디오 프레임에 속하는 패킷).
  • 타임스탬프 필드(32비트): 페이로드 데이터의 첫 번째 옥텟이 여기에서 생성된 시점을 기록합니다. 이 필드에 시간이 지정되는 단위는 페이로드 유형에 따라 다릅니다. 값은 보낸 사람의 로컬 시계에 의해 결정됩니다.
  • 동기 소스 ID 필드: 세션 중에 소스를 고유하게 식별하는 무작위로 생성된 번호입니다.

메인 헤더 다음에 페이로드에 데이터가 있는 하나 이상의 발신자 식별자 필드가 올 수 있습니다. 이러한 식별자는 믹서에 의해 삽입됩니다.

RTP 프로토콜사용자 데이터(일반적으로 멀티캐스트)를 세션의 모든 참가자에게 전송하는 데만 사용됩니다. 별도의 RTCP(실시간 전송 제어 프로토콜)는 여러 대상과 함께 작동하여 피드백 RTP 데이터 발신자 및 기타 세션 참가자와

RTCP는 RTP(보통 UDP)와 동일한 기본 전송 프로토콜을 사용하지만 다른 포트 번호를 사용합니다. 각 세션 참가자는 주기적으로 RTCP 패킷을 다른 모든 세션 참가자에게 보냅니다. RFC 1889는 RTCP가 수행하는 세 가지 기능을 설명합니다.

첫 번째 기능은 혼잡 시 서비스 품질과 피드백을 제공하는 것입니다. RTCP 패킷은 멀티캐스트이므로 세션의 모든 참가자는 다른 참가자가 얼마나 잘 작동하고 수신하는지 평가할 수 있습니다. 보낸 사람의 메시지를 통해 받는 사람은 데이터 속도와 전송 품질을 평가할 수 있습니다. 수신자의 메시지에는 패킷 손실 및 과도한 리플을 포함하여 그들이 겪고 있는 문제에 대한 정보가 포함되어 있습니다. 예를 들어, 링크가 주어진 비트 레이트에서 원하는 서비스 품질을 제공하지 않는 경우 오디오/비디오 애플리케이션에 대한 비트 레이트가 감소될 수 있습니다.

수신자 피드백도 전파 오류를 진단하는 데 중요합니다.

세션에 있는 모든 참가자의 메시지를 분석하여 네트워크 관리자는 주어진 문제가 한 참가자와 관련된 것인지 아니면 일반적인 문제인지 결정할 수 있습니다.

RTCP의 두 번째 주요 기능은 발신자 식별입니다. RTCP 패킷에는 발신자에 대한 표준 텍스트 설명이 포함되어 있습니다. 무작위로 선택한 동기화 소스 ID보다 데이터 패킷의 발신자에 대한 더 많은 정보를 제공합니다. 또한 사용자가 다른 세션과 관련된 스레드를 식별하는 데 도움이 됩니다. 예를 들어 사용자가 별도의 오디오 및 비디오 세션이 동시에 열려 있는지 확인할 수 있습니다.

세 번째 기능은 세션 크기 조정 및 크기 조정입니다. 서비스 품질과 혼잡 제어를 위한 피드백을 보장하고 발신자를 식별하기 위해 모든 참가자는 주기적으로 RTCP 패킷을 보냅니다. 이러한 패킷의 전송 빈도는 참가자 수가 증가함에 따라 감소합니다.

참가자 수가 적은 경우 최대 5초마다 하나의 RTCP 패킷이 전송됩니다. RFC 1889는 참가자가 총 참가자 수를 기반으로 RTCP 패킷의 속도를 제한하는 알고리즘을 설명합니다. 목표는 RTCP 트래픽을 총 세션 트래픽의 5% 미만으로 유지하는 것입니다.

모든 네트워크의 목적은 다음을 포함하여 보장된 서비스 품질로 수신자에게 데이터를 전달하는 것입니다. 처리량, 지연 및 허용 지연 변동 한계. 사용자와 애플리케이션의 수가 증가함에 따라 서비스 품질을 보장하는 것이 점점 더 어려워지고 있습니다.

과부하에 대응하는 것만으로는 더 이상 충분하지 않습니다. 혼잡을 완전히 피하려면, 즉 애플리케이션이 필요한 서비스 품질에 따라 네트워크 리소스를 예약할 수 있도록 하는 도구가 필요합니다.

예방 조치는 유니캐스트와 멀티캐스트 모두에 유용합니다. 유니캐스트에서 두 애플리케이션은 주어진 세션에 대한 특정 서비스 품질 수준에 동의합니다. 네트워크 부하가 크면 필요한 서비스 품질을 제공하지 못할 수 있습니다. 이 상황에서 응용 프로그램은 더 나은 시간이 될 때까지 세션을 연기하거나 가능한 경우 서비스 품질 요구 사항을 줄이려고 노력해야 합니다.

이 경우의 솔루션은 유니캐스트 응용 프로그램이 필요한 수준의 서비스를 제공하기 위해 리소스를 예약하는 것입니다. 그런 다음 의도한 경로의 라우터는 리소스를 할당합니다(예: 대기열의 한 위치 및 나가는 회선 용량의 일부). 라우터가 이전 커밋으로 인해 리소스를 할당할 수 없는 경우 애플리케이션에 알립니다. 이 경우 응용 프로그램은 서비스 요구 사항의 품질이 낮은 다른 세션을 시작하거나 나중에 다시 예약하려고 할 수 있습니다.

멀티캐스트는 훨씬 더 많은 것을 제공합니다. 도전적인 작업리소스 예약. 그것은 거대한 볼륨의 생성으로 이어집니다. 네트워크 그래픽- 예를 들어, 비디오와 같은 애플리케이션의 경우 또는 수신자 그룹이 크고 분산되어 있는 경우. 그러나 멀티캐스트 소스의 트래픽은 원칙적으로 크게 줄일 수 있습니다.

여기에는 두 가지 이유가 있습니다. 첫째, 그룹의 일부 구성원은 특정 기간에 특정 소스에서 데이터를 전달할 필요가 없을 수 있습니다. 따라서 한 그룹의 구성원은 두 채널(두 소스에서)을 통해 동시에 정보를 수신할 수 있지만 수신자는 하나의 채널만 수신하는 데 관심이 있을 수 있습니다.

둘째, 그룹의 일부 구성원은 발신자가 전송한 정보의 일부만 처리할 수 있습니다. 예를 들어, 비디오 스트림은 두 가지 구성요소로 구성될 수 있습니다. 하나는 낮은 화질을 갖고 다른 하나는 고화질을 갖습니다. 이 형식에는 여러 가지 비디오 압축 알고리즘이 있습니다. 추가 구성 요소더 높은 해상도로.

일부 수신자는 다음을 사용하여 구성 요소를 처리하기에 충분한 처리 능력이 없을 수 있습니다. 높은 해상도또는 전체 신호를 전달할 수 있는 용량이 충분하지 않은 서브넷 또는 링크를 통해 네트워크에 연결됩니다.

리소스 예약을 통해 라우터는 멀티캐스트 트래픽을 모든 수신자에게 전달할 수 있는지 여부를 미리 결정할 수 있습니다.

리소스 예약을 구현하려는 이전 시도와 프레임 릴레이 및 ATM에서 채택된 접근 방식에서 필요한 리소스는 데이터 흐름의 소스에서 요청합니다. 이 방법은 유니캐스트 전송의 경우 전송 응용 프로그램이 특정 속도로 데이터를 전송하고 필요한 수준의 서비스 품질이 전송 방식에 내재되어 있기 때문에 충분합니다.

그러나 이 접근 방식은 멀티캐스팅에 사용할 수 없습니다. 그룹 구성원마다 리소스 요구 사항이 다를 수 있습니다. 원본 스트림을 하위 스트림으로 나눌 수 있는 경우 그룹의 일부 구성원은 그 중 하나만 수신하기를 원할 수 있습니다. 특히 일부 수신기는 저해상도 비디오 구성 요소만 처리할 수 있습니다. 또는 여러 발신자가 동일한 그룹에 브로드캐스트하는 경우 수신자는 발신자 한 명 또는 그 중 일부만 선택할 수 있습니다. 마지막으로 다양한 수신자의 서비스 품질 요구 사항은 출력 장비, 프로세서 성능 및 채널 속도에 따라 다를 수 있습니다.

이러한 이유로 수신자에 의한 리소스 예약이 선호되는 것으로 보입니다. 발신자는 라우터에 트래픽의 일반적인 특성(예: 데이터 속도 및 가변성)을 제공할 수 있지만 수신자는 필요한 서비스 품질 수준을 결정해야 합니다. 그런 다음 라우터는 전파 트리의 공통 부분에서 리소스 할당 요청을 집계합니다.

RSVP는 데이터 흐름과 관련된 세 가지 개념인 세션, 흐름 사양 및 필터 사양을 기반으로 합니다. 세션대상으로 식별되는 데이터 스트림입니다. RSVP 및 RTP 세션이 일대일 대응을 가질 수 있지만 이 개념은 RTP 세션의 개념과 다릅니다. 라우터는 특정 대상에 대한 리소스를 예약한 후 이를 세션의 시작으로 취급하고 해당 세션 기간 동안 리소스를 할당합니다.

흐름 설명자라고 하는 목적지 종단 시스템의 예약 요청은 흐름 사양과 필터로 구성됩니다. 흐름 사양필요한 서비스 품질을 정의하고 노드가 패킷 스케줄러의 매개변수를 설정하는 데 사용합니다. 라우터는 현재 흐름 사양에 따라 주어진 기본 설정 집합으로 패킷을 전송합니다.

필터 사양리소스가 요청되는 패키지 세트를 정의합니다. 세션과 함께 필요한 서비스 품질이 제공될 패킷(또는 흐름) 집합을 정의합니다. 해당 목적지로 향하는 다른 패킷은 네트워크가 처리할 수 있는 한 처리됩니다.

RSVP는 흐름 사양의 내용을 정의하지 않고 단순히 요청을 전달합니다. 흐름 사양에는 일반적으로 서비스 클래스, Rspec(R은 예약을 나타냄) 및 Tspec(T는 트래픽을 나타냄)이 포함됩니다. 다른 두 매개변수는 숫자 세트입니다. Rspec 매개변수는 필요한 서비스 품질을 정의하고 Tspec 매개변수는 데이터 흐름을 설명합니다. Rspec 및 Tspec의 내용은 RSVP에 투명합니다.

원칙적으로 필터 사양은 단일 세션(즉, 해당 세션에 의해 목적지가 결정되는 패킷)의 임의의 패킷 하위 집합을 설명합니다. 예를 들어 필터 사양은 특정 발신자만 정의하거나 프로토콜 헤더 필드가 지정된 것과 일치하는 프로토콜 또는 패킷을 정의할 수 있습니다.

쌀. 도 3은 세션, 플로우 사양 및 필터 사양 간의 관계를 예시한다. 들어오는 각 패킷은 적어도 하나의 세션에 속하며 해당 세션의 논리적 흐름에 따라 고려됩니다. 패킷이 세션에 속하지 않으면 여유 리소스가 있는 한 전달됩니다.

RSVP의 주요 어려움은 멀티캐스팅과 관련이 있습니다. 멀티캐스트 구성의 예가 그림 1에 나와 있습니다. 6. 이 구성은 4개의 라우터로 구성됩니다. 선으로 표시되는 두 라우터 간의 링크는 직접 링크 또는 서브넷이 될 수 있습니다. 3개의 호스트(G1, G2 및 G3)는 동일한 그룹에 있으며 해당 멀티캐스트 주소로 데이터그램을 수신합니다. 이 주소의 데이터는 S1과 S2의 두 호스트에 의해 전송됩니다. 빨간색 선은 S1 및 이 그룹의 라우팅 트리에 해당하고 파란색 선은 S2 및 이 그룹에 해당합니다. 화살표 선은 S1(빨간색)과 S2(파란색)의 패킷 방향을 나타냅니다.

그림은 네 개의 라우터 모두가 각 수신자의 리소스 예약을 알고 있어야 함을 보여줍니다. 따라서 리소스 할당 요청은 라우팅 트리를 통해 역방향으로 전파됩니다.

RSVP는 두 가지 주요 메시지 유형인 Resv와 Path를 사용합니다. Resv 메시지는 수신자에 의해 생성되고 트리 위로 전파되며, 각 노드는 가능한 경우 서로 다른 수신자의 패킷을 연결 및 재조립합니다. 이러한 메시지는 라우터가 해당 세션(멀티캐스트 주소)에 대한 리소스 예약 상태로 들어가도록 합니다. 결국 모든 결합된 Resv 메시지는 보내는 호스트에 도달합니다. 수신된 정보를 기반으로 첫 번째 홉에 대한 적절한 일정 제어 매개변수를 설정합니다.

쌀. 도 7은 Resv 메시지 스트림을 나타낸다. 참고: 메시지는 연결됩니다. 따라서 하나의 메시지만 결합된 배달 트리의 분기로 전송됩니다. 그러나 리소스 예약 기간을 연장하려면 이러한 메시지를 주기적으로 재전송해야 합니다.

경로 메시지는 역방향 경로 정보를 전파하는 데 사용됩니다. 모든 최신 멀티캐스트 라우팅 프로토콜은 전파 트리 형태(발신자에서 아래로)의 직접 경로만 지원합니다. 그러나 Resv 메시지는 모든 중간 라우터를 통해 모든 보내는 호스트로 다시 보내져야 합니다.

라우팅 프로토콜은 역방향 경로 정보를 제공하지 않으므로 경로 메시지에서 RSVP에 의해 전달됩니다. 발신자가 되고자 하는 모든 호스트는 그룹의 모든 구성원에게 경로 메시지를 보냅니다. 그 과정에서 각 라우터와 각 대상 호스트는 경로 상태에 들어가 이 발신자의 패킷이 패킷을 수신한 홉으로 전달되어야 함을 나타냅니다. 쌀. 도 5는 경로 패킷이 데이터 패킷과 동일한 경로를 통해 전송되는 것을 보여줍니다.

RSVP 프로토콜의 작동을 고려하십시오. 호스트의 관점에서 프로토콜의 작동은 다음 단계로 구성됩니다(이 순서의 처음 두 단계는 때때로 반대입니다).

  1. 수신자는 IGMP 메시지를 인접 라우터에 전송하여 멀티캐스트 그룹에 참여합니다.
  2. 잠재적인 발신자는 그룹의 주소로 메시지를 보냅니다.
  3. 받는 사람은 보낸 사람을 식별하는 경로 메시지를 받습니다.
  4. 이제 수신기가 반환 경로에 대한 정보를 얻었으므로 스트림 설명자와 함께 Resv 메시지를 보낼 수 있습니다.
  5. Resv 메시지는 네트워크를 통해 발신자에게 전송됩니다.
  6. 발신자가 데이터 전송을 시작합니다.
  7. 수신기는 데이터 패킷 수신을 시작합니다.

과거의 대용량 그래픽 작업 방법은 현대 시스템에 완전히 적합하지 않습니다. 새로운 도구 없이는 볼륨의 증가, 실시간 응용 프로그램 및 멀티캐스트의 확산으로 인해 증가하는 데이터 전송 수요를 충족할 수 없습니다. RTP 및 RSVP는 차세대 LAN을 위한 견고한 기반을 제공합니다.

이러한 프로토콜의 실제 응용 프로그램의 예로는 VoIP(Voice over IP) 모델이 있습니다. 이 모델은 H.232 표준에 설명되어 있고 IP 네트워크를 통한 오디오, 비디오 정보 및 데이터 전송을 제공하는 IP 네트워크를 통한 음성 전송입니다. . 이 경우 실시간 프로토콜인 RTP를 사용하여 연결을 설정하고 RSVP 프로토콜을 사용하여 네트워크 리소스를 예약합니다.

에 이번 장네트워크 및 전송 프로토콜에 의한 RTP 패킷 전송의 일부 측면이 고려됩니다. 다른 프로토콜의 사양에서 달리 지정하지 않는 한 패킷을 전송할 때 다음 기본 규칙이 적용됩니다.

RTP는 하위 계층 프로토콜에 의존하여 RTP 데이터 스트림과 RTCP 제어 정보를 분리합니다. UDP 및 유사한 프로토콜의 경우 RTP는 짝수 포트 번호를 사용하고 해당 RTCP 스트림은 1보다 큰 포트 번호를 사용합니다.

RTP 정보 패킷에는 길이 필드가 포함되어 있지 않으므로 RTP는 기본 프로토콜에 의존하여 길이 표시도 제공합니다. RTP 패킷의 최대 길이는 하위 계층 프로토콜에 의해서만 제한됩니다.

여러 RTP 프로토콜 패킷이 하나의 하위 계층 프로토콜 데이터 단위, 예를 들어 UDP 패킷에서 전송될 수 있습니다. 이것은 헤더 중복성을 줄이고 다른 스트림 간의 동기화를 단순화할 수 있습니다.

9. 프로토콜 상수 목록

이 섹션에는 RTP 프로토콜 사양에 정의된 상수 목록이 포함되어 있습니다.

RTP(PT - 페이로드 유형) 트래픽 유형 상수는 프로필에 정의됩니다. 그러나 마커 비트와 트래픽 유형 필드를 포함하는 RTP 헤더 옥텟은 RTP 패킷을 RTCP SR 및 RR 패킷과 구별하기 위해 예약된 값 200 및 201(십진수)을 포함하지 않아야 합니다. 하나의 마커 비트와 7비트 트래픽 유형 필드가 있는 표준 형식의 경우 이 제한은 트래픽 유형 72 및 73을 사용해서는 안 된다는 것을 의미합니다.

RTCP 패킷 유형의 값(표 1 참조)은 RTP 패킷과 비교할 때 RTCP 패킷 헤더의 정확성을 더 잘 제어하기 위해 200에서 204 사이에서 선택됩니다. RTCP 패킷 유형 필드가 RTP 헤더의 해당 옥텟과 비교될 때, 이 범위는 1의 마커 비트(일반적으로 정보 패킷의 경우가 아님)와 1의 표준 트래픽 유형 필드의 최상위 비트에 해당합니다. (정적으로 정의된 트래픽 유형은 일반적으로 최상위 자릿수가 0인 PT 값을 가집니다.) 이 범위는 또한 0과 255 값에서 더 멀리 선택되었습니다. 왜냐하면 전적으로 0 또는 1로 구성된 필드가 대부분 데이터의 특성이기 때문입니다.

다른 유형의 RTCP 패킷은 IANA 커뮤니티에서 정의합니다. 개발자는 실험 연구에 필요한 값을 등록한 다음 해당 값이 더 이상 필요하지 않을 때 등록을 취소할 수 있습니다.

SDES 패키지의 유효한 항목 유형은 표에 나와 있습니다. 2. 다른 SDES 항목 유형은 IANA 커뮤니티에서 할당합니다. 개발자는 실험 연구를 수행할 때 필요한 값을 등록한 다음 해당 값이 더 이상 필요하지 않을 때 등록을 취소할 수 있습니다.

10. 트래픽 프로필 및 형식에 대한 설명

위에서 언급했듯이(섹션 2 참조) 특정 애플리케이션에 대한 RTP 프로토콜에 대한 완전한 설명에는 프로필 설명과 트래픽 형식이라는 두 가지 유형의 추가 문서가 필요합니다.

RTP는 요구 사항이 크게 다른 여러 클래스의 애플리케이션에 사용할 수 있습니다. 다양한 프로필을 사용하면 이러한 요구 사항에 유연하게 적응할 수 있습니다( 참조). 일반적으로 응용 프로그램은 하나의 프로필만 사용하며 어떤 프로필이 어떤 프로필에 있는지 명시적으로 표시하지 않습니다. 이 순간사용 중, 아니요.

두 번째 유형의 선택적 문서인 트래픽 형식 사양은 특정 유형의 트래픽(예: H.261 인코딩 비디오)이 RTP에 따라 전송되어야 하는 방법을 정의합니다. 동일한 트래픽 형식이 여러 프로필에 사용될 수 있으므로 프로필과 독립적으로 정의될 수 있습니다. 프로필 문서는 이 형식을 PT 값과 일치시키는 역할만 합니다. .

프로필 설명은 다음 항목을 정의할 수 있지만 이 목록이 완전하지는 않습니다.

RTP 데이터 패킷의 헤더입니다. 토큰 비트와 트래픽 유형 필드를 포함하는 RTP 데이터 패킷 헤더의 옥텟은 예를 들어 더 많거나 적은 토큰 비트(섹션 3.3)를 제공하기 위해 다양한 요구 사항을 충족하기 위해 프로필에 따라 재정의될 수 있습니다.

트래픽 유형. 프로필은 일반적으로 트래픽 형식 집합(예: 미디어 인코딩 알고리즘)과 이러한 형식 및 PT 값의 기본 정적 매핑을 정의합니다. 일부 트래픽 형식은 개별 트래픽 형식 설명을 참조하여 정의할 수 있습니다. 정의된 각 유형의 트래픽에 대해 프로필은 사용할 필수 RTP 타임스탬프 클록 속도를 지정해야 합니다(섹션 3.1).

RTP 데이터 패킷 헤더 추가. 만약 추가적인 기능이내에 응용 클래스프로파일, 트래픽 유형에 관계없이 RTP 데이터 패킷의 고정 헤더에 추가 필드 첨부 가능 .

RTP 데이터 패킷 헤더 확장. RTP 데이터 패킷 헤더 확장 구조의 처음 16비트 내용은 이 메커니즘의 사용이 프로파일에 의해 허용되는 경우 지정되어야 합니다. .

RTCP 패킷 유형. 새로운 애플리케이션 클래스 특정 유형의 RTCP 패킷을 정의(및 IANA에 등록)할 수 있습니다.

RTCP 보고 간격. 프로파일은 RTCP 보고 간격을 계산하는 데 사용되는 값을 정의해야 합니다. RTCP 세션 대역폭 비율, 최소 보고 간격, 발신자와 수신자 간의 대역폭 분할.

SR/RR 패키지 확장. 가능한 경우 추가 정보정기적으로 전송되는 송신자 또는 수신자에 대해 RTCP SR 및 RR 패킷에 대해 확장 섹션을 정의할 수 있습니다.

SDES 사용. 프로파일은 전송되거나 제외될 RTCP SDES 항목에 대한 상대적 우선순위를 정의할 수 있습니다(섹션 4.2.2 참조). CNAME 절에 대한 대체 구문 또는 의미론(섹션 4.4.1) LOC 항목 형식(섹션 4.4.5) NOTE 절(섹션 4.4.7) 및 IANA에 등록될 새로운 SDES 절의 의미 및 사용.

안전. 프로필은 응용 프로그램이 사용해야 하는 보안 서비스 및 알고리즘을 정의하고 사용에 대한 제어를 제공할 수 있습니다(7절).

암호 키 일치. 프로필은 사용자가 입력한 암호가 암호화 키로 변환되는 방법을 결정할 수 있습니다.

기본 프로토콜. RTP 패킷의 전송에는 특정 기본 네트워크 또는 전송 계층 프로토콜의 사용이 필요할 수 있습니다.

운송 규정 준수. UDP 포트와 같이 섹션 8에 지정된 전송 계층 주소에 대한 RTP 및 RTCP의 표준 매핑이 정의될 수 있습니다.

캡슐화. RTP 패킷 형성은 여러 RTP 정보 패킷이 단일 기본 프로토콜 데이터 단위(섹션 8)에서 전송되도록 정의할 수 있습니다.

개발하는 각 응용 프로그램에는 새 프로필이 필요하지 않습니다. 새 프로필을 만드는 것보다 동일한 응용 프로그램 클래스 내에서 기존 프로필을 확장하는 것이 더 편리합니다. 이렇게 하면 각 응용 프로그램이 일반적으로 하나의 프로필에서만 실행되기 때문에 응용 프로그램이 더 쉽게 상호 작용할 수 있습니다. 추가 PT 값 또는 RTCP 패킷 유형을 정의하는 것과 같은 간단한 확장은 IANA에 등록하고 프로필 사양 또는 트래픽 형식 사양에 해당 설명을 게시하여 수행할 수 있습니다.

11. 최소한의 제어로 음성 및 화상 회의를 위한 RTP 프로필

RFC 1890은 그룹 오디오 또는 비디오 회의 내에서 RTP 버전 2 실시간 전송 프로토콜 및 관련 RTCP 제어 프로토콜을 사용하기 위한 프로필, 이른바 오디오 및 비디오 회의용 RTP 프로필(오디오 및 비디오 회의용 RTP 프로필)을 설명합니다. . 최소한의 제어). 이 프로필은 RTP 프로토콜 버전 2 사양(RFC 1889)에 지정되지 않은 RTP의 측면을 정의합니다. 최소 제어는 매개변수 협상 또는 구성원 제어에 대한 지원이 필요하지 않음을 의미합니다(예: RTCP에서 제공하는 정적 트래픽 유형 매핑 및 구성원 표시 사용). 주요 조항을 고려하십시오 이 프로필.

11.1. RTP 및 RTCP 패킷 형식 및 프로토콜 매개변수

이 섹션에는 프로필에서 정의하거나 수정할 수 있는 여러 항목에 대한 설명이 포함되어 있습니다.

RTP 정보 패킷의 헤더입니다. RTP 정보 패킷의 표준 고정 헤더 형식(1비트 마커)이 사용됩니다.

트래픽 유형. 트래픽 유형에 대한 정적 값은 섹션 11.3 및 11.4에 정의되어 있습니다.

RTP 정보 패킷 헤더 확장. 추가 고정 필드는 RTP 정보 패킷 헤더에 첨부되지 않습니다.

RTP 정보 패킷 헤더 확장. RTP 정보 패킷 헤더 확장은 정의되어 있지 않지만 이 프로필을 사용하는 응용 프로그램은 이러한 확장을 사용할 수 있습니다(MAY). 즉, 애플리케이션은 RTP 헤더의 X 비트가 항상 0이라고 가정해서는 안 됩니다. 애플리케이션은 헤더 확장을 무시할 준비가 되어 있어야 합니다. 헤더 확장이 미래에 정의되면 처음 16비트의 내용을 지정해야 여러 확장을 식별할 수 있습니다.

RTCP 패킷 유형. 이 프로필 사양에는 추가 RTCP 패킷 유형이 정의되어 있지 않습니다.

RTCP 보고 간격. RTCP 보고 간격을 계산할 때 RFC 1889에서 제안하는 상수를 사용해야 합니다.

SR/RR 패키지 확장. RTCP SR 및 RR 패킷에 대한 확장은 정의되어 있지 않습니다.

SDES 사용. 애플리케이션은 설명된 SDES 절을 사용할 수 있습니다. 표준 이름(CNAME) 정보는 보고 간격마다 전송되지만 다른 항목은 5번째 보고 간격마다 전송되기만 하면 됩니다.

안전. 기본 RTP 보안 서비스도 이 프로필에 의해 기본적으로 정의됩니다.

암호 키 일치. 사용자가 입력한 암호는 MD5 알고리즘을 사용하여 16옥텟 요약으로 변환됩니다. N 비트 키는 첫 번째 N 비트를 사용하여 다이제스트에서 얻습니다. 비밀번호는 전화, 팩스, 텔렉스 또는 이메일로 비밀번호를 전송할 때 손상될 가능성을 줄이기 위해 ASCII 문자, 숫자, 하이픈 및 공백만 포함하도록 되어 있습니다. 암호 앞에는 암호화 알고리즘 사양이 올 수 있습니다. 첫 번째 슬래시(ASCII 코드 0x2f)까지의 모든 문자는 암호화 알고리즘의 이름으로 사용됩니다. 슬래시가 없으면 기본 암호화 알고리즘은 DES-CBC입니다.

사용자가 입력한 암호는 종료 알고리즘이 적용되기 전에 정식 형식으로 변환됩니다. 이를 위해 비밀번호는 ISO/IEC 10646-1:1993의 부록 P에 정의된 UTF-8 인코딩을 사용하여 ISO 10646 문자 세트로 변환됩니다(ASCII 문자는 변환이 필요하지 않음). 암호의 시작과 끝에서 공백이 제거됩니다. 둘 이상의 공백은 하나의 공백으로 대체됩니다(ASCII 또는 UTF-8 0x20). 모든 문자는 소문자로 변환

기본 프로토콜. 프로필은 양방향 및 멀티캐스트 모드에서 UDP를 통한 RTP 사용을 정의합니다.

운송 규정 준수. 전송 계층 주소에 대한 RTP 및 RTCP의 표준 매핑이 사용됩니다.

캡슐화. RTP 패킷의 캡슐화는 정의되지 않습니다.

11.2. 트래픽 유형 등록

이 프로필은 RTP와 함께 사용되는 표준 인코딩 유형을 정의합니다. 다른 인코딩 유형은 사용하기 전에 IANA에 등록해야 합니다. 새로운 코딩 유형을 등록할 때 다음 정보를 제공해야 합니다.

  • 코딩 유형 규칙 이름 및 RTP 타임스탬프 클록 속도(일반적인 이름은 필요한 경우 간결한 표현을 제공하기 위해 3자 또는 4자여야 함)
  • 인코딩 유형을 변경할 수 있는 권한이 있는 사람 표시(예: ISO, CCITT/ITU, 기타 국제 표준 기구, 컨소시엄, 특정 회사 또는 회사 그룹)
  • 모든 작동 매개변수;
  • 링크 사용 가능한 설명인코딩 알고리즘, 예: (선호도 순으로) RFC, 출판된 기사, 특허 등록, 기술 보고서, 코덱 소스 코드 또는 참조;
  • 개인 인코딩 유형의 경우 연락처 정보(우편 주소 및 이메일 주소);
  • 필요한 경우 이 프로필의 트래픽 유형을 나타내는 값입니다(아래 참조).
  • RTP와 함께 사용할 모든 인코딩 유형을 정적으로 할당할 필요는 없습니다. 96~127 범위의 PT(Traffic Type) 값과 인코딩 유형 간의 동적 매핑을 설정하려면 이 문서에서 다루지 않는 "비 RTP 수단"을 사용할 수 있습니다.
  • 트래픽 유형에 사용 가능한 값 공간은 매우 작습니다. 다음 조건이 충족되는 경우에만 새 트래픽 유형이 정적으로(영구적으로) 할당됩니다.
  • 코딩은 인터넷 커뮤니티에 큰 관심거리입니다.
  • 기존 인코딩에 필적하는 이점을 제공하거나 기존의 널리 사용되는 회의 또는 멀티미디어 시스템과의 상호 운용성을 위해 필요합니다.
  • 설명은 디코더를 만들기에 충분합니다.

11.3. 오디오 코딩

일시 중지 중에 패킷을 보내지 않는 응용 프로그램의 경우 RTP 정보 패킷의 헤더에 있는 마커 비트를 1로 설정하여 활성 음성의 첫 번째 버스트(일시 중지 후 첫 번째 패킷)를 구별합니다. 무음 억제가 없는 응용 프로그램은 이 비트를 0으로 설정합니다.

RTP 타임스탬프를 생성할 때 사용되는 RTP 클럭은 채널 수 및 코딩 유형과 무관합니다. 초당 샘플링 기간의 수와 같습니다. N 채널 코딩(스테레오, 쿼드 등)의 경우 각 샘플링 주기(예: 1/8000초)는 N 샘플을 생성합니다. 총 수초당 생성되는 샘플 수는 샘플 속도와 채널 수의 곱과 같습니다.

여러 개 사용할 때 사운드 채널첫 번째부터 시작하여 왼쪽에서 오른쪽으로 번호가 매겨집니다. RTP 오디오 패킷에서 번호가 낮은 채널의 데이터는 번호가 높은 채널의 데이터보다 우선합니다. 2개 이상의 채널에 대해 다음 표기법이 사용됩니다.

  • 내가 - 왼쪽;
  • r - 오른쪽;
  • c - 중앙;
  • S - 주변 장치;
  • F - 정면;
  • R-뒤로.
채널 수 시스템 이름 채널 번호
1 2 3 4 5 6
2 스테레오 엘 아르 자형
3 엘 아르 자형 씨
4 쿼드 플로리다 정말로 Rl 르르
4 엘 씨 아르 자형 에스
5 플로리다 정말로 Fc 슬 시니어
6 엘 액정 씨 아르 자형 rc 에스

동일한 샘플링 순간에 속하는 모든 채널의 샘플은 동일한 패킷 내에 있어야 합니다. 다른 채널의 샘플 인터리빙은 코딩 유형에 따라 다릅니다.

샘플 속도는 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000Hz 중에서 선택해야 합니다. 20ms 프레임에서 4개 또는 2개의 샘플을 건너뛰어 품질). 그러나 대부분의 오디오 코딩 알고리즘은 보다 제한된 샘플 레이트 세트에 대해 정의됩니다. 수신기는 다중 채널 오디오를 수신할 준비가 되어 있어야 하지만 모노를 선택할 수도 있습니다.

포장용 소리 신호, 인코딩 설명에 달리 지정되지 않는 한 기본 패킷화 간격은 20ms입니다. 패킷화 간격은 최소 종단 간 지연을 정의합니다. 더 긴 패킷에서 헤더에 할당되는 바이트의 비율은 상대적으로 적지만 큰 지연패킷 손실을 더 중요하게 만듭니다. 상당한 대역폭 제약이 있는 강의 또는 채널과 같은 비대화형 응용 프로그램의 경우 더 높은 패킷화 지연이 허용될 수 있습니다. 수신자는 0 ~ 200ms의 지연으로 사운드 신호가 포함된 패킷을 수신해야 합니다. 이 제한은 수신기에 대해 허용 가능한 버퍼 크기를 보장합니다.

샘플 기반 인코딩에서 각 신호 샘플은 고정된 비트 수로 표시됩니다. 압축된 오디오 데이터 내에서 개별 샘플 코드는 옥텟 경계를 넘을 수 있습니다. 오디오 패킷에서 전송되는 신호의 지속 시간은 패킷의 샘플 수에 의해 결정됩니다.

샘플당 하나 이상의 옥텟을 생성하는 샘플 기반 인코딩 유형의 경우 동시에 샘플링된 다른 채널의 샘플은 인접한 옥텟으로 패킹됩니다. 예를 들어, 스테레오 인코딩의 경우 옥텟 시퀀스는 왼쪽 채널, 첫 ​​번째 샘플입니다. 오른쪽 채널, 첫 ​​번째 카운트; 왼쪽 채널, 두 번째 카운트; 오른쪽 채널, 두 번째 샘플 등 다중 옥텟 인코딩에서는 최상위 옥텟이 먼저 전송됩니다. 샘플당 1옥텟 미만을 생성하는 샘플 기반 인코딩의 패킹은 인코딩 알고리즘에 의해 결정됩니다.

프레임 기반 코딩 알고리즘은 고정 길이 오디오 블록을 일반적으로 고정 길이의 다른 압축 데이터 블록으로 변환합니다. 프레임 기반 인코딩의 경우 발신자는 이러한 여러 프레임을 단일 메시지로 결합할 수 있습니다.

프레임 기반 코덱의 경우 전체 블록에 대해 채널 순서가 정의됩니다. 즉, 스테레오 오디오의 경우 왼쪽 및 오른쪽 채널의 샘플이 독립적으로 인코딩됩니다. 제1항에 있어서, 상기 좌측 채널에 대한 코딩 프레임은 상기 우측 채널에 대한 프레임보다 선행하는 것을 특징으로 하는 방법.

모든 프레임 지향 오디오 코덱은 단일 패킷 내에서 전송되는 여러 연속 프레임을 인코딩 및 디코딩할 수 있어야 합니다. 프레임 지향 코덱의 경우 프레임 크기가 지정되어 있으므로 동일한 인코딩에 대해 별도의 표기법을 사용할 필요가 없지만, 다른 번호패키지의 프레임입니다.

테이블에서. 3은 오디오 신호에 대한 이 프로필에 의해 정의된 트래픽 유형(PT)의 값을 보여줍니다. 관습그리고 메인 명세서코딩 알고리즘.

11.4. 비디오 인코딩

테이블에서. 도 4는 코딩 유형(PT)의 값, 코딩 알고리즘의 기호 및 이 프로파일에 의해 정의된 비디오 코딩 알고리즘의 기술적 특성뿐만 아니라 할당되지 않은, 예약된 및 동적으로 할당된 PT 값을 보여줍니다.

96~127 범위의 트래픽 유형 값은 이 문서에서 다루지 않는 회의 제어 프로토콜을 통해 동적으로 결정할 수 있습니다. 예를 들어, 세션 디렉토리는 주어진 세션에 대해 트래픽 유형 96이 8000Hz에서 PCMU 코딩, 이중 채널을 나타내도록 지정할 수 있습니다. "reserved"로 표시된 트래픽 유형의 범위는 RTCP 및 RTP 프로토콜 패킷을 안정적으로 구별할 수 있도록 사용되지 않습니다. .

RTP 소스는 주어진 시간에 한 가지 유형의 트래픽만 방출합니다. 하나의 RTP 세션에서 서로 다른 유형의 트래픽을 인터리빙하는 것은 허용되지 않습니다. 여러 RTP 세션을 병렬로 사용하여 서로 다른 유형의 트래픽을 전달할 수 있습니다. 이 프로필에 정의된 트래픽 유형은 오디오 또는 비디오 중 하나를 참조하지만 둘 다 참조하지는 않습니다. 그러나 예를 들어 오디오 및 비디오를 결합하고 트래픽 형식에서 적절한 분리를 사용하여 결합된 트래픽 유형을 정의할 수 있습니다.

이 프로필을 사용하는 오디오 응용 프로그램은 최소한 트래픽 유형 0(PCMU) 및 5(DVI4)를 보내고 받을 수 있어야 합니다. 이것은 형식 협상 없이 상호 운용성을 허용합니다.

11.5. 포트 할당

RTP 프로토콜 설명에 정의된 바와 같이 RTP 데이터는 짝수번 UDP 포트로 전송되어야 하고, 해당 RTCP 패킷은 1보다 큰 포트 번호(홀수 번호)로 전송되어야 합니다.

이 프로필로 실행되는 응용 프로그램은 이러한 UDP 포트 쌍을 사용할 수 있습니다. 예를 들어, 한 쌍의 포트는 세션 관리 프로그램에 의해 무작위로 할당될 수 있습니다. 경우에 따라 이 프로필을 사용하는 여러 응용 프로그램이 동일한 호스트에서 올바르게 실행되어야 하고 일부 운영 체제에서는 여러 프로세스가 다른 멀티캐스트 주소를 가진 동일한 UDP 포트를 사용하는 것을 허용하지 않기 때문에 단일 고정 포트 번호 쌍을 지정할 수 없습니다.

그러나 기본 포트 번호는 5004 및 5005일 수 있습니다. 여러 프로필을 사용하는 응용 프로그램은 이 포트 쌍을 해당 프로필의 표시기로 선택할 수 있습니다. 그러나 응용 프로그램에서는 포트 쌍을 명시적으로 지정해야 할 수도 있습니다.

12. 사용되는 용어 및 약어 목록

  • ASCII(American Standard Code for Information Interchange)는 정보 교환을 위한 미국 표준 코드입니다. 표현을 위한 7자리 코드 문자 정보, 대부분의 컴퓨팅 시스템에서 일부 수정과 함께 사용
  • CBC(암호 블록 체인) - 암호화된 블록 체인, DES 데이터 암호화 표준 모드
  • CELP(코드 여기 선형 예측) - 코드 여기 선형 예측을 사용하는 오디오 코딩 유형
  • CNAME(표준 이름) - 표준 이름
  • CSRC(기여 소스) - 포함된 소스. RTP 믹서에서 생성된 결합된 스트림에 기여한 RTP 패킷 스트림의 소스입니다. 믹서는 이 패킷의 형성에 참여한 소스의 SSRC 식별자 목록을 RTP 패킷의 헤더에 삽입합니다. 이 목록을 CSRC 목록이라고 합니다. 예: 믹서는 모든 사운드 패킷에 동일한 SSRC 식별자(예: 믹서로)
  • DES(데이터 암호화 표준) - 데이터 암호화 표준
  • IANA(Internet Assigned Numbers Authority) - 인터넷 할당 번호 기관
  • IMA(Interactive Multimedia Association) - 양방향 멀티미디어 협회
  • IP(인터넷 프로토콜) - 인터넷 프로토콜, 네트워크 계층 프로토콜, 데이터그램 프로토콜. 패킷이 목적지로 가는 도중에 여러 네트워크를 통과할 수 있습니다.
  • IPM(IP 멀티캐스트) - IP 프로토콜을 사용하는 멀티캐스트
  • LD-CELP(저지연 코드 여기 선형 예측) - 낮은 지연의 코드 여기 선형 예측을 사용하는 음성 코딩 알고리즘
  • LPC(선형 예측 인코딩) - 선형 예측 코딩
  • NTP(네트워크 시간 프로토콜) - 네트워크 시간 프로토콜은 1900년 1월 1일의 0시간을 기준으로 한 초 단위 카운트다운입니다. 전체 NTP 타임스탬프 형식은 다음을 포함하는 부호 없는 64비트 숫자입니다. 고정 소수점처음 32비트에는 정수 부분이 있고 마지막 32비트에는 소수 부분이 있습니다. 일부 경우에는 전체 형식에서 중간 32비트만 가져오는 보다 간결한 표현이 사용됩니다. 정수 부분의 하위 16비트와 소수 부분의 상위 16비트
  • RPE/LTP ​​​​(잔여 펄스 여기/장기 예측) - 차동 펄스 여기 및 장기 예측을 사용한 음성 신호 코딩 알고리즘
  • RTCP(실시간 제어 프로토콜) - 실시간 통신 제어 프로토콜
  • RTP(실시간 전송 프로토콜) - 실시간 전송 프로토콜
  • SSRC(동기화 소스) - 동기화 소스. 네트워크 주소에 관계없이 RTP 헤더에 포함된 32비트 숫자 SSRC 식별자로 식별되는 RTP 패킷 스트림의 소스입니다. 동일한 타이밍 소스를 가진 모든 패킷은 동일한 타이밍 간격과 동일한 시퀀스 번호 공간을 사용하므로 수신기는 타이밍 소스를 사용하여 재생하기 위해 패킷을 그룹화합니다. 클록 소스 예: 마이크, 비디오 카메라 또는 RTP 믹서와 같은 신호 소스에서 수신된 패킷 스트림의 발신자. 클록 소스는 오디오 코딩과 같이 시간이 지남에 따라 데이터 형식을 변경할 수 있습니다. SSRC ID는 특정 RTP 세션 내에서 전역적으로 고유한 것으로 간주되는 무작위로 선택된 값입니다. 원격 회의 참가자는 멀티미디어 세션의 모든 RTP 세션에 대해 동일한 SSRC 식별자를 사용할 필요가 없습니다. SSRC ID 집계는 RTCP 프로토콜을 통해 제공됩니다. 참가자가 단일 RTP 세션에서 여러 스트림을 생성하는 경우(예: 여러 카메라에서) 각 스트림은 별도의 SSRC로 식별되어야 합니다.
  • TCP(Transmission Control Protocol)는 IP 프로토콜과 함께 사용되는 전송 계층 프로토콜입니다.
  • UDP(User Datagram Protocol)는 논리적 연결을 설정하지 않는 전송 계층 프로토콜입니다. UDP는 네트워크에 있는 하나 이상의 스테이션으로 패킷을 보내는 데만 제공됩니다. 데이터 전송의 정확성 확인 및 무결성 보장(확실한 전달)이 상위 수준에서 수행됩니다.
  • ADPCM - 적응형 차동 펄스 코드 변조
  • 지터(지터) - 지터, 신호의 위상 또는 주파수 편차. IP 텔레포니 관련 - 네트워크의 데이터그램 지연 불규칙성
  • ZPD - 데이터 전송 링크(상호작용의 참조 모델의 두 번째 수준 개방형 시스템)
  • IVS - 정보 및 컴퓨팅 네트워크
  • 믹서(믹서) - 하나 이상의 소스에서 RTP 패킷을 수신하고 데이터 형식을 변경하고 패킷을 다음으로 결합하는 중간 시스템 새 패키지 RTP 후 전송합니다. 여러 신호 소스가 일반적으로 동기화되지 않기 때문에 믹서는 구성 요소 스트림의 타이밍을 수정하고 결합된 스트림에 대한 자체 타이밍을 생성합니다. 따라서 믹서에 의해 생성된 모든 데이터 패킷은 믹서를 클럭 소스로 갖는 것으로 식별됩니다.
  • 모니터(모니터) - RTP 세션 참가자가 보낸 RTCP 패킷, 특히 수신 보고를 수신하고 배포 제어, 오류 감지 및 장기 통계를 위해 현재 서비스 품질을 평가하는 응용 프로그램입니다. 일반적으로 모니터의 기능은 세션에서 사용되는 응용 프로그램과 함께 있지만 모니터는 RTP 정보 패킷을 보내거나 받는 다른 방법으로 사용되지 않는 별도의 응용 프로그램일 수도 있습니다. 이러한 응용 프로그램을 타사 모니터라고 합니다.
  • ITU-T - 국제 전기 통신 연합의 통신 표준화 부문
  • 종단 시스템 - RTP 패킷으로 전송된 콘텐츠를 생성하고/하거나 수신된 RTP 패킷의 콘텐츠를 소비하는 응용 프로그램입니다. 종단 시스템은 각 RTP 세션에서 하나 이상의(일반적으로 하나만) 클록 소스로 작동할 수 있습니다.
  • RTCP 패킷 - RTP 프로토콜의 정보 패킷 헤더와 유사한 고정 헤더 부분과 RTCP 패킷 유형에 따라 변경되는 구조적 요소로 구성된 제어 패킷입니다. 일반적으로 다중 RTCP 패킷은 단일 기본 프로토콜 패킷의 다중 RTCP 패킷으로 함께 전송됩니다. 이것은 각 RTCP 패킷의 고정 헤더에 있는 길이 필드에 의해 제공됩니다.
  • RTP 패킷 - 고정된 RTP 헤더, 포함할 빈 소스 목록, 확장 및 트래픽으로 구성된 프로토콜 데이터 단위입니다. 일반적으로 하나의 기본 프로토콜 패킷에는 하나의 RTP 패킷이 포함되지만 여러 개 있을 수 있습니다.
  • 포트는 단일 호스트 컴퓨터 내에서 여러 대상을 구별하기 위해 전송 계층 프로토콜에서 사용하는 추상화입니다. 포트는 번호로 식별됩니다. 따라서 포트 번호는 전달된 데이터가 의도된 특정 응용 프로그램을 식별하는 번호입니다. 이 번호는 상위 계층에서 사용되는 프로토콜(예: TCP 또는 UDP)에 대한 정보와 함께 인터넷을 통해 전송되는 데이터그램의 다른 서비스 정보 중 포함됩니다. 전송에서 사용하는 TSEL(전송 선택기) OSI 레이어, 포트와 동일
  • 프로필 (프로필) - 기능의 기능을 결정하는 응용 프로그램 클래스에 대한 RTP 및 RTCP 프로토콜 매개 변수 집합입니다. 프로파일은 RTP 데이터 패킷 헤더, 트래픽 유형, RTP 데이터 패킷 헤더 확장, RTP 데이터 패킷 헤더 확장의 처음 16비트, RTCP 패킷 유형, RTCP 보고 간격, SR에서 마커 비트 및 트래픽 유형 필드의 사용을 정의합니다. /RR 패킷 확장, 통신 보안 및 기본 프로토콜 사용 기능을 보장하기 위해 SDES 패킷, 서비스 및 알고리즘 사용
  • RTP 세션(RTP 세션) - RTP 프로토콜을 통해 상호 작용하는 여러 참가자의 통신입니다. 각 참가자에 대해 세션은 대상 전송 주소의 특정 쌍(네트워크 주소 1개와 RTP 및 RTCP용 포트 쌍)으로 정의됩니다. 목적지 전송 주소 쌍은 모든 참가자에게 공통적일 수 있거나(IPM의 경우와 같이) 각각에 대해 다를 수 있습니다(양방향 통신에서와 같이 개별 네트워크 주소 및 공통 포트 쌍). 멀티미디어 세션에서 각 유형의 트래픽은 자체 RTCP 패킷이 있는 별도의 RTP 세션에서 전달됩니다. 멀티캐스트 RTP 세션은 다른 포트 쌍 번호 및/또는 다른 멀티캐스트 주소로 구별됩니다.
  • 비 RTP 수단 - 수용 가능한 서비스를 제공하기 위해 RTP에 추가로 필요할 수 있는 프로토콜 및 메커니즘. 특히 멀티미디어 회의의 경우 회의 제어 응용 프로그램은 멀티캐스트 주소와 암호화 키를 배포하고 사용할 암호화 알고리즘을 협상하며 RTP 트래픽 유형 값과 이러한 값이 나타내는 트래픽 형식(미리 정의된 형식이 없는 형식) 간의 동적 매핑을 결정할 수 있습니다. 값). 트래픽 유형). 을 위한 간단한 응용 프로그램도 사용할 수 있습니다 이메일또는 회의 데이터베이스
  • 변환기(변환기) - 동기화 소스의 식별자를 변경하지 않고 RTP 패킷을 전달하는 중간 시스템. 변환기의 예: 혼합 없이 트랜스코딩하는 장치, 다방향 또는 양방향 리플리케이터, 방화벽의 응용 프로그램 계층 응용 프로그램
  • 전송 주소 - IP 주소 및 UDP 포트 번호와 같이 전송 끝점을 식별하는 네트워크 주소와 포트 번호의 조합입니다. 패킷은 소스 전송 주소에서 목적지 전송 주소로 전송됩니다.
  • RTP 트래픽 - 오디오 샘플 또는 압축된 비디오 데이터와 같은 RTP 프로토콜 패킷으로 전송되는 멀티미디어 데이터
  • PSTN - 공중 교환 전화 네트워크

RTP 프로토콜

멀티미디어 응용 프로그램의 주요 전송 프로토콜은 IP 네트워크를 통해 코딩된 음성 신호가 포함된 패킷 전송을 구성하도록 설계된 실시간 프로토콜 RTP(실시간 프로토콜)가 되었습니다. RTP 패킷의 전송은 UDP 프로토콜을 통해 수행되며 차례로 IP를 통해 작동합니다(그림 1.5.).

쌀. 1.5.

사실 RTP가 속하는 레벨은 그림 1과 같이 명확하게 정의되어 있지 않다. 1.5 그리고 일반적으로 문헌에 설명되어 있습니다. 한편으로 프로토콜은 실제로 UDP 위에서 작동하고 응용 프로그램에 의해 구현되며 모든 표시에 따르면 응용 프로토콜입니다. 그러나 동시에 이 단락의 시작 부분에서 언급한 바와 같이 RTP는 멀티미디어 응용 프로그램과 독립적으로 전송 서비스를 제공하며 이러한 관점에서 볼 때 단지 전송 프로토콜입니다. 최상의 정의: RTP는 응용 프로그램 계층에서 구현되는 전송 프로토콜입니다.

음성(멀티미디어) 트래픽을 전송하기 위해 RTP는 패킷을 사용하며 그 구조는 그림 1과 같습니다. 1.6.

RTP 패킷은 최소 12바이트로 구성됩니다. RTP 헤더의 처음 두 비트(버전 비트 필드, V)는 RTP 프로토콜(현재 버전 2)의 버전을 나타냅니다.

분명히, 이 헤더 구조를 사용하면 기껏해야 하나의 추가 RTP 버전만 가능합니다. 그 뒤에 오는 필드에는 두 개의 비트가 포함됩니다. P 비트는 페이로드 필드의 끝에 패딩 문자가 추가되었는지 여부를 나타냅니다(전송 프로토콜 또는 인코딩 알고리즘이 고정 크기 블록을 사용해야 하는 경우 일반적으로 추가됨). 및 확장 헤더가 사용 중인지 여부를 나타내는 X 비트.


쌀. 1.6.

사용되는 경우 확장 헤더의 첫 번째 단어에는 확장의 전체 길이가 포함됩니다. 또한, 4개의 CC 비트는 RTP 헤더의 끝에서 CSRC 필드의 수를 결정합니다. 흐름을 형성하는 소스의 수. 마커 비트 M을 사용하면 비디오 프레임의 시작, 오디오 채널의 단어 시작 등과 같이 표준이 중요한 이벤트로 정의하는 것을 표시할 수 있습니다. 그 다음에는 페이로드 유형 코드가 표시되는 PT 데이터 유형 필드(7비트)가 옵니다. 이 필드는 페이로드 필드의 내용을 결정합니다. 애플리케이션 데이터(Application Data), 예를 들어, 압축되지 않은 8비트 MP3 오디오 등입니다. 이 코드에서 애플리케이션은 데이터를 디코딩하기 위해 무엇을 해야 하는지 배울 수 있습니다. 고정 길이 헤더의 나머지 부분은 시퀀스 번호 필드, 패킷의 첫 번째 단어가 생성될 때 기록하는 타임 스탬프 필드, 이 소스를 식별하는 SSRC 타이밍 소스 필드로 구성됩니다. 마지막 필드는 네트워크 주소가 하나뿐인 단일 장치, 다른 미디어(오디오, 비디오 등)를 나타낼 수 있는 여러 소스 또는 동일한 미디어의 다른 스트림일 수 있습니다. 소스가 다른 장치에 있을 수 있으므로 SSRC 식별자는 무작위로 선택되므로 RTP 세션 동안 한 번에 두 소스에서 데이터를 수신할 가능성이 최소화됩니다. 그러나 갈등이 발생할 경우 이를 해결하기 위한 메커니즘도 정의되어 있습니다. RTP 헤더의 고정 부분 뒤에는 데이터 소스를 식별하는 최대 15개의 개별 32비트 CSRC 필드가 올 수 있습니다.

RTP는 RTP 세션에 대한 정보가 포함된 추가 보고서를 생성하는 RTCP(실시간 전송 제어 프로토콜)에서 지원됩니다. UDP나 RTP는 QoS(서비스 품질)를 제공하는 데 관여하지 않습니다. RTCP 프로토콜은 발신자에게 피드백을 제공하고 스트림 수신자에게 QoS 향상, 패킷 정보(손실, 지연, 지터) 및 사용자(응용 프로그램, 스트림)를 제공합니다. 흐름 제어의 경우 보낸 사람이 생성하는 보고서와 받는 사람이 생성하는 두 가지 유형의 보고서가 있습니다. 예를 들어, 손실된 패킷의 백분율과 손실의 절대 수에 대한 정보를 통해 보낸 사람은 보고를 받을 때 채널 정체로 인해 수신기가 예상한 패킷 스트림을 수신하지 못할 수 있음을 감지할 수 있습니다. 이 경우 발신자는 코딩 속도를 낮추어 혼잡을 줄이고 수신을 개선할 수 있는 옵션이 있습니다. 발신자 보고서에는 마지막 RTP 패킷이 생성된 시간에 대한 정보가 포함됩니다(내부 레이블 및 실시간). 이 정보를 통해 수신자는 비디오 및 오디오와 같은 여러 스트림을 조정하고 동기화할 수 있습니다. 스트림이 여러 수신자에게 전달되는 경우 각 수신자의 RTCP 패킷 스트림이 구성됩니다. 이것은 RTCP 보고서가 생성되는 속도와 수신자 수에 반비례하여 대역폭을 제한하는 조치를 취합니다.

RTCP는 RTP와 별도로 작동하지만 RTP/UDP/IP 체인 자체는 상당한 오버헤드(헤더 형태로)를 초래한다는 점에 유의해야 합니다. G.729 코덱은 10바이트(10ms마다 80비트)의 패킷을 생성합니다. 크기가 12바이트인 하나의 RTP 헤더는 이 전체 패킷보다 큽니다. 또한 8바이트 UDP 헤더와 20바이트 IP 헤더(IPv4에서)를 추가해야 하므로 전송 데이터 크기의 4배에 달하는 헤더가 생성됩니다.

현대 통신의 진화에서 가장 중요한 추세 중 하나는 IP 전화의 개발입니다. IP 전화는 정보 및 컴퓨터 네트워크(ICN)를 통해 멀티미디어 메시지(음성, 데이터, 비디오)의 전송을 제공하는 일련의 새로운 기술입니다. 로컬, 기업, 글로벌 컴퓨터 네트워크 및 인터넷을 포함하는 IP(인터넷 프로토콜) 프로토콜의 기반입니다. IP 텔레포니의 개념에는 인터넷 가입자 간, 가입자 간 전화 통신을 구성할 수 있는 인터넷 전화가 포함됩니다. 전화 네트워크인터넷을 통한 일반 사용(PSTN)은 물론 PSTN과 인터넷 가입자 간의 전화 통신입니다.

IP 텔레포니는 컴퓨터 텔레포니 시장의 급속한 발전과 확장을 보장하는 부인할 수 없는 많은 이점을 가지고 있습니다. 상당히 낮은 분당 요금으로 전화 통신이 제공되는 최종 사용자에게 유용합니다. 원격 지점이 있는 회사의 경우 IP 기술을 사용하면 기존 회사 IP 네트워크를 사용하여 음성 통신을 구성할 수 있습니다. 여러 통신 네트워크 대신 하나가 사용됩니다. 일반 전화에 비해 IP 전화 통신의 확실한 장점은 추가적인 서비스멀티미디어 컴퓨터와 다양한 인터넷 응용 프로그램의 사용을 통해. 따라서 기업과 개인은 IP 텔레포니를 통해 고급 화상 회의, 응용 프로그램 공유, 화이트보드 유형 도구 등을 통합하여 통신 기능을 확장할 수 있습니다.

하드웨어 작동을 위한 주요 매개변수와 알고리즘을 규제하는 국제 표준 및 프로토콜 소프트웨어 도구 IP 전화에 사용되는 연결? 분명히 이름에서 알 수 있듯이 이 기술은 IP 프로토콜을 기반으로 하지만 전화 통신에만 사용되는 것이 아니라 원래 디지털 데이터를 패킷 전환 IVS로 전송하기 위해 개발되었습니다.

보장된 서비스 품질을 제공하지 않는 네트워크(IP 프로토콜 기반으로 구축된 네트워크 포함)에서는 패킷이 손실될 수 있고 도착 순서가 변경될 수 있으며 패킷으로 전송된 데이터가 왜곡될 수 있습니다. 이러한 조건에서 전송된 정보의 안정적인 전달을 보장하기 위해 다양한 전송 계층 절차가 사용됩니다. 디지털 데이터를 전송할 때 이를 위해 TCP 프로토콜(Transmission Control Protocol)이 사용됩니다. 이 프로토콜은 안정적인 데이터 전달을 제공하고 원래 패킷 순서를 복원합니다. 패킷에서 오류가 감지되거나 패킷이 손실되면 TCP 절차는 재전송 요청을 보냅니다.

오디오 및 비디오 회의 애플리케이션의 경우 패킷 지연이 개별 데이터 왜곡보다 신호 품질에 훨씬 더 큰 영향을 미칩니다. 지연의 차이는 격차로 이어질 수 있습니다. 이러한 애플리케이션에는 패킷 재배열, 최소 지연으로 전달, 정확하게 지정된 순간에 실시간 재생, 트래픽 유형 인식, 멀티캐스트 또는 양방향 통신을 제공하는 다른 전송 계층 프로토콜이 필요합니다. 이러한 프로토콜이 실시간 전송 프로토콜인 RTP(Real-Time Transport Protocol)입니다. 이 프로토콜은 전송 수준에서 IVS를 통한 패킷의 멀티미디어 데이터 전송을 규제하고 실시간 데이터 전송 제어 프로토콜 RTCP(실시간 제어 프로토콜)로 보완됩니다. RTCP 프로토콜은 차례로 멀티미디어 데이터 전달, 서비스 품질 제어, 현재 통신 세션의 참가자에 대한 정보 전송, 제어 및 식별에 대한 제어를 제공하며 때때로 RTP 프로토콜의 일부로 간주됩니다.

IP 텔레포니에 관한 많은 간행물에 따르면 대부분의 네트워크 장비와 특수 소프트웨어이 기술은 ITU-T(International Telecommunication Union)의 통신 표준화 부문(TAPI 3.0, NetMeeting 2.0 등 포함)의 Recommendation H.323을 기반으로 개발되었습니다. H.323은 RTP 및 RTCP와 어떤 관련이 있습니까? H.323은 정보 전송의 다양한 측면을 각각 처리하는 다른 많은 표준을 포함하는 광범위한 개념적 프레임워크입니다. 오디오 및 비디오 코덱 표준과 같은 이러한 표준의 대부분은 IP 텔레포니뿐만 아니라 널리 사용됩니다. RTP / RTCP 프로토콜은 H.323 표준의 기반을 형성하고 정확한 IP 기술을 제공하는 데 중점을 두고 있으며 IP 텔레포니 조직의 기반이 됩니다. 이 문서에서는 이러한 프로토콜을 고려합니다.

2. 기본 개념

RTP 실시간 전송 프로토콜은 양방향 오디오 및 비디오와 같은 멀티미디어 데이터의 종단 간 실시간 전송을 제공합니다. 이 프로토콜은 트래픽 유형 인식, 패킷 시퀀스 번호 지정, 타임스탬프및 전송 제어.

RTP 프로토콜의 동작은 각 나가는 패킷에 타임스탬프를 할당하는 것으로 축소됩니다. 수신 측에서 패킷 타임스탬프는 재생해야 하는 순서와 지연 시간을 나타냅니다. RTP 및 RTCP 지원을 통해 수신 호스트는 수신된 패킷을 적절한 순서로 정렬하고 패킷 지연 리플이 신호 품질에 미치는 영향을 줄이며 오디오와 비디오 간의 동기화를 복원하여 들어오는 정보를 올바르게 듣고 볼 수 있습니다. 사용자.

RTP 자체에는 적시 데이터 전송 및 서비스 품질을 보장하는 메커니즘이 없지만 이를 보장하기 위해 기본 서비스를 사용합니다. 순서가 잘못된 패킷을 방지하지는 않지만 기본 네트워크가 절대적으로 신뢰할 수 있고 올바른 순서로 패킷을 전송한다고 가정하지 않습니다. RTP에 포함된 시퀀스 번호를 사용하면 수신자가 발신자의 패킷을 다시 시퀀싱할 수 있습니다.

RTP 프로토콜은 기본 네트워크에서 멀티캐스트를 지원하는 경우 양방향 통신과 대상 그룹으로의 데이터 전송을 모두 지원합니다. RTP는 개별 애플리케이션에 필요한 정보를 제공하기 위한 것으로 대부분의 경우 애플리케이션의 운영에 통합됩니다.

RTP는 전송 계층 프로토콜로 간주되지만 일반적으로 다른 전송 계층 프로토콜인 UDP(User Datagram Protocol) 위에서 작동합니다. 두 프로토콜 모두 전송 계층의 기능에 기여합니다. RTP 및 RTCP는 기본 전송 및 네트워크 계층과 독립적이므로 RTP/RTCP 프로토콜을 다른 적절한 전송 프로토콜과 함께 사용할 수 있습니다.

RTP/RTCP 프로토콜 데이터 단위를 패킷이라고 합니다. RTP 프로토콜에 따라 생성되어 멀티미디어 데이터를 전송하는 데 사용되는 패킷을 정보 패킷 또는 데이터 패킷(데이터 패킷)이라고 하며, RTCP 프로토콜에 따라 생성되어 원격 회의의 안정적인 운영에 필요한 서비스 정보를 전송하는 데 사용되는 패킷은 패킷이라고 하는 제어 또는 서비스 패킷(제어 패킷). RTP 패킷은 고정 헤더, 선택적 가변 길이 헤더 확장 및 데이터 필드를 포함합니다. RTCP 패킷은 고정 부분(RTP 정보 패킷의 고정 부분과 유사)으로 시작하여 가변 길이 빌딩 블록이 뒤따릅니다.

RTP 프로토콜이 보다 유연하고 다양한 애플리케이션에 적용 가능하도록 하기 위해 일부 매개변수는 의도적으로 정의되지 않았지만 프로파일 개념을 제공합니다. 프로필(프로필)은 기능의 기능을 결정하는 특정 클래스의 응용 프로그램에 대한 RTP 및 RTCP 프로토콜에 대한 매개 변수 집합입니다. 프로파일은 개별 패킷 헤더 필드, 트래픽 유형, 헤더 추가 및 헤더 확장, 패킷 유형, 통신 보안 서비스 및 알고리즘, 기본 프로토콜 사용 기능 등의 사용을 정의합니다. 최소한의 제어로 오디오 및 화상 회의를 위한 RTP 프로파일 ). 각 응용 프로그램은 일반적으로 하나의 프로필에서만 작동하며 프로필 유형 설정은 적절한 응용 프로그램을 선택하여 수행됩니다. 포트 번호, 프로토콜 식별자 등으로 프로필 유형을 명시적으로 표시하지 않습니다. 제공되지 않습니다.

따라서 특정 애플리케이션에 대한 완전한 RTP 사양에는 프로필 설명과 오디오 또는 비디오와 같은 특정 유형의 트래픽이 RTP에서 처리되는 방식을 정의하는 트래픽 형식 설명이 포함된 추가 문서가 포함되어야 합니다.

오디오 및 비디오 회의 중 멀티미디어 데이터 전송 기능은 다음 섹션에서 설명합니다.

2.1. 그룹 오디오 회의

그룹 오디오 회의에는 다중 사용자 그룹 주소와 2개의 포트가 필요합니다. 이 경우 하나의 포트는 오디오 데이터 교환을 위해 필요하고 다른 하나는 RTCP 프로토콜의 제어 패킷에 사용됩니다. 그룹 주소 및 포트 정보는 원하는 원격 회의 참가자에게 전송됩니다. 개인 정보 보호가 필요한 경우 정보 및 제어 패킷이 섹션 7.1에 정의된 대로 암호화될 수 있으며 이 경우 암호화 키도 생성 및 배포되어야 합니다.

각 회의 참가자가 사용하는 오디오 회의 응용 프로그램은 20ms와 같은 작은 버스트로 오디오 데이터를 보냅니다. 오디오 데이터의 각 조각 앞에는 RTP 헤더가 옵니다. RTP 헤더와 데이터는 차례로 UDP 패킷으로 형성(캡슐화)됩니다. RTP 헤더는 패킷의 데이터를 형성하는 데 사용된 오디오 코딩 유형(예: PCM, ADPCM 또는 LPC)을 나타냅니다. 이렇게 하면 예를 들어 낮은 대역폭 연결을 사용하는 새 참가자가 도착하거나 네트워크 정체가 발생한 경우와 같이 회의 ​​중에 코딩 유형을 변경할 수 있습니다.

다른 패킷 교환 데이터 네트워크와 마찬가지로 인터넷에서도 패킷이 손실 및 재정렬되는 경우가 있으며 여러 번 지연되기도 합니다. 이러한 이벤트에 대응하기 위해 RTP 헤더에는 예를 들어 오디오 신호의 일부가 20ms마다 스피커에서 계속 재생되도록 수신기가 재타이밍할 수 있도록 하는 타임스탬프와 시퀀스 번호가 포함되어 있습니다. 이 타이밍 재구성은 원격 회의에서 RTP 패킷의 각 소스에 대해 개별적으로 독립적으로 수행됩니다. 시퀀스 번호는 또한 수신기에서 손실된 패킷 수를 추정하는 데 사용할 수 있습니다.

다자간 전화회의 참가자는 진행 중인 다자간 통화에 참여하고 나갈 수 있으므로 현재 회의에 누가 있고 회의 참가자가 오디오 데이터를 얼마나 잘 수신하고 있는지 아는 것이 유용합니다. 이를 위해 회의 중 오디오 응용 프로그램의 각 인스턴스는 다른 모든 참가자의 응용 프로그램에 대한 제어 포트(RTCP 포트)에서 사용자 이름을 나타내는 패킷 수신 메시지를 주기적으로 발행합니다. 수신 메시지는 현재 화자가 얼마나 잘 들리는지 나타내며 적응형 인코더를 제어하는 ​​데 사용할 수 있습니다. 사용자 이름 외에 대역폭 제어를 위한 다른 식별 정보도 포함될 수 있습니다. 회의를 떠날 때 사이트는 RTCP BYE 패킷을 보냅니다.

2.2. 화상 회의

오디오 및 비디오 신호가 모두 원격 회의에서 사용되는 경우 별도로 전송됩니다. 각 유형의 트래픽 전송에 대해 서로 상관없이 프로토콜 사양은 RTP 세션의 개념을 도입합니다(사용된 약어 및 용어 목록 참조). 세션은 특정 목적지 전송 주소 쌍(하나의 네트워크 주소와 RTP 및 RTCP용 포트 쌍)으로 정의됩니다. 각 유형의 트래픽에 대한 패킷은 서로 다른 두 쌍의 UDP 포트 및/또는 멀티캐스트 주소를 사용하여 전송됩니다. 세션이 링크될 수 있도록 두 세션에 참여하는 사용자가 두 세션에 대한 RTCP 패킷에서 동일한 정식 이름을 사용해야 한다는 점을 제외하고 오디오 및 비디오 세션 사이에는 직접적인 RTP 계층 연결이 없습니다.

이러한 분리의 한 가지 이유는 일부 회의 참가자가 원하는 경우 한 가지 유형의 트래픽만 수신하도록 허용해야 하기 때문입니다. 분리에도 불구하고 소스 미디어 데이터(오디오 및 비디오)의 동기 재생은 두 세션에 대한 RTCP 패킷에 전달되는 타이밍 정보를 사용하여 달성할 수 있습니다.

2.3. 믹서와 번역기의 개념

항상 모든 사이트가 동일한 형식으로 멀티미디어 데이터를 수신할 수 있는 것은 아닙니다. 동일한 지역의 참가자가 광대역 네트워크 액세스 권한이 있는 대부분의 다른 회의 참가자에게 저속 링크를 통해 연결되는 경우를 고려하십시오. 모든 사람이 더 좁은 대역폭과 낮은 품질의 오디오 코딩을 사용하도록 강요하는 대신 믹서라고 하는 RTP 계층 통신 기능을 낮은 대역폭 영역에 배치할 수 있습니다. 이 믹서는 들어오는 오디오 패킷을 재동기화하여 원래의 20ms 간격을 복원하고 이러한 복원된 오디오 스트림을 단일 스트림으로 혼합하고 저대역폭 오디오 인코딩을 수행하고 패킷 스트림을 저속 링크를 통해 전송합니다. 이 경우 패킷은 한 수신자 또는 다른 주소를 가진 수신자 그룹으로 주소 지정될 수 있습니다. 수신 엔드포인트가 메시지 소스의 정확한 표시를 제공하기 위해 RTP 헤더에는 혼합 패킷의 형성에 관련된 소스를 식별하기 위한 수단이 혼합기가 포함되어 있습니다.

오디오 회의의 일부 참가자는 광대역 통신 회선으로 연결될 수 있지만 IP 멀티캐스트 그룹 회의(IPM)를 통해 연결되지 않을 수 있습니다. 예를 들어, IP 패킷 전송을 허용하지 않는 응용 프로그램 계층 방화벽 뒤에 있을 수 있습니다. 이러한 경우 믹서가 필요하지 않고 변환기라고 하는 다른 유형의 RTP 계층 통신이 필요합니다. 두 변환기 중 하나는 방화벽 외부에 설치되고 보안 연결을 통해 수신된 모든 멀티캐스트 패킷을 방화벽 뒤에 설치된 다른 변환기로 외부적으로 전달합니다. 방화벽 뒤에 있는 변환기는 다음으로 제한된 다중 사용자 그룹에 멀티캐스트 패킷으로 다시 브로드캐스트합니다. 내부 네트워크대지.

믹서와 변환기는 다양한 용도로 설계할 수 있습니다. 예: 개별 비디오 스트림에서 개인의 비디오 이미지를 확장하고 단일 비디오 스트림으로 합성하여 그룹 장면을 시뮬레이션하는 비디오 믹서. 브로드캐스트 예: IP/UDP 전용 호스트 그룹을 ST-II 전용 호스트 그룹에 연결하거나 리타이밍 또는 믹싱 없이 개별 소스의 패킷별로 비디오 패킷을 트랜스코딩합니다. 믹서와 번역기의 작동 방식에 대한 자세한 내용은 섹션 5에서 설명합니다.

2.4. 바이트 순서, 정렬 및 타임스탬프 형식

RTP/RTCP 패킷의 모든 필드는 바이트(옥텟) 단위로 네트워크를 통해 전송됩니다. 최상위 바이트가 먼저 전송됩니다. 모든 헤더 필드 데이터는 길이에 따라 정렬됩니다. . 선택 사항으로 지정된 옥텟의 값은 0입니다.

RTP의 절대 시간(벽시계 시간)은 NTP(Network Time Protocol) 타임스탬프 형식을 사용하여 표시되며, 이는 1900년 1월 1일의 0시간을 기준으로 한 초 단위의 카운트다운입니다. 전체 NTP 타임스탬프 형식은 처음 32비트에 정수 부분이 있고 마지막 32비트에 소수 부분이 있는 64비트 부호 없는 고정 소수점 숫자입니다. 보다 간결한 표현이 있는 일부 필드에서는 정수 부분의 하위 16비트와 소수 부분의 상위 16비트인 중간 32비트만 사용됩니다.

이 기사의 다음 두 섹션(3 및 4)에서는 각각 RTP 및 RTCP 프로토콜 기능의 패킷 형식과 기능에 대해 설명합니다.

3. RTP 데이터 전송 프로토콜

3.1. 고정 RTP 헤더 필드

위에서 언급한 바와 같이, RTP 패킷은 고정 헤더, 선택적 가변 길이 헤더 확장 및 데이터 필드를 포함합니다. RTP 프로토콜 패킷의 고정 헤더 형식은 다음과 같습니다.

처음 12개의 옥텟은 모든 RTP 패킷에 존재하는 반면 기여 소스 CSRC(기여 소스) 식별자 필드는 믹서에 의해 삽입될 때만 존재합니다. 필드의 목적은 다음과 같습니다.

버전(V): 2비트. 이 필드는 RTP 버전을 식별합니다. 이 기사는 RTP 프로토콜의 버전 2에 초점을 맞춥니다(값 1은 RTP의 첫 번째 초안 버전에서 사용됨).

보수(P): 1비트. 패딩 비트가 1로 설정되면 끝에 있는 패킷에는 트래픽의 일부가 아닌 하나 이상의 패딩 옥텟이 포함됩니다. 마지막 패딩 옥텟은 이후에 무시될 그러한 옥텟의 수에 대한 표시를 포함합니다. 고정 블록 크기를 사용하거나 단일 기본 프로토콜 페이로드에서 여러 RTP 패킷을 전달하기 위해 일부 암호 알고리즘에 패딩이 필요할 수 있습니다.

확장자(X): 1비트. 확장 비트가 설정되면 고정 헤더 다음에 에 정의된 형식의 헤더 확장이 옵니다.

CSRC 카운터(CC): 4비트. CSRC 카운터에는 고정 헤더 다음에 포함할 CSRC 소스 식별자의 수가 포함됩니다(사용된 약어 및 용어 목록 참조).

마커(M): 1비트. 마커의 해석은 프로필에 의해 결정됩니다. 중요한 이벤트(예: 비디오 프레임 경계)가 패킷 스트림에 표시되도록 하기 위한 것입니다. 프로필은 추가 마커 비트를 도입하거나 트래픽 유형 필드의 비트 수를 변경하여 마커 비트가 없는 것으로 결정할 수 있습니다( 참조).

트래픽 유형(PT): 7비트. 이 필드는 RTP 트래픽의 형식을 식별하고 애플리케이션이 이를 해석하는 방법을 결정합니다. 프로필은 PT 값과 트래픽 형식의 기본 정적 매핑을 정의합니다. 추가 트래픽 유형 코드는 비 RTP 기능을 통해 동적으로 정의할 수 있습니다. 주어진 시간에 RTP 패킷의 발신자는 단일 RTP 트래픽 유형 값을 내보냅니다. 이 필드는 개별 미디어 스트림을 다중화하기 위한 것이 아닙니다( 참조).

시퀀스 번호: 16비트. 시퀀스 번호 값은 RTP 정보 패킷이 전송될 때마다 1씩 증가하며 수신기에서 손실된 패킷을 감지하고 원래 시퀀스를 복원하는 데 사용할 수 있습니다. 시퀀스 번호의 초기 값은 이 필드의 알려진 값을 기반으로 키를 해독하기 어렵게 하기 위해 무작위로 선택됩니다(소스가 암호화를 사용하지 않더라도 패킷이 암호화를 사용하는 릴레이를 통과할 수 있기 때문에). 타임스탬프: 32비트. 타임스탬프는 RTP 정보 패킷의 첫 번째 옥텟에 대한 샘플링 시간을 반영합니다. 샘플 시간은 동기화 및 지터 감지를 제공하기 위해 시간에 따라 단조 및 선형적으로 증가하는 타이머에서 파생되어야 합니다(섹션 4.3.1 참조). 타이머의 해상도는 원하는 타이밍 정확도와 패킷 도착 지터 측정에 충분해야 합니다(일반적으로 비디오 프레임당 하나의 타이머 보고로는 충분하지 않음). 타이밍 주파수는 전송된 트래픽의 형식에 따라 다르며 프로필 또는 트래픽 형식 사양에서 정적으로 설정되거나 "비 RTP 도구"를 통해 정의된 트래픽 형식에 대해 동적으로 설정할 수 있습니다. RTP 패킷이 주기적으로 생성되는 경우 시스템 타이머 값이 아닌 샘플링 타이머에 의해 결정된 공칭 샘플링 시간을 사용해야 합니다. 예를 들어, 고정 속도 오디오 신호의 경우 타임스탬프 인코더가 각 샘플 기간에 대해 1씩 증가하는 것이 바람직합니다. 입력 장치의 오디오 응용 프로그램이 160개 샘플을 포함하는 블록을 읽는 경우 블록이 패킷으로 전송되었는지 또는 일시 중지로 삭제되었는지 여부에 관계없이 이러한 각 블록에 대해 타임스탬프를 160씩 증가해야 합니다. 타임스탬프의 초기값은 시퀀스 번호의 초기값과 마찬가지로 랜덤 변수입니다. 여러 개의 연속적인 RTP 패킷이 논리적으로 동시에 생성되는 경우, 예를 들어 동일한 비디오 프레임에 속하는 경우 동일한 타임스탬프를 가질 수 있습니다. 보간된 MPEG 비디오 프레임의 경우와 같이 데이터가 샘플 순서로 전송되지 않으면 연속 RTP 패킷에 비단조 타임스탬프가 포함될 수 있습니다(그러나 패킷 시퀀스 번호는 전송될 때 여전히 단조입니다).

SSRC: 32비트. SSRC(동기화 소스) 필드는 동기화 소스를 식별합니다(사용된 약어 및 용어 목록 참조). 이 ID는 동일한 RTP 세션 내에서 두 개의 클록 소스가 동일한 SSRC ID를 가지지 않도록 무작위로 선택됩니다. 여러 출처에서 동일한 식별자를 선택할 가능성은 낮지만 모든 RTP 구현은 이러한 충돌을 감지하고 해결할 준비가 되어 있어야 합니다. 6장에서는 SSRC 식별자의 고유성을 기반으로 충돌을 해결하고 RTP 계층 루프를 감지하는 메커니즘과 함께 충돌 확률에 대해 설명합니다. 소스가 원래 전송 주소를 변경하면 루프 소스로 해석되지 않도록 새 SSRC 식별자도 선택해야 합니다.

CSRC 목록: 0 ~ 15개 항목, 각각 32비트. 기여 소스(CSRC) 목록은 포함할 패킷에 포함된 트래픽 소스를 식별합니다. 식별자의 수는 CC 필드에 의해 제공됩니다. 포함된 출처가 15개 이상이면 그 중 15개만 식별할 수 있습니다. CSRC ID는 전환된 소스에 SSRC ID를 사용할 때 믹서에 의해 삽입됩니다. 예를 들어 사운드 패킷의 경우 패킷이 생성될 때 혼합된 모든 소스의 SSRC 식별자가 CSRC 목록에 나열되어 수신자에게 메시지 소스에 대한 올바른 표시를 제공합니다.

3.2. RTP 세션

위에서 언급한 바와 같이 RTP 프로토콜에 따라 서로 다른 유형의 트래픽은 서로 다른 RTP 세션에서 별도로 전송되어야 합니다. 세션은 대상 전송 주소의 특정 쌍(네트워크 주소 1개와 RTP 및 RTCP용 포트 쌍)으로 정의됩니다. 예를 들어, 별도로 인코딩된 오디오 및 비디오로 구성된 원격 회의에서 각 유형의 트래픽은 고유한 대상 전송 주소가 있는 별도의 RTP 세션으로 전송되어야 합니다. 오디오와 비디오는 동일한 RTP 세션에서 전달되지 않으며 트래픽 유형 또는 SSRC 필드에 따라 분리됩니다. 패킷의 인터리빙 다른 유형하지만 동일한 SSRC를 사용하면 몇 가지 문제가 발생할 수 있습니다.

  1. 세션 중에 트래픽 유형 중 하나가 변경되면 이전 값 중 새 값으로 대체된 값을 결정할 수 있는 일반적인 수단이 없습니다.
  2. SSRC는 단일 타이밍 간격 값과 시퀀스 번호 공간을 식별합니다. 여러 트래픽 유형을 인터리빙하려면 서로 다른 스트림의 클록 속도가 다른 경우 서로 다른 동기화 간격이 필요하고 패킷 손실과 관련된 트래픽 유형을 나타내기 위해 서로 다른 시퀀스 번호 공간이 필요합니다.
  3. RTCP 송신자 및 수신자 메시지(섹션 4.3 참조)는 SSRC에 대한 하나의 타이밍 간격 값과 시퀀스 번호 공간만 설명하며 트래픽 유형 필드를 전달하지 않습니다.
  4. RTP 믹서는 서로 다른 유형의 트래픽이 인터리브 처리된 스트림을 단일 스트림으로 결합할 수 없습니다.
  5. 단일 RTP 세션에서 여러 유형의 트래픽 전송은 다음 요인에 의해 방해를 받습니다. 비디오 신호가 가용 대역폭을 초과한 경우에만 오디오와 같이 필요할 때 멀티미디어 데이터의 서브세트를 수신하는 단계; 서로 다른 유형의 트래픽에 대해 별도의 프로세스를 사용하는 싱크 구현과 별개의 RTP 세션을 사용하면 단일 및 다중 프로세스 구현이 모두 가능합니다.

각 트래픽 유형에 대해 서로 다른 SSRC를 사용하지만 동일한 RTP 세션에서 전송하면 처음 세 가지 문제는 피할 수 있지만 마지막 두 개는 피할 수 없습니다. 따라서 RTP 프로토콜의 사양은 각 유형의 트래픽이 고유한 RTP 세션을 사용하도록 요구합니다.

3.3. 프로필 정의 RTP 헤더 변경

기존 RTP 정보 패킷 헤더는 RTP를 지원할 수 있는 모든 애플리케이션 클래스에 일반적으로 필요한 기능 세트에 대해 완전합니다. 그러나 특정 작업에 더 잘 적응하기 위해 프로필 사양에 정의된 수정 또는 추가를 통해 헤더를 수정할 수 있습니다.

마커 비트 및 트래픽 유형 필드는 프로필 특정 정보를 전달하지만 많은 애플리케이션이 필요할 것으로 예상되는 고정 헤더에 위치합니다. 이러한 필드를 포함하는 옥텟은 예를 들어 더 많거나 더 적은 마커 비트를 사용하여 다양한 요구 사항을 충족하기 위해 프로필에 의해 재정의될 수 있습니다. 마커 비트가 있는 경우 프로필 독립 모니터가 패킷 손실 패턴과 마커 비트 간의 상관 관계를 관찰할 수 있으므로 옥텟의 상위 비트에 배치해야 합니다.

특정 트래픽 형식(예: 비디오 코딩 유형)에 필요한 추가 정보는 패킷의 데이터 필드에 포함되어야 합니다(MUST). 데이터 배열의 시작 또는 내부의 특정 위치에 배치할 수 있습니다.

특정 클래스의 애플리케이션이 트래픽 형식과 무관한 추가 기능을 필요로 하는 경우 해당 애플리케이션이 작동하는 프로필은 기존 고정 헤더의 SSRC 필드 바로 뒤에 배치할 추가 고정 필드를 정의해야 합니다. 이러한 애플리케이션은 추가 필드에 직접 빠르게 액세스할 수 있는 반면 프로필 독립 모니터 또는 레코더는 처음 12개의 옥텟만 해석하여 RTP 패킷을 계속 처리할 수 있습니다.

일반적으로 모든 프로필에 대해 추가 기능이 필요하다고 판단되는 경우 새 버전만들 RTP 영구적인 변화고정 헤더.

3.4. RTP 헤더 확장

개별 구현이 데이터 패킷 헤더에 추가 정보를 전달해야 하는 새로운 트래픽 형식 독립적 기능을 실험할 수 있도록 RTP는 패킷 헤더 확장 메커니즘을 제공합니다. 이 메커니즘은 헤더 확장이 필요하지 않은 다른 협력 응용 프로그램에서 헤더 확장을 무시할 수 있도록 설계되었습니다.

RTP 헤더의 X 비트가 1로 설정되면 가변 길이 헤더 확장이 고정 RTP 헤더에 추가됩니다(있는 경우 CSRC 목록을 따름). 이 헤더 확장은 제한된 용도로만 사용됩니다. RTP 패킷 헤더 확장의 형식은 다음과 같습니다.

확장에는 4옥텟 확장 헤더(따라서 길이는 0이 될 수 있음)를 제외하고 32비트 단어의 수를 나타내는 16비트 길이 필드가 있습니다. 고정 RTP 정보 패킷 헤더에는 하나의 확장만 추가할 수 있습니다. 복수의 협력 구현 각각이 서로 다른 헤더 확장을 독립적으로 실험할 수 있도록 하거나 특정 구현이 하나 이상의 유형의 헤더 확장을 실험할 수 있도록 하기 위해 확장의 처음 16비트의 사용은 정의되지 않고 구별하기 위해 남겨둡니다. 식별자 또는 매개변수. 이 16비트의 형식은 응용 프로그램이 작업하는 프로필 사양에 따라 결정되어야 합니다.


1999
2000

우리가 IP 전화로 이야기하거나 수신기에서 대화 상대의 음성을 듣거나 화상 회의 시스템을 사용하여 동료 및 친척과 통신할 때 우리는 지속적인 데이터 스트림을 교환합니다. 패킷 네트워크를 통해 음성 및 비디오와 같은 스트리밍 데이터를 전송할 때 다음 작업을 해결하는 메커니즘을 사용하는 것이 매우 중요합니다.

  • 패킷 손실의 영향 제거
  • 주문 복원 및 패킷 제어
  • 지연 평활화(지터)

이러한 목적으로 개발된 RTP(Real-time Transport Protocol)은 실시간 전송 프로토콜로, 오늘 기사에서 다룰 것입니다. 이 프로토콜은 오디오-비디오 전송 작업 그룹이 IETF에서 개발했으며 RFC 3550에 설명되어 있습니다.

일반적으로 RTP는 UDP(User Datagram Protocol) 위에서 작동합니다. 멀티미디어 데이터를 전송할 때 적시에 전달하는 것이 매우 중요하기 때문입니다.

RTP에는 페이로드 유형을 결정하고 스트림에 있는 패킷의 시퀀스 번호를 할당하는 기능과 타임스탬프를 사용하는 기능이 포함됩니다.

송신측에서 각 패킷은 타임스탬프로 표시되고 수신측은 이를 수신하여 총 지연을 결정한 후 총 지연의 차이를 계산하고 지터를 결정합니다. 따라서 패킷 전달에 일정한 지연을 설정하여 지터의 영향을 줄일 수 있습니다.

RTP의 또 다른 기능은 다음과 관련이 있습니다. 가능한 손실패킷이 IP 네트워크를 통과하는 동안 대화에서 짧은 일시 중지의 모양으로 표현됩니다. 갑작스런 침묵 핸드셋, 일반적으로 청취자에게 매우 부정적인 영향을 미치므로 RTP 프로토콜의 기능으로 이러한 침묵 기간은 소위 "편안한 소음"으로 채워집니다.

RTP는 RFC 3550에 설명된 RTCP(실시간 전송 제어 프로토콜)라는 다른 IETF 프로토콜과 함께 작동합니다. RTCP는 통계 정보를 수집하고 서비스 품질 QoS(서비스 품질)를 결정하고 RTP 세션의 미디어 스트림 간에 동기화합니다.

RTCP의 주요 기능은 수신된 정보의 품질에 대해 보고하기 위해 애플리케이션과 피드백을 설정하는 것입니다. RTCP 세션의 참가자는 수신 및 손실 패킷 수, 지터 값, 지연 등에 대한 정보를 교환합니다. 이 정보의 분석을 기반으로 전송 품질을 개선하기 위해 정보 압축 비율을 줄이는 등 전송 매개변수를 변경하기로 결정합니다.

이러한 기능을 수행하기 위해 RTCP는 특정 유형의 특수 메시지를 보냅니다.

  • SR - 발신자 보고서 - RTP 세션에 대한 통계 정보가 포함된 소스 보고서
  • RR - 수신자 보고서 - RTP 세션에 대한 통계 정보가 포함된 수신자 보고서
  • SDES - cname(사용자 이름)을 포함한 소스 옵션에 대한 설명이 포함되어 있습니다.
  • 안녕 – 그룹의 구성원 자격 종료를 시작합니다.
  • 앱 - 응용 기능 설명

RTP는 단방향 프로토콜이므로 양방향 통신에는 양쪽에 하나씩 두 개의 RTP 세션이 필요합니다.

RTP 세션은 참가자의 IP 주소와 16384 - 32767 범위의 예약되지 않은 UDP 포트 쌍으로 정의됩니다. 또한 응용 프로그램과의 피드백을 구성하기 위해 두 개의 설정도 필요합니다. 방법 RTCP 세션. RTCP 세션의 경우 RTP보다 1이 큰 포트가 점유됩니다. 예를 들어 포트 19554가 RTP에 대해 선택되면 RTCP 세션은 포트 19555를 사용합니다. 시각적으로 RTP/RTCP 세션의 구성은 아래 그림과 같습니다.