블로그 > If I can be yours..
http://blog.naver.com/dallpang2/20011439153
1. RTP (Realtime Transport Protocol)
1) RTP 개요
실시간 미디어 방송 또는 화상회의 정보를 인터넷이나 인트라넷에서 구동하기 위해서는 Realtime 으로 미디어 데이터를 전송하고자 하는 요구가 증가하고 있다. 이러한 네트워크 밴드 대역의 요구를 충족하기 위해서 Real Time Transport Protocol (RTP) 이 소개되었고, 네트워크를 통한 미디어 데이터의 송신 및 수신을 위해 JMF 에서 RTP를 구현하는 패키지를 기본적으로 제공하고 있다.
2) RTP를 사용하게 된 이유
먼저 RTP 라는 새로운 프로토콜이 나온 이유는 실시간 전송환경에서는 높은 대역의 BandWidth를 필요로 하며 데이터를 수신 할 때는 전송중의 전송지연에 대한 보상을 위한 처리보다는 손실 데이터에 대한 보상이 구현상 더 쉬운 편 이기 때문에 이런 측면에서 멀티미디어 데이터의 전송시에 요구되는 환경은 파일 전송 같은 완전한 데이터의 전송이 요구되는 무손실 통신 환경과는 다른 측면이 있음을 알 수 있다. 결과적으로 이러한 파일 같은 정적인 데이터를 보내는 프로토콜은 스트리밍 데이터를 전송하기 위한 프로토콜로는 적합하지 않다는 것이다.
2. HTTP, FTP 프로토콜의 문제점
1) HTTP, FTP 등의 일반적인 연결지향형 프로토콜은 일반적인 인터넷 프로토콜로서 송신 및 수신시에 전송 데이터의 확고한 안정성 보장에 중점을 둔 프로토콜이므로, 속도에 중점을 두어 설계된 프로토콜이 아니다. 즉 HTTP, FTP 등은 전송되는 목적지에 전송하는 모든 데이터 패킷의 완전한 전송을 보장한다. 이러한 프로토콜들은 TCP layer를 이용하는데, 멀티미디어 전송의 관점에서 TCP 전송은 3가지의 주요한 단점을 지닌다.
① Processing overhead
② Network Transmission Delay
③ Lack of multimedia functionalities
2) HTTP 나 FTP 는 TCP 기반의 프로토콜로서 TCP 프로토콜은 안정적인 데이터 전송과, low bandwidth, high network error 환경에서 적합한 프로토콜이다.
만약 송신 및 수신단 에서 데이터 손실이 발생하는 경우 이를 송신측으로 재 요청을 통하여 데이터의 재전송 및 재 수신이 이루어지게 된다. 이러한 데이터 전송에 대한 무손실 보장은 결국 네트워크에 대한 오버헤드로 작용하게 된다.
그래서 스트리밍 데이터의 전송(화상회의, 인터넷 브로드캐스팅, 멀티캐스팅)에서는 TCP 와는 다른 프로토콜을 이용하게 되었고, 일반적으로 추천 받은 프로토콜이 UDP 이다. UDP 는 Unreliable 프로토콜로서 수신단 측에서 데이터 수신에 대한 보장을 하지 않으며, 또한 전송되는 데이터 패킷이 올바른 순서대로 수신단에서 받는다는 보장이 없다. 이러한 UDP 환경에서 수신단측 에서 결국, 데이터 손실에 대한 보상처리를 해주어야 하고, 패킷의 복제 기능, 패킷의 재정렬 기능을 구현해 주어야 하는 책임이 있었다. TCP 와 마찬가지로 UDP 역시 일반적인 Transport Layer 의 통신 프로토콜이며, 오디오나 비디오와 같은 스트리밍 데이터 전송에 대한 인터넷 표준으로 RTP 를 이용하게 되었고, RTP 는 IEEE RFC 1889로 규정되어 있다.
3. RTP Unicat / Multicast
RTP 는 Unicast와 Multicast 양측에서 모두 사용가능하며, Unicast 서비스 모드에서는 각각의 데이터 카피본이 전송 데이터의 소스위치에서 목적지로 전송이 된다. Multicast 서비스 모드에서는 데이터가 소스에서만 보내지고, 네트워크 자체가 다중 목적지로 전송에 대한 책임을 지는 구조를 구현한다. 멀티캐스팅이 비디오 오디오 데이터를 발생시키는 화상회의와 같은 응용 애플리케이션에 보다 더 효율적으로 적용될 수 있으며 멀티캐스팅을 지원하는 IP 프로토콜을 이용하게 된다. RTP 는 전송된 데이터의 구별능력과 패킷의 순서에 대한 결정 , 다중 미디어에 대한 효율적인 동기화 기능을 수행하지만 RTP 는 송신단에서 보내지는 패킷의 순서대로 수신단에서 패킷을 수신한다는 보장이 없다. 또한 송신한 모든 데이터 패킷이 전부 다 수신단에 도달한다는 보장도 없으므로 수신단의 패킷 시퀀스를 다시 만들고, 패킷 헤더에서 제공되는 정보를 가지고 손실된 데이터 패킷을 검출하는 모든 부분이 바로 수신단의 책임이 된다. 주의할 것은 RTP 는 주기적인 전송의 보장이나, 서비스 quality 에 관한 보장이 없기 때문에 , 데이터 전송의 품질을 보증하기 위해서 RTCP 를 이용하게 된다. RTCP 는 또한 RTP 전송에 대한 control 기능과 identification 매커니즘을 제공한다.
4. RTP 프로토콜을 이해하기 위한 용어들
1) RTP (Realtime Transport Protocol)
① 실시간 미디어 스트림에 대한 전송과 수신을 목적으로 설계
② 모든 RTP 버퍼들은 timestamp 를 가지고 있어서, timestamp 와 실제 전역적인 동기화된 클럭(예를 들어서 JMF Player 의 TimeBase) 사이의 매핑을 수행한다.
③ Timestamp 의 역할은 다양한 데이터 소스로부터 제공되는 미디어들을 통합하는 기능을 지닌다
2) Session 과 Participants
① Session : 둘이상의 Participants 간의 데이터 교환을 의미
② Participants: 데이터 교환에 참여하는 각각의 송/수신단을 의미
3) RTCP (Realtime Control Protocol)
① RTCP는 프리젠테이션의 데이터 품질과 함께 RTP session에 대한 모니터링 기능을 제공한다.
② 각각의 데이터를 구분하기 위해 식별자로서 Palyload type(PT)을 이용한다
4) RTSP(Realtime Streaming Protocol)
① RTP보다 상위 단계의 프로토콜로서 멀티미디어 스트림에대한 Command/ Control 기능을 제공
② UDP 와 같이 RTSP 도 비연결지향 프로토콜이며 각각의 스트림은 세션 ID 에 의해 서로 구별
③ RTSP 의 control 요청은 연결이 보장된 프로토콜 즉, TCP 를 통해 전송
5. RTP 구조
Real-Time Media Frameworks and Applications
Real-Time Control Protocol (RTCP)
Real-Time Transport Protocol (RTP)
Other Network and
Transport Protocols
(TCP, ATM, ST-Ⅱ, etc.)
UDP
IP
[그림 1] RTP의 구조
6. RTP Applications
1) RTP Client, RTP Server 로 구성
2) RTP를 통한 네트워크 송수신의 사례
① Receiving Media Streams from the Network
② Transmitting Media Streams across the Network
7. JMF 에서의 RTP 구현
1) RTP 관련 패키지
- javax.media.rtp
- javax.media.rtp.event
- javax.media.rtp.rtcp
2) JMF RTP API 지원사항
- RTP 세션 생성하고 세션열기 수행
- 세션으로 들어오는 스트림 수신 및 JMF Player 또는 Processor 생성하고 재생
- 수신되는 스트림의 통계정보를 획득하고, RTCP 정보를 통한 세션의 모니터링 수행
- 데이터 소스로부터 RTP 스트림을 전송
- Send 스트림의 통계정보 획득 및 RTCP를 이용한 모니터링 방법 제공
- RTPSessionManager를 이용한 동적 Playload의 이용 및 사용자 Plug-in 기능
