(RTP, RTCP, RTSP의 개요 및 동작과정) 멀티미디어 네트워킹 기술 (RTP, RTCP, RTSP의 개요 및 동작과정) 컴퓨터공학과 99003019 김규호 컴퓨터공학과 99003021 김대현 컴퓨터공학과 99003056 류성한 컴퓨터공학과 99006010 강대일

RTP란 실시간 수송 프로토콜(Real-Time Transport Protocol) 실시간 특성을 가지는 데이터의 전달이 필요한 응용에서 사용하는 프로토콜 UDP의 특성을 기반으로 함 TCP는 신뢰성을 강조한 나머지 데이터의 실시간 전달이 어려움 UDP는 신뢰성은 낮지만 TCP에 비해 빠르게 데이터를 전달 가능 RTP는 다른 네트워크계층이나 수송계층 프로토콜과 함께 쓰여 질수도 있으며, 하위의 프로토콜에 의존이 적음

RTP 패킷 형식(1) RTP는 모든 메시지들에 대해 같은 형태를 사용 RTP 헤더 오디오와 비디오 데이터를 동기화하여 화면에 출력 잃어버린 패킷이나 순서 없이 도착하는 패킷을 검사하는데 필요한, 시간 정보를 제공 다양한 데이터와 압축 타입을 허용되는 페이로드를 포함  RTP 패킷은 12-Byte 헤더와 다음에 오는 페이로드로 구성

RTP 패킷 형식(2) Synchronization source(SSRC) identifier V P X CC M Payload type Sequence number Timestamp Contributing source(CSRC) identifier Bit 4 8 9 16 31 V = Version P = Padding X = Extension CC = CSRC count M = Market

RTP 헤더필드의 의미(1) 필 드 약어 풀 스 펠 링 내 용 버전번호 V Version 필     드 약어 풀 스 펠 링 내           용 버전번호 V  Version   RTP의 버전을 표시. 현재의 버전은 2 패딩 필드 P  Padding  현재는 미사용 부분. 0의 값이 들어있음 확장 비트 X  Extension  이 비트는, 이 RTP 패킷이 RTP 헤더 외에 확장 RTP 헤더를 포함하고 있는가를 표시함. 확장 헤더는 RTP 에 특별한 기능을 제공하기 위한 헤더임. 지금까지 확장 RTP 헤더는 규정되어 있지 않기 때문에 이 비트가  세트되는 경우는 없음 컨트리뷰트 카운트    CCRC(Contribute Source Count) 이 필드는, 이 RTP 패킷이 격납하고 있는 데이터가 어느 정도 수의 공헌 소스로부터 생성되었는가를 표시함

RTP 헤더필드의 의미(2) 마커 비트 M Marker 페이로드 타입 PT  Payload Type  이 필드에는 이 RTP가 보관하고 있는 데이터 타입을 0-127의 수치로 표시함. 표 7-3은 현재까지 규정되어 있는 RTP의 페이로드 타입 번호와 그에 대응하는 부호화(인코딩)명(데이터 포맷명)임 시퀀스 번호 -  Sequence Number  이 필드는 RTP 패킷의 시퀀스 번호를 격남함. 이 시퀀스 번호는 RTP의 각 패킷마다 부여되어 있는 고유 번호임. 데이터 수신측은 시퀀스 번호를 근거로 현재 패킷의 수신율, 손신률을 파악할 수 있음

RTP 헤더필드의 의미(3) 타임 스탬프 - Timestamp 동기 소스 식별자 SSRC Synchronization Source (SSRC) Identifier  이 필드에는 동기 소스의 식별자가 들어감 공헌 소스 CSRC Contributing Source (CSRC) Identifier  이 필드에는 공헌 소스의 식별자가 들어감. 이 필드는 공헌 소스 수에 따라 증가됨. 공헌 소스 식별자 필드의 최대치는 15임. 만일 데이터가 15이상의 공헌 소스에서 생성된 경우에는 그 중에서 몇 개를 선택하여 RTP 헤더에 격납하게 됨

RTP 주요기능 동적인 페이로드 타입 할당 동기화 흐름 및 체증 제어 패킷 소스 탐색 정보를 전송하고 있는 동안 수신한 RTCP의 리포트 패킷에 따라 페이로드 타입을 동적으로 변화시키는 기능 동기화 동기화는 RTP 헤더 내의 timestamp필드를 이용하여 상위계층에서 각종 동기화를 수행할 수 있도록 정보를 제공해 주는 기능 흐름 및 체증 제어 RTCP의 SR(sender report)와 RR(receiver report) 패킷에 의해 이루어짐 패킷 소스 탐색 RTP 레벨의 중계자인 Mixer에서 여러 곳으로부터 받은 스트림을 하나의 새로운 스트림으로 생성할 때 수신측에서 본래의 생성자를 알 수 있도록 해 주는 기능

RTP 동작과정(1) RTP가 제공하는 통신 서비스는 “실시간 전송에 적당한 형태로 데이터를 전송하는 것” 주의사항 네트워크를 경유하여 전송되어 가는 중에 분실 되거나 지연되어 배달되기도 함 영상이나 음성 데이터는 데이터 일부가 결손 되어도 재생 가능

RTP 동작과정(2) 1 5 4 3 2 영상 데이터 전송 1장의 영상 프레임에 시간 정보를 부가하여 패킷화 한다. 지연 송신측 수신측 1 5 4 지연 3 2 패킷 소실(로스) 영상 데이터 전송 1장의 영상 프레임에 시간 정보를 부가하여 패킷화 한다. 지연된 패킷 데이터 소실된 패킷 데이터 데이터의 수신측은 패킷의 시간정보를 근거로 데이터를 재생한다. 소실하거나 배송이 지연된 패킷 부분의 프레임은 없어지지만 데이터 전체의 시간적인 관계는 보존된다.

RTP 아키텍쳐(1) RTP는 애플리케이션과 깊은 관계를 갖고 있지만 트랜스포트층 프로토콜의 성질도 가지고 있음 일반적으로 UDP 프로토콜을 하위 프로토콜로 이용함 TCP/IP의 아키텍처 안에서 RTP를 이용할 경우에는 RTP가 UDP의 상의 프로토콜로써 기능을 함 RTP는 하위층 프로토콜에 UDP 이외에 다른 통신 프로토콜도 이용할 수 있도록 유연하게 설계되어 있음

RTP 아키텍쳐(2) RTP 관련 프로토콜 계층과 RTP 멀티캐스트 통신의 예 데이터링크 층 ATM IP CLNP TCP 호스트 B 호스트 C 호스트 D 호스트 E 데이터링크 층 ATM IP CLNP TCP UDP RTP/RTCP 멀티캐스트 애플리케이션

RTP 구성요소 트랜스레이터(Translator) 믹서(Mixer, 데이터 합성기) 세션 동기 소스와 공헌 소스 세션  동기 소스와 공헌 소스 동기 소스, 공헌 소스의 식별자

트랜스레이터(Translator) RTP는 1대다 형의 멀티캐스트 통신을 대상으로 함 멀티캐스트 통신에서는 데이터를 수신하는 호스트가 고속 네트워크에 접속되어 있거나 저속 네트워크에 접속되어 있음 고속 네트워크에 접속되어 있는 호스트에 맞추어 높은 전송 레이트로 데이터를 전송하면 저속 네트워크에 접속된 호스트에서는 데이터를 바르게 수신할 수 없음 저속 네트워크에 접속된 호스트에 맞추어 낮은 전송 레이트로 데이터를 전송하면 고속 네트워크에 접속된 호스트는 네트워크를 유효하게 이용할 수 없음 이런 문제를 해결하기 위하여 RTP는 트랜스레이터(Translator)라고 부르는 데이터를 변환하여 중계하는 호스트를 규정

트렌스레이터를 이용한 RTP 데이터 전송 트랜스레이트 (속도 변환기) 고속 네트워크 수신 호스트 (속도 변환기) 저속 네트워크 송신 호스트 트랜스레이트 ⊙프레임 레이트 저하 ⊙화질 저하 ⊙샘플링 레이트 저하 전송레이트를 낮춤 트랜스레이터가 수신한 데이터를 저속 네트워크용으로 변환하여 전송히기 때문에 저속 네트워크 접속해 있는 수신 호스트도 데이터를 수신할 수 있다.

믹서(Mixer, 데이터 합성기) RTP가 대상으로 하는 화상 회의 애플리케이션 등에서는 복수의 송신 호스트가 동시에 영상이나 음성 등의 정보를 송신할 경우가 있음 네트워크 대역이 충분한 경우는 이들 정보를 각각 개별적으로 송신할 수도 있음 네트워크 대역에 여유가 없는 경우, 개별적으로 데이터를 송신하면 네트워크 대역이 범람하여 부족현상이 생길 가능성도 있음 이런 문제에 대처하기 위하여 RTP에서는 트랜스레이터와는 다른 기능을 가진 “믹서”라고 하는 데이터 중계 호스트를 규정

믹서를 이용한 RTP 데이터 전송 믹서 (데이터 합성기) 믹서가 송신 호스트 A와 송신 호스트 B의 데이터를 합성하여 전송하기 때문에 저속 네트워크에 접속하고 있는 호스트도 데이터를 수신할 수 있다 고속 네트워크 수신 호스트 믹서 (데이터 합성기) 저속 네트워크 A와 B를 합성한 데이터 송신 호스트A 송신 호스트B A 데이터 B 데이터

세션(Session) RTP는 RTP를 이용하여 통신하는 호스트 그룹을 “세션”이라고 하는 개념을 이용하여 식별 RTP의 세션 개념은 OSI 7층 프로토콜의 세션층의 개념과는 미묘하게 다름 차이점 : OSI의 세션층은 다음은 누가 데이터를 송신할 것인가라고 하는 다이얼로그 관리(대화관리) 등의 기능을 가지고 있지만, RTP의 세션에는 이런 기능이 없음 세션은 RTP의 하위층 프로토콜의 식별자를 이용하여 식별됨 RTP가 하위층 프로토콜로 UDP와 IP를 이용할 경우, 세션은 “수신처 IP 어드레스”와 “U에 포트”의 조합으로 식별됨 IP 멀티캐스트를 이용하여 RTP 패킷을 전송할 경우, 같은 세션에서 통신하는 호스트 그룹은 같은 어드레스와 포트의 조합을 이용하여 통신함

RTP 세션의 예 (224.1.2.3, 5004) 앞으로 패킷 전송 호스트 D 호스트 E 호스트 C 호스트 A 호스트 B 멀티캐스트용 IP 주소 UDP 포트 번호

동기소스와 공헌소스 RTP는 데이터의 송신원을 식별하는 “동기 소스” 와 “공헌소스”라는 두 가지 개념을 가지고 있음 “누가 데이터를 송신했는가”의 의미 공헌 소스 “데이터는 원래 누가 송신한 것인가”의 의미

동기소스와 공헌소스 예 호스트 E(믹서) 호스트 C와 D는 동기소스 식별자가 호스트 A와 B인 데이터를 수신한다. 고속 네트워크 호스트 F 호스트 G 호스트 E(믹서) 저속 네트워크 동기 소스 : E 공헌소스 : A,B 호스트 A 호스트 B 호스트 C 호스트 D 호스트 C와 D는 동기소스 식별자가 호스트 A와 B인 데이터를 수신한다. ◎호스트 C,D,E에 대한 동기소스 ◎호스트 F,G에 대한 공헌 소스 동기소스 A 동기소스 B 호스트 E는 호스트 A와 B의 데이터를 합성하여 호스트 F와 G에 전송. 이 경우 동기 소스 식별자는 호스트 E, 공헌소스 식별자는 호스트 A와 B

동기 소스, 공헌 소스의 식별자 동기 소스의 식별자와 공헌 소스의 식별자는 하위층의 프로토콜에 의존하지 않는 32비트의 수치로 표시됨 이 수치는 하나의 세션 안에서 유일하여야 함 어떤 호스트가 하나의 세션내에서 음성과 영상의 정보를 전송할 경우, 영상과 음성 데이터를 운반하는 RTP 패킷에 서로 다른 동기 소스 식별자를 부여하여 전송 동기 소스나 공헌 소스에서 이용하는 32비트의 수치를 생성하는 알고리즘의 예가 RTP를 규정하고 있는 RFC 1889 내에 제시되어 있음

Ethereal을 통한 RTP 분석 예 (1) 실시간 동영상 재생에서 실제로 RTP가 사용되는지를 Ethereal 프로그램을 사용 환경 Windows Media Player 사용 WindowsMedia.com의 동영상을 실시간으로 재생 Ethereal 프로그램을 사용하여 RTP 프로토콜 캡쳐

Ethereal을 통한 RTP 분석 예 (2)

Ethereal을 통한 RTP 분석 예 (3)

Ethereal을 통한 RTP 분석 예 (4) 프로토콜 분석결과 필 드 약어 풀 스 펠 링 분 석 내 용 버전번호 V 필      드 약어 풀 스 펠 링 분  석  내  용 버전번호 V  Version   RTP의 버전을 표시. 현재의 버전은 2 패딩 필드 P  Padding  현재는 미사용 부분. 0의 값이 들어있음(False) 확장 비트 X  Extension  0의 값이 들어있음(False) 컨트리뷰트 카운트    CCRC  (Contribute Sorce Count)  6개의 공헌소스 생성 마커 비트 M  Marker   0의 값이 들어있음(False) 페이로드 타입 PT  Payload Type  ITU_T G.723 , 유료부하유형(4), 음성타입

RTCP 란 RTP 세션에 참가하는 호스트가 RTP 정보를 교환하기 위한 통신 프로토콜 RTCP의 사양은   RFC 1889에 규정 됨

RTCP의 필요성 RTP는 데이터 전송만 하는 프로토콜로써 통신 상황을 전하는 체계가 없음 네트워크가 혼잡할 경우 데이터 전송속도나 전송량 감소 수신측의 수신 속도가 전송속도보다 느린 경우 전송측에서 데이터 전송 속도 조절을 할 필요성 발생

RTCP의 식별자 IP 어드레스와 포트 번호의 조합으로 지정 RTCP가 어느 RTP 세션 안에서 이용되고 있는 가를 명확히 알려줌 RTP 세션의 세션 식별자의 포트 번호에 “1”을 더한 조합을 사용 예) RTP(224.1.2.3, 5004) RTCP(224.1.2.3, 5005) RTP에서 사용되는 포트 번호는 항상 짝수를 사용 RTCP는 RTP 세션의 포트 번호에 “1”를 더한 홀수 포트 번호를 사용

RTCP의 메시지 타입 (1) RTCP는 RTP 전송에 참여하는 프로그램들 간에 QoS 정보를 교환함 QoS를 평가하고 이에 따른 적응성  있는 인코딩(encoding)을 제공 패킷 송신률을 계산하고 최소한의 세션 제어 정보를 제공 CNAME이라 부르는 영구 트랜스포트 식별자도 제공

RTCP의 메시지 타입 (2) SN (Sender Report) RR (Receiver Report ) 데이터 송신 호스트가 송신한 데이터에 관한 레포트를 세션 참가 호스트에게 통지할 경우에 이용 RR (Receiver Report ) 데이터 수신 호스트가 수신한 데이터에 관한 fp포트를 세션 참가 호스트에게 통지할 경우에 이용 SDES (Source Description ) 데이터 송신 호스트가 수신 호스트에 대하여 보다 상세한 송신 호스트 정보를 통지할 `경우에 이용된다 Bye 세션 참가 호스트가 세션에서 이탈할 경우에 이용 Application Specific 애플리케이션 고유의 정보를 세션 참가 호스트에게 통지하기 위하여, 혹은 새로운 RTCP 메시지 타입을 실험하기 위하여 이용

RTCP 메시지의 송신 간격 (1) 멀티캐스트로 전송 및 정기적으로 모든 세션 참가 호스트에게 통지 송출하는 빈도가 많아지면 네트워크 대역의 소비가 커지고, 송출 빈도가 적을 경우라도 세션 참가 호스트가 많으면 대역소비가 커짐 일정한 간격으로 송신 시 트래픽이 발생할 가능성도 있기 때문에 메시지 송출 간격을 난수를 이용하여 결정함

RTCP 메시지의 송신 간격 (2) RTP와 RTCP는 한 미디어 스트림에 대해 하나의 세션을 생성함 RTP 데이터 패킷들이 32-bit 구별자(SSRC)를 통해 자신의 것을 구별하는 반면에, RTCP 메시지는 SDES 패킷을 포함 RTCP는 IP에 있어서 ICMP처럼 전송 속도를 떨어뜨리는 등의 직접적인 제어를 하지 않음

RTSP(real-time streaming protocol)란 (1) 실시간 스트리밍 프로토콜은 인터넷을 이용하는 클라이언트/서버 환경에 시간적 제약 조건이 비교적 느슨한 멀티미디어 정보를 전달하기 위한 통신 프로토콜이다. RTSP는 미디어 플레이어가 매체 스트림의 전송을 제어할 수 있게 하는 프로토콜이다. 소위 말하는  대역외(out-of-band)프로토콜이다. 반면 (RTSP에 의해 패킷 구조가 정의되지 않은)매체 스트림은 “대역내(in-band)"로 여겨진다. RTSP는 메시지가 TCP나 UDP 상으로  전송 되는 것을 허용한다.

RTSP(real-time streaming protocol)란 (2) 다수의 인터넷 멀티미디어 사용자들(특히, 원격 tv제어기를 손에 들고 자란 사람들)은 재생 중지, 이전이나 이후 시점으로 재생 재위치, 화상의 급전진 재생, 화상의 되감기 재생 등을 함으로써 연속적인 매체의 재생을 제어하고 싶어 한다. 사용자가 재생을 제어할 수 있도록 하려면, 미디어 플레이어와 서버는 재생 제어 정보를 교환하는 프로토콜이 필요하며, RFC 2326에 정의 되어 있는 RTSP가 이런 프로토콜이다. RealNetworks사, Netscape Communications사, 그리고 콜럼비아대학이 공동으로 만들었으며, IETF(internet engineering task force)의 MMUSIC(multiparty multimedia session control)이라는 연구그룹에서 RFC 2326으로 표준화 되었다.

RTSP 동작구조(1) 매체 서버 Client Server 웹 브라우져 웹 서버 HTTP GET 시간 프리젠테이션 기술 파일 SET UP PLAY Media stream PAUSE TEARDOWN 시간

RTSP 동작구조(2) 웹 브라우저는 웹 서버에게 프리젠테이션 기술 파일을 요청한다. 웹 브라우저는 웹 서버에게  프리젠테이션 기술 파일을 요청한다. 프리젠테이션 기술 파일은 연속매체 파일의 동기화에 대해서 지시할 뿐만 아니라 연속 매체 파일들을 참조할 수 있다. 각각의 연속 매체 파일에 대한 참조는 URL 기법인 rtsp://로 시작된다. 오디오 스트림에 대해 미디어 플레이어는 두 종류의 오디오 기록 즉 저품질(low-fidelity)기록과 고품질(high-fidelity) 기록 중에서 선택(“스위치”)할 수 있다. 웹 서버는 프리젠테이션 기술 파일을 HTTP응답 메시지에 캡슐화해서 브라우저에 전송한다. 브라우저는 HTTP응답 메시지를 수신하면 그 메시지의 content-type 필드에 따라 미디어 플레이어(즉, 헬퍼 응용)를 가동한다. 플레이어와 서버는 서로에게 일련의 RTSP메시지를 전송한다.

RTSP 동작구조(3) 플레이어는 RTSP SETUP 요청을 보내고 서버는 RTSP SETUP 응답을 보낸다. 플레이어는 저품질 오디오에 대한 RTSP PLAY요청을 보내며 서버는 RTSP PLAY 응답을 보낸다. 이 시점에, 스트리밍 서버는 저품질 오디오를 자신의 대역내 채널로 내보낸다. 미디어  플레이어는 RTSP PAUSE요청을 보내고 서버는 RTSP PAUSE 응답을 한다. 사용자가 끝나면, 미디어 플레이어는 RTSP TEARDOWN 요청을 보내며 서버는 RTSP TEARDOWN으로 답한다. 각각의 RTSP 세션은 서버에 의해서 선택된 세션 식별자를 가진다. 클라이언트는 SETUP요청으로 세션을 시작하며, 서버는 이 요청에 대해 식별자로 답한다. 클라이언트는 TEARDOWN 요청으로 세션을 종료  할 때까지 각 요청마다 세션 식별자를 사용한다. 

Ethereal을 통한 프로토콜 분석