dep. of information and communications engineering at hufs parksh01@gmail soohyun park

Dep. of Information and Communications Engineering at [email protected]

Soohyun Park

Real-time Streaming Protocols - RTP / RTCP / RTSP

mailto:[email protected]

Contents

Background

Introduction

RTP structure

RTP’s basic operations / RTP header / The examples of analyzing for RTP packets

RTCP / RTCP header

RTCP’s message types

RTCP’s traffic control

RTSP

Summary

Background (1/2)

인터넷 트래픽 양의 증가– 이용자 , host, 라우터 , 응용 , ISP 의 증가

인터넷 트래픽 내용의 변화– 기존 텍스트 위주에서 실시간 멀티미디어 트래픽으로 – 멀티미디어 트래픽

• 그래픽 , 이미지 , 오디오 , 동영상 , ...

– 실시간 트래픽 (Rea-time Traffic)• Audio/Video Conference• 인터넷 폰• 인터넷 방송• Streaming A/V

시간 제약성 고려 , QoS 또는 QoE 보장 필요

IP

UDP

RTP/RTCP

IP

UDP

RTP/RTCP

BE(Best-Effort) In-

ternet

Background (2/2)

RTP profiles (Payload type)– RFC 2032 – RTP payload format for H.261 Video streams– RFC 2190 – RTP payload format for H.263 Video streams– RFC 2250 – RTP payload format for MPEG1/MPEG2 video– RFC 3984 – RTP payload format for H.264 Video streams– RFC 3016 – RTP payload format for MPEG-4 Audio/Visual streams– RFC 2435 – RTP payload format for JPEG-compressed video– RFC 3551 – RTP profile for Audio ad Video conferences with minimal control– RFC 3640 – RTP payload format for transport of MPEG-4 Elementary Streams– RFC 4175 – RTP payload format for uncompressed video

Introduction

실시간 트래픽 전달을 위한 새로운 프로토콜– RTP(RFC 1889 : 1996 년 ), RTSP(RFC 2326 : 1998 년 ) 가

2003 년 RFC 3550 에 포함됨 – ITU-T H.323 에 채용됨– N to N conference 를 염두에 두고 설계– 미국 마이크로소프트사의 비디오 회의 소프트 NetMeeting

등이 탑재

RTP / RTCP 의 동작 개념도

RTP Architecture

Application Layer Framing (ALF)– 간단한 Framework 으로 복잡한 TCP 를 대신함

– Framework 는 기본적 동작과 메시지 포맷 정도만 규정• 실시간 트래픽에 유리• 예로 , 대부분의 오디오 재생 알고리즘은 데이터의 손실 또는 순서 오류 보다는 과도한 지연에 약하기 때문

– Framework+ AddOn = Complete protocol for specific application

RTP overhead– IP + UDP + RTP overhead = 20 + 8 + 12 = 40 Bytes

RTP’s basic operations

Time Stamping Real Time Data– Source 가 모든 메시지에 Time Stamp 표시– Receiver 는 이를 받아 보고 메시지간 타이밍 정보를 추출

Multicast Operation– A/V conference 염두– 여러 참여자들이 멀티캐스트 그룹을 이룸– Data traffic 뿐 아니라 control traffic 도 그룹내에 멀티캐스트 됨

인터넷Sender 규칙적 송신 불규칙적 수신

Receiver

RTP header (1/2)

CC (CSRC count)– Number of CSRCs (contributing sources) following the fixed header

M (Marker)– 오디오 / 비디오의 frame 시작과 끝 구별

PT (Payload Type)– 모든 패킷이 payload type 을 가짐으로써 망 QoS 변화에 따라 payload 형태 적응 가능

• e.g., 다른 encoding rule 적용

Sequence Number– 패킷의 손실 검출 , 순서 맞춤

RTP header (2/2)

Timestamp– 패킷내 첫번째 데이터 바이트의 샘플링 시점을 상대적 ( 스트림의 시작 비트대비 ) 으로 표시 ,

시작값은 랜덤– 예 ) PCM 음성을 20ms 단위로 패킷을 만들 경우

• 160 개 샘플을 포함하므로 (125uS*160=20ms) RTP 패킷마다 160 씩 증가

– 미디어스트림의 패킷발생이 일시중지 ( 묵음구간 등 ) 시에도 계속 증가

SSRC (Synchronization Source Identifier)– 미디어스트림의 소스를 식별– 미디어스트림이란 하나의 동기소스에서 생성되는 RTP 패킷열

CSRC (Contributing Source Identifier)– 다수의 미디어스트림이 새로운 미디어를 생성할 경우 생성된 미디어스트림에 새로운 SSRC

를 할당하는 대신 이들의 기여소스 미디어를 CSRD 로 식별함– 15 개 까지 수용 가능

The examples of analyzing for RTP packets (1/2)

음성 RTP 패킷

– 일대일 음성 통화로 단 방향만을 캡쳐한 그림

– SSRC 가 동일• 동일 세션에서 발생한 음성임을 확인

– 기본 샘플링 단위 시간 160ms 단위

The examples of analyzing for RTP packets (2/2)

영상 RTP 패킷

– Timestamp 의 time 이 모두 동일• 영상 전송시 전송 데이터가 다수임

– SSRC 가 동일• 동일 세션에서 발생한 영상임을 확인

RTCP (Real Time Control Protocol) (1/2)

RTP 패킷은 단방향 , RTCP 패킷은 양방향 지원

Feedback 또는 response 는 RTCP 가 지원– RTP 와 분리된 프로토콜이지만 , 밀접한 관계– 짝수인 RTP port number 보다 1 이 큰 port number 가짐

QoS 관리 , Inter-media Synchronization, Identification 이 주 기능– 세션 대역폭의 5% 이내로 RTCP 패킷 량 제한됨– 멀티캐스트 환경인 경우 , 전송 성능 및 QoS 감시가 가능– RTCP 메시지들 역시 멀티캐스트 됨

RTCP (Real Time Control Protocol) (2/2)

RTCP 의 주요 기능– 핵심기능은 RTP 세션을 통해 전달되는 미디어스트림의 통신품질정보 feedback– RTP 근원지에 대한 식별자인 CNAME(Canonical Name) 을 통지– 매체간 동기화를 위한 NTP 및 RTP 타임스탬프 값을 통보– 기타 세션제어 및 응용 확장을 위한 기능

5 개 메시지 유형이 존재– SR (Sender’s Report)– RR (Receiver’s Report)– SDES (Source Description)– BYE – APP (Application Specific)

RTCP header Version

– the same as for RTP header

P (padding)– the same as for RTP header

Count– the number of reception report blocks contained in this packet

Type– the packet type

(193 – NACK, 200 – SR report, 201 – RR report, 202 – SDES packet, 203 – BYE packet, 204 – APP packet)

Length– the length of the RTCP packet in 32 bit words minus one, including the header

and padding

RTCP’s message types (1/5)

Sender Report (SR)– 데이터 송신자가 주기적으로 수신자들에게 보내는 패킷– 기간 중 보낸 데이터 패킷 수 및 바이트 수 정보를 알림– 수신 데이터에 대한 Receiver report 를 겸하기도 함 (Receiver blocks)

Network Time Protocol Time Stamp


Receiver Report (RR)– ( 보낼 데이터가 없는 ) 수신자들이 송신자에게 주기적으로 보내는 패킷– Sender report 를 통해 받은 송신 패킷 정보를 , 실제 수신한 패킷 수와 비교하여 패킷

손실율 및 누적 손실 패킷 수를 계산하여 포함시킴– 또한 , 수신한 최고 sequence number, Interarrival jitter, sender report 의 최종 수신

시간 정보를 포함

LSR(Last Sender Report)

DLSR(Delay since LSR)


SR / RR 메시지를 통한 RTT 계산– LSR 과 DLSR 을 사용하여 왕복지연시간을 계산할 수 있음– A 는 RR 블럭이 수신된 시점의 시각

RTT : 6.125s – 5.250s = 0.875s


Source Description (SDES)– 소스가 자신의 정보를 주기적으로 알림 (Identification)– 소스 이름 (CNANE), 사용자 이름 , Email 주소 , 전화번호 , 주소 , 응용 프로그램 명 등– CNAME

• 여러 RTP 스트림을 하나의 송신자에 연관시키는데 이용 • Inter-media synchronization• e.g., audio / video synchronization

Source Count : chunk 의 수를 표기


Bye (BYE)– 소스가 conference 를 떠날 때 사용

Application Specific (APP)– Reserved for application-specific features and experiments

RTCP’s traffic control

참여자 수가 많을 시 , RTCP 의 traffic implosion 방지 – 세션 대역폭의 5% 를 넘지 않도록 함 – Report period 를 조정

세션 대역폭의 5% 에서 – 25% 를 송신 측에 배당하고 , 나머지 75% 를 수신 측에 배당

송신측의 RTCP 패킷 송신 주기 T– T= (( 송신자의 수 ) / (0.25*0.05* 세션대역폭 ))* 평균 RTCP 패킷 크기

수신측의 RTCP 메시지 송신 T– T= (( 수신자의 수 ) / (0.75*0.05* 세션대역폭 ))* 평균 RTCP 패킷 크기

RTSP (Real-Time Streaming Protocol)

On Demand 형식으로 real-time media streaming 을 실행– Application layer 프로토콜

실시간으로 음성이나 동화를 송수신하기 위한 통신 규약으로 정의됨 – Real Networks ( 구 progressive network) 사와 Netscape 사가 공동개발– RFC 2326 에 규정됨

RTSP 도 H.323 과 마찬가지로 , 멀티미디어 콘텐츠 패킷 포맷을 지정하기 위해 RTP를 사용– H.323 은 적당한 크기의 그룹간에 화상회의를 하기 위해 설계– RTSP 는 대규모 그룹들에게 오디오 및 비디오 데이터를 효율적으로 브로드캐스트하기 위한

목적으로 설계

RTP 와는 달리 application layer 에서 동작함

TCP 위에서 동작하며 , 표준포트는 554 번임

Summary

인터넷 트래픽 양의 증가 – 대용량 데이터의 송수신 증가– Real-time media traffic 의 증가– 서비스 제공을 위한 프로토콜의 필요성 증대

RTP / RTCP 를 통한 서비스의 제공– 초기에는 Real-time audio / N-To-N conference 서비스의 제공이 목적– 현재는 사용자의 요구증가로 주로 real-time media streaming 서비스 제공에 사용– Application layer 에서 RTSP 의 사용

RTCP 를 통해 RTP 를 사용하는 트래픽의 제어

dep. of information and communications engineering at hufs parksh01@gmail soohyun park

Documents