RSVP/RTP/RTCP/RTSP

RSVP ( resource reservation protocol )

RTCP가 수신 품질에 대한 보고를 통해서 송신자 측에서 트래픽을 조절할 수 있게는 하지만 송신자와 수신자 간에 적시 전송과 특정 QoS 만족을 성취하기 위해서는 RTCP 이외에 다른 프로토콜 체계가 필요하다. 이러한 필요에 의해 등장한 것이 RSVP이다.
RSVP는 사용자 간 특정 데이터 스트림에 대한 QoS 만족을 위해 네트워크의 자원을 미리 확보해 두기 위해 이용되는 자원 예약 프로토콜이다.
수신자는 RSVP를 이용해서 특정 데이터 스트림을 위해 네트워크으로부터 특정 QoS를 요청한다. 기본적인 RSVP 예약 요청은 요구되는 QoS와 이 QoS를 보장 받을 데이터 패킷에 대한 정의를 포함한다. 멀티캐스트의 경우 호스트는 IGMP 메시지를 보내서 호스트 그룹에 가입한 후 RSVP 메시지를 그 그룹의 전송 경로를 통해서 보내어 자원을 예약한다.
RSVP가 동작하기 위해서는 송신자와 수신자 간의 전송 경로에 위치하는 모든 호스트와 라우터 그리고 다른 네트워크 기반 요소들에서 RSVP를 지원해야만 한다. RSVP를 지원하는 각각의 구성 요소들은 QoS 요청을 만족시키는데 필요한 대역폭, CPU 그리고 메모리 버퍼와 같은 시스템 자원들을 예약한다. QoS는 주어진 서비스 모델을 위한 흐름 명세(Flow Spec)에 의해 정의된다. 서비스 모델에 따라 흐름 명세는 세션 데이터를 위한 전송 속도와 지연의 한계를 명시하거나 전송 속도만을 명시한다. 서비스 모델은 IETF Integrated-Services Working Group에서 정의되고, RSVP는 일반적으로 Guaranteed Service나 Controlled-Load Service 가운데 하나를 구현하고 있다. RSVP 세션은 RSVP를 지원하지 않는 라우터를 통해서 Tunneling할 수도 있다.

 

RTCP ( real-time transport control protocol )

RTCP는 RTP의 QoS를 유지하기 위해 함께 쓰이는 프로토콜이다. RTP는 데이터 전송에만 관계하지만, RTCP는 데이터 전송을 감시하고, 세션 관련 정보를 전송하는데 관여한다. RTP 노드들은 네트웍 상태를 분석하고 주기적으로 네트웍 정체 여부를 보고하기 위해 RTCP 패킷을 서로에게 보낸다. RTP와 RTCP는 모두 UDP 상에서 동작하므로, 그 특성상 품질보장이나 신뢰성, 뒤바뀐 순서, 전송 방지 등의 기능을 제공하지는 못하지만, 실시간 응용에서 필요한 시간 정보와 정보 매체의 동기화 기능을 제공하기 때문에, 최근 인터넷상에서 실시간 정보를 사용하는 거의 모든 애플리케이션 (VOD, AOD, 인터넷 방송, 영상 회의 등)들이 RTP 및 RTCP를 이용하고 있다.

1. 특징
RTP와 쌍으로 존재함.
RTP 패킷이 송신자 --> 수신자로 단 방향인 데 반해, RTCP는 양 방향임.
패킷 구조는 RTP와 유사함.
멀티캐스트 환경인 경우, 전송 성능 및 QoS 감시가 가능함.
RTCP 패킷은 데이터가 없을 때 세션이 유효함을 수신자에게 알림.
RTP 세션에 참가하고 있는 참가자의 파악이 가능함.
5% 이내로 RTCP 패킷 량 제한됨.
2. 기능
서비스 품질 감시, 체증 제어, 매체간 동기화, 발신지 식별, 세션의 크기 추정 등
세션의 유지와 관리에 필요한 중요한 기능을 수행함.
3. 패킷의 종류
- 송신자 보고 (SR), 수신자 보고 (RR) 패킷
- 송신자 기술 (SDES) 패킷
- 탈퇴 (BYE) 패킷
- 응용 (APP) 패킷

 

RTSP ( real-time streaming protocol )

On Demand 형식으로 리얼타임 미디어 전송을 행하는 애플리케이션 계층의 프로토콜을 말한다. 실시간으로 음성이나 동화를 송수신하기 위한 통신 규약. 미국 Real Networks (구 progressive network)사와 넷스케이프 커뮤니케이션즈사가 공동 개발하였으며 상세한 사항은 RFC 2326에 규정되어 있다.
RTSP도 H.323과 마찬가지로, 멀티미디어 콘텐츠 패킷 포맷을 지정하기 위해 RTP를 사용한다. 그러나 H.323이 적당한 크기의 그룹간에 화상회의를 하기 위해 설계된 데 반해, RTSP는 대규모 그룹들에게 오디오 및 비디오 데이터를 효율적으로 브로드캐스트 하기 위한 목적으로 설계되었다.
RTP (real-time transport protocol)와는 달리 애플리케이션층에서 동작하는 특징이 있다. 통상의 TCP/IP 스택을 교환할 필요가 없으며, 다만 TCP 대신 RTP도 사용하도록 하고 있는데, 이 경우에는 좀 더 확실히 서비스 품질(QoS)을 개선할 수 있다

 

RTP ( real-time transport protocol )

실시간으로 음성이나 통화를 송수신하기 위한 트랜스포트층 통신규약. RFC 1889에 RTCP(RTP control protocol)와 함께 규정되어 있다. 자원 예약 프로토콜(RSVP)과는 달리 라우터 등의 통신망 기기에 의지하지 않고 단말 간에 실행되는 것이 특징이다. RTP는 보통 사용자 데이터그램 프로토콜(UDP)의 상위 통신 규약으로 이용된다. 송신 측은 타임 스탬프(time stamp)를 근거로 재생 동기를 취해서 지연이 큰 패킷을 포기할 수 있다. 또, 수신 측에서 전송 지연이나 대역폭 등을 점검, RTC(RTP control portocol)를 사용해서 LAN/인터넷 환경에서 비디오 회의 시스템의 ITU 권고 H.323에 채용되었으며 미국 마이크로소프트사의 비디오 회의 소프트 NetMeeting 등이 탑재되어 있다.

단순한 다중 음성회의(Simple Multicast Audio Conference)
다수를 대표하는 하나의 주소와 한 쌍의 포트를 가지고 회의를 한다. 하나의 포트는 음성 데이터를 전송하는데 사용되고, 다른 하나의 포트는 RTCP가 사용한다. 이러한 주소와 포트에 관한 정보는 회의 참여자에게 알려진다. 인터넷상에서 통신을 할 때에는 송신자가 보낸 데이터가 도중에 없어지거나 송신자가 보낸 순서와 다르게 데이터가 도착할 수도 있고, 또는 보낸 데이터가 늦게 도착하는 경우도 종종 발생한다. 그래서, RTP를 이용한 데이터 전송 시에는 수신자가 받은 데이터를 제대로 조합시킬 수 있도록 데이터에 대한 시간정보와 순서번호에 대한 정보가 포함된다.
음성과 영상회의(Audio and Video Conference) : 음성과 영상을 동시에 회의에서 사용하고자 한다면, 음성과 영상 데이터는 각각의 RTP 데이터로 전송되어야 한다. RTCP 데이터는 음성과 영상, 각각에 대하여 다른 포트의 쌍과 다수를 대표하는 하나의 주소가 사용되어 전송된다. 그러므로, 회의의 참여자는 자신이 선택한 형태(음성 또는 영상)의 데이터를 선택하여 수신할 수 있다. 만약, 두 가지 형태의 데이터를 수신하고자 하는 참여자에게는 RTCP 패킷에 시간 정보를 포함시켜서 두 데이터를 적절하게 보고 들을 수 있게 하였다.

혼합기와 전환기(Mixers and Translators)

회의에 참여하는 모든 참여자들이 같은 환경에서 참여한다면 혼합기와 전환기는 필요하지 않다. 하지만, 전세계에서 인터넷을 통해 통신을 하는 참여자들이 모두 같은 환경일 수는 없다. 그러므로, 각 참여자들에게 적절한 형태의 데이터 전송이 이루어지게 하기 위해 사용된다. 예를 들어, 느린 속도로만 가능한 참여자가 고속 처리가 가능한 회의에 참여하고자 할 때, 또는 그 반대의 경우이면 한명의 참여자로 인해 다수의 참여자에게 불이익을 줄 수 없다는 것이 혼합기와 전환기 사용의 목적이다. 즉, 환경이 다른 참여자에게도 적절한 형태로 데이터 전송을 해 주는 것이다.

< 특징 >
- UDP는 TCP에 비해 신뢰성이 낮은 반면, 더 빠르게 데이터를 전달함.
이러한 UDP의 특성을 이용하여 RTP가 등장함.
- RTP는 그 자체로 QoS 보장이나 신뢰성을 제공하지 못함.
- 시간 정보와 정보 매체의 동기화 기능을 제공함.
-RTP는 다른 3계층, 4계층 프로토콜과도 같이 사용이 가능하며, 하위 프로토콜에 별로 의존하지 않음.