RTSP(Real-Time Streming Protocol) RSVP(Resource Reservation) 개요

RTSP(Real-Time Streming Protocol)

 

>> RFC 2326

☛ 개요 

   많은 인터넷 멀티미디어 사용자는 재생 중지 이전이나 이후 시점으로 재생 재위치, 급전진 재생, 되감기 재생 등을 이용하여 연속적인 미디어의 재생을 제어하려고 한다. 이런 기능은 DVD 비디오를 볼 때 DVD 플레이어를 조작하거나, 음악 CD를 들을 때 CD 플레이어를 조작하는 것과 비슷하다. 사용자가 재생을 제어할 수 있도록 하려면 미디어 플레이어와 서버는 재생 제어정보를 교환하는 프로토콜이 필요한데 RTSP가 바로 그것이다.

☛ RTSP가 하지 않는 것

- 오디오와 비디오를 압축하는 기법에 대해서는 정의 하지 않는다.

-  네트워크 상으로 전송하기 위해서 오디오와 비디오를 어떻게 패킷으로 캡슐화 하는지에 대해서는 정의하지 않는다.

스트리밍 미디어를 캡슐화하는 것은 RTP 또는 임의의 사적 프로토콜에 의해서 제공될 수 있다. 예를 들어, 리얼네트웍스사의 오디오/비디오 서버와 플레이어는 서로에게 제어정보를 전송하기 위해 RTSP를 사용한다. 그러나 미디어 스트림 자체는 RTP 패킷들이나 EH는 다른 사설 데이터 타입으로 캡슐화 할 수 있다.

- 스트림된 미디어의 전송 방식에 대해서는 제약하지 않는다.

 RTSP는 UDP나 TCP상으로 전송될 수 있다.

- 미디어 플레이어의 오디오/비디오 버퍼링 방식을 제약하지 않는다.

 오디오/비디오는 클라이언트에 도착하는 즉시 재생될 수도 있고, 또는 몇 초의 지연 후에 재생 될 수도 있으며, 재생하기 전에 모두 다운로드할 수도 있다.

 

그림 RTSP사용하는 클라이언트/서버의 상호작용

 

   RTSP는 미디어 플레이어가 매체 스트림의 전송을 제어할 수 있게 하는 프로토콜이다. 제어동작에는 정지/재시작. 재생 재위치. 급전진과 되감기가 있다. RTSP는 흔히 말하는 대역외(out-of-band)프로토콜이다. 특히, RTSP 메시지는 대역외로 전송되는 반면, RTSP에 의해 패킷 구조가 정의되지 않은 미디어 스트림은 대역내(in-band)로 여겨진다. RTSP 메시지는 미디어 스트림과는 다른 포트번호 544를 사용한다. RFC에서는 RTSP메시지가 TCP나 UDP상으로 전송되는 것을 허용한다. 

 

 

   그림을 보면 먼저 웹 브라우저는 웹 서버에게 프리젠테이션 기술 파일을 요청한다. 프리젠테이션 기술 파일은 연속 미디어 파일의 동기화에 대해서 지시할 뿐만 아니라 연속 미디어 파이들을 참조할 수 있다. 각각의 연속 미디어 파일에 대한참조는 URL 기법인 rtsp://로 시작된다. 다음에 파일을 제시한 후 이 프레젠테이션에서 오디오와 비디오 스트림은 병렬로( 같은그룹의 일부로) 립 싱크해서 재생된다. 오디오 스트림에 대해 미디어 플레이어는 두 종류의 오디오 기록, 즉 저품질 기록과 고품질 기록 중에서 선택(스위치)할 수 있다.

 

   웹 서버는 프레젠테이션 기술 파일을 HTTP 응답 메시지에 캡슐화해서 브라우저에게 전송한다. 브라우저는 HTTP 응답 메시지를 수신하면 그 메시지의 content-type 필드에 맞게 미디어 플레이어를 가동한다. 프레테이션 기술 파일은 앞 예에서 본 것처럼 URL 기법인 rtsp://를 사용하는 미디어 스트림에 대한 참조를 포함한다. 그 뒤에 플레이어와 서버는 그림처럼 서로에게 일련의 RTSP 메시지를 전송한다. 플레이어는 RTSP SETUP 요청을 보내고, 서버는 RTSP OK 메시지로 응답한다. 플레이어는 저품질 오디오에 대한 RTSP　PLAY 요청을 보내며, 서버는 RTSP OK 메시지로 응답한다. 이 시점에서 스트리밍 서버는 저품질 오디오를 자신의 대역내 채널로 내보낸다. 나중에 미디어 플레이어는 RTSP PAUSE 요청을 보내고, 서버는 RTSP OK 메시지로 응답한다.사용자가 실행을 끝내면, 미디어 플레이어는 RTSP TEARDOWN 요청을 보내며, 서버는 RTSP OK 메시지로 응답한다.

☛ HTTP와 RTSP의 유사점 & 차이점

- 유사점 : 모든 요청과 응답 메시지는 ASCII 텍스트로 되어 있으며, 클라이언트는 표준화된(setup, play등) 방법을 사용하고, 서버는 표준 응답코드로 답한다.

- 차이점 : RSTP 서버는 진행 중인 각 RTSP 세션의 클라이언트 상태를 계속 감시한다는 것이다. 예를 들어 서버는 클라이언트가 초기상태, 재생상태, 정지상태에 있는지 그 여부를 계속 검사한다. RTS 요청과 응답에 포함되어 있는 세션번호 및 순서번호는 서버가 세션 상태를 감시할 수 있도록 한다. 세션번호는 전체 세션에서 그대로 유지된다. 서버는 세션번호와 현재 순서번호를 돌려준다.

☛ SETUP

- 클라이언트는 스트리밍할 파일의 URL과 RTSP 버전이 포함된 SETUP 요청해서 세션을 초기화 한다. SETUP메시지는 미디어가 전송되어야 할 클라이언트의 포트번호도 포함한다. 또한 패킷화를 수행하는 프로토콜인 RTP를 사용해서 UDP상으로 미디어를 전송하도록 지시한다.

 

 

 

RSVP(Resource Reservation Protocol)

 

 >> RFC 2205

☛ 개요

   네트워크가 QoS를 보장을 하기 위해서는 호스트에서 실행되고 있는 애플리케이션들로 하여금 인터넷에서 자원을 예약할 수 있도록 하는 시그널링 프로토콜이 있어야만 하는데 RSVP는 인터넷을 위한 그런 시그널링 프로토콜이다.

   RSVP 프로토콜은 애플리케이션들로 하여금 자신의 데이터 흐름을 위해 대역폭을 예약할 수 있도록 한다. 이 프로토콜은 애플리케이션 데이터 흐름을 대신해서 호스트가 네트워크로부터 특정 양의 대역폭을 요청하기 위해 사용된다. 또한 RSVP는 라우터가 대역폭 예약 요청을 전달하기 위해서 사용된다. 또한 RSVP는 라우터가 대역폭 예약 요청을 전달하기 위해서 사용된다. RSVP를 구현하려면 수신자, 송신자, 라우터에 RSVP 소프트웨어가 있어야만 한다.

 

 

그림 RSVP : 멀티캐스트 그리고 수신 지향형

 

☛ 특징 

 

1. 멀티캐스트 트리에서 대역폭 예약을 할 수 있게 한다.

2. 수신자지향(receiver-oriented), 즉 데이터 흐름의 수신자가 그 흐름을 위한 자원예약을 시작하고 유지한다.

   옆의 그림은 트리의 맨 위로부터 트리의 맨 아래에 있는 호스트들로 데이터 흐름이 있는 멀티캐스트 트리를 보여준다. 비록 데이터는 송신자가 보내지만, 예약 메시지는 수신자가 보낸다. 라우터는 예약 메시지를 송신하는 쪽인 상향으로 전달할 때 이 예약 메시지를 하향에서 오는 다른 예약 메시지들과 합칠 수 있다.

☛ RSVP가 하지 않는 것

1. 네트워크가 데이터 흐름에게 예약된 대역폭을 제공하는 방식에 대해서 명시하지 않났다.

    RSVP는 단지 애플리케이션으로 하여금 필요한 링크 대역폭을 예약할 수 있도록 해주는 프로토콜일 뿐이다. 일단 예약이 되면, 데이터 흐름에게 예약된 대역폭을 실제로 제공하는 것은 인터넷의 라우터에게 달려 있다. 이러한 일들은 스케줄링기법을 사용하면 가능하다.

2. 라우팅 프로토콜이 아니다.

   RSVP는 예약을 해야 하는 링크들을 결정하지 않는다. 대신에 흐름을 위한 경로를 결정하기 위해 하부의 라우팅 프로토콜에 의존한다. 일단 경로가 결정되면 RSVP는 이 경로상의 링크들의 대역폭을 예약할 수 있다. (경로가 바뀌면 RSVP가 자원을 재예약하는 것을 볼 수 있다.)일단 예약이 되면, 라우터의 패킷 스케줄러는 데이터 흐름에게 예약된 대역폭을 실제로 제공해야 한다. 따라서 RSVP는 QoS를 보장하는 요소들 중 한 가지 일 qNs이다.

   RSVP는 시그널링 프로토콜(signaling protocol)이라고 한다. 이것은 RSVP가 호스트로 하여금 데이터 흐름을 위한 얘약을 설정하고 해제할 수 있게 하는 프로토콜이라는 것을 뜻한다.

* 이질적인특성을 가진 수신자들의 문제를 해결하기 위해 비디오와 오디오를 계층적으로 인코딩하도록 제안하고자 하낟. 예를 들어, 비디오는 두 계층으로 인코딩할 수 있다. 즉, 기본계층과 향상된 계층이다. 기본 계층은 20kbps의 전송률을 갖는 반면에 향상된 계층은 100kbps의 전송률을 가질 수 있다. 이런 식으로 28.8kbps의 접근을 갖는 수신자는 저품질의 기본 계층 이미지를 수신할 수 있고 128kbps의 수신자는 고품질의 이미지를 구성할 수 있도록 두 계층 모두 수신할 수 있다.

송신자는 모든 수신자들의 수신율을 알고 있을 필요가 없으며, 단지 수신자들의 수신율 중 최고 수신율만 알면 된다. 송신자는 비디오나 오디오를 여러 계층으로 인코딩해서 최고율까지의 모든 RP층을 멀티캐스트 트리로 전송한다. 수신자는 자신의 수신율에 맞는 계층만을 받아들인다. 네트워크 링크 대역폭을 너무 많이 낭비하지 않기 위해서, 이질적인 수신자들은 자신이 처리할 수 있는 수신유은 네트워크에게 알려야 한다. RSVP는 이질적인 수신자들에게 자원을 예약해주는 문제에 가장 관심을 기울인다.

☛ 콜 수락(Call Admission)

   레스토랑의 매니저가 레슽랑의 테이블 수보다 더 많은 예약을 받아들일 수 없는 것처럼, 라우터가 예약하는 링크의 대역폭 양은 링크의 용량을 초과해서는 안 된다. 따라서 라우터는 새로운 예약 메시지를 수신할 EO마다 멀티캐스트 트리상의 하향 링크들이 예약을 수용할 수 있는지에 대해서 먼저 결정해야 한다. 이와 같은 수락 시험은 라우터가 예약 메시지를 수신할 때마다 수행된다. 만일 수락 시험이 실패하면, 라우터는 예약을 수락하지 않고 오류 메시지를 적절한 수신자에게 보낸다.

☛ 동작

1. 전송근원지는 멀티캐스트 트리를 통해 RSVP path 메시지를 보내서 자신의 콘텐츠를 광고하는데 이를 통해 콘텐츠에 필요한 대역폭과 소프트 상태 타임아웃 간격, 그리고 송신자로의 업스트림 경로에 대한 정보를 나타낸다. 각 수신자는 RSVP 예약 메시지를 멀티 캐스트 트리의 상향으로 전송한다 예약 메시지는 수신자가 송신지로부터 데이터를 수신하고자 하는 비율을 명시한다. 예약 메시지가 라우터에 도착하면, 라우터는 이 예약을 수용할 수 있도록 자신의 패킷 스케줄러를 조절한다. 라우터에게 예약받는 상향대역폭의 양은 하향예약된 대역폭에 의존한다.

 

 

 

   그림을 보면 우리는 RSVP가 수신자 지향이라는 것을 알 수 있다. 즉, 데이터 흐름의 수신자는 이 흐름에서 사용하는 자원예약을 초기화 하고 유지한다. 각 라우터는 멀티 캐스트 트리의 하향 링크들로부터 예약 메시지를 수신하며 상향 링크로 단 하나의 예약 메시지를 전송한다.