rtp 프로토콜 예제

그러나 프로필 문서(RFC 3551)는 일반적으로 응용 프로그램의 필요에 따라 헤더를 조작하는 데 사용되는 방법론을 제공하기 때문에 이 확장 헤더를 사용하는 것은 드문 일입니다. 실제로 이 장의 작성에 사용된 토폴로지 에는 확장 헤더가 포함되어 있지 않습니다. 이것은 RTP 고정 헤더가 우리가 지금까지 본 것에 국한된다는 것을 말하는 것이 아닙니다. 다른 문서는 통신 시스템에 필요할 수 있는 신호 및 사운드를 처리하기 위한 추가 메커니즘을 제공합니다. 예를 들어 RFC 4733은 VoIP 시스템에서 듀얼 톤 다중 주파수(DTMF) 신호를 전송하기 위해 수행해야 하는 작업을 간략하게 설명합니다. 이러한 캡슐화의 예는 도 4-19에 도시되어 있다. 프로토콜 변형을 나타내는 2비트 필드입니다. 가능한 값은 다음과 같습니다: RTP는 의도적으로 완전하지 않은 프로토콜 프레임워크입니다. 이 문서에서는 RTP가 적합한 모든 응용 프로그램에서 공통으로 예상되는 함수를 지정합니다. 기존의 프로토콜과는 달리 … RTP는 필요에 따라 헤더에 대한 수정 및/또는 추가를 통해 맞춤화됩니다.

이 필드는 수신기에 패킷에 포함된 데이터의 형식을 알려주는 7비트 필드입니다. 이 값은 샘플에 사용되는 소스 코덱의 숫자 값을 제공합니다. 낮은 값(0-23)은 오디오 코덱용이며, 다른 페이로드 유형도 존재할 수 있지만 더 높은 값은 일반적으로 비디오의 경우입니다. 예를 들어 RFC 4733(RFC 2833)은 다양한 ID를 사용하여 여러 DTMF 페이로드를 설명합니다. 그림 4-7의 패킷 컬렉션에서 RTP 패킷에 G.729로 인코딩된 데이터가 포함되어 있음을 확인할 수 있습니다. 그림 4-6에 표시된 패킷은 G.711 코덱으로 인코딩됩니다. RFC 3551은 작성 시점까지 정의된 코덱 목록을 제공합니다. RFC 3551의 표 4의 몇 가지 예는 다음과 같습니다(그림 4-8): 네트워킹 모델의 계층 4에서 RTP는 UDP 헤더로 캡슐화됩니다.

UDP는 우선 순위 처리 또는 시퀀싱을 거의 제공하지 않습니다. 이는 대상의 응용 프로그램이 이를 기다려야 하는 경우 손실되거나 상당히 지연된 패킷이 문제를 일으킬 수 있기 때문에 실시간 데이터에 일반적입니다.